Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110518 > unrolled thread
| Started by | joel.rees@gmail.com |
|---|---|
| First post | 2017-05-23 18:46 -0700 |
| Last post | 2017-05-25 02:21 -0700 |
| Articles | 20 on this page of 250 — 24 participants |
Back to article view | Back to comp.lang.c
conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 18:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 03:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 19:47 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 11:54 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:16 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 20:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-23 22:10 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 20:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 12:22 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 12:00 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 04:10 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 14:28 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 16:36 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 16:02 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 17:43 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Thiago Adams <thiago.adams@gmail.com> - 2017-05-25 05:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:10 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 09:55 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 10:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 10:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 07:33 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 15:43 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 08:05 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 16:15 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 17:52 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 11:55 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:42 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 16:50 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:58 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 17:10 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:07 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 11:34 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:19 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 15:04 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:06 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 09:00 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:24 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 14:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:09 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-27 08:43 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 17:01 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 14:38 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 05:54 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 15:15 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 14:14 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 17:55 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-24 23:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 20:59 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:59 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 18:30 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 21:46 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 22:48 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 01:10 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 01:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 03:41 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 12:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 22:26 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 23:25 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 17:03 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-26 01:09 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:29 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:24 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:35 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 03:41 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-26 11:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:43 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:29 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:20 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Gareth Owen <gwowen@gmail.com> - 2017-05-29 07:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-29 11:37 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:25 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-30 16:06 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 15:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:26 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 11:58 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 04:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Melzzzzz <Melzzzzz@zzzzz.com> - 2017-05-24 11:14 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 14:58 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 15:48 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 18:54 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 16:58 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 18:19 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:58 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 21:45 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 08:51 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 17:22 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 21:38 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-26 23:02 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 12:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-01 11:47 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-01 10:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-02 00:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-02 00:11 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-02 00:51 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-02 02:21 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:59 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 13:03 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 20:32 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 15:16 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 22:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 17:16 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 11:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 17:34 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-04 17:32 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:37 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Philip Lantz <prl@canterey.us> - 2017-05-25 21:08 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Philip Lantz <prl@canterey.us> - 2017-05-25 21:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-26 03:33 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 22:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:21 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 22:07 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 14:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:57 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 15:47 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-25 18:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-25 22:29 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 15:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-26 09:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-26 23:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-27 11:39 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 13:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-27 13:26 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 00:57 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 08:42 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 18:52 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 15:08 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 01:52 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 16:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 05:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 13:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 15:12 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 15:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 15:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 17:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 20:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 01:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 05:24 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 06:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 17:13 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 19:26 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 14:19 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 15:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Gareth Owen <gwowen@gmail.com> - 2017-05-30 07:01 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-30 09:31 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-27 16:22 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 14:41 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 06:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 09:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 03:58 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 01:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 13:48 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 06:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 15:46 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 15:40 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 17:18 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 15:08 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 20:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") luser droog <luser.droog@gmail.com> - 2017-05-30 00:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 11:54 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-30 09:48 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-30 07:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-30 10:20 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-30 14:50 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") scott@slp53.sl.home (Scott Lurndal) - 2017-05-30 19:16 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-30 12:07 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-30 20:15 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:01 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 11:25 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 14:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:32 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") asetofsymbols@gmail.com - 2017-06-03 03:50 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 11:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 18:54 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 12:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-11 23:34 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-12 07:17 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-12 08:12 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") jameskuyper@verizon.net - 2017-06-12 09:01 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-12 09:34 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-13 22:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-14 09:42 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-14 17:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-15 03:28 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-15 07:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-14 07:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-14 20:19 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-04 19:00 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-05 11:48 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 08:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 10:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") scott@slp53.sl.home (Scott Lurndal) - 2017-06-05 18:05 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-05 21:31 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 13:04 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 14:50 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 13:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 15:22 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 13:30 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 08:15 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:38 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 18:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 18:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 18:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 14:08 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:17 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 02:39 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:48 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 15:13 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 14:34 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 16:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 15:02 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 17:19 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 17:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 18:58 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 18:24 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 20:36 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 16:06 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:54 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:33 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:12 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 02:00 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 09:34 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-26 23:08 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-27 16:40 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 19:36 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-24 23:16 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 21:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 15:45 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 14:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 05:50 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-25 02:21 -0700
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-05 11:48 +0200 |
| Message-ID | <oh3976$5sd$1@dont-email.me> |
| In reply to | #111505 |
On 05/06/17 04:00, supercat@casperkitty.com wrote: > On Sunday, June 4, 2017 at 9:44:17 AM UTC-5, David Brown wrote: >> On 03/06/17 20:28, supercat wrote: >> By this logic, it would be a good idea for /all/ C compilers now to >> treat all data that is not register qualified, as having volatile semantics. > >> I suspect that even /you/ would see that as a bad idea. > > I would regard an option to treat everything as volatile would be a useful > thing to have, since it would allow a compiler to be usable with the widest > range of programs. As an indication of how useful other people think that might be, gcc used to have a "-fvolatile" switch doing exactly that. It was removed in 3.4, because it hadn't worked correctly in the entire 3.x series and no one had noticed. So /you/ might regard this as a useful option, but you are very much in the minority. > For most programs, a "feel free to cache things in > registers when there's no evidence of aliasing, but flush things to memory > when executing constructs that are indicative of aliasing" mode would allow > better performance without having to give up any semantics, and would thus > be preferred. On the other hand, a "first make it work--then make it > faster" philosophy would suggest that a mode which synchronizes to memory > at every step would be a wise thing to include. > <snip> > >> The same principle applies to /all/ your arguments about mythical >> unwritten standards or agreements, how things "used to be", and >> everything else you belief about undefined behaviour. > > How many useful operating systems are there written in C (suitable for > use on freestanding implementations) that would be compatible with the > aliasing rules in the Standard? > All of them, except a few where the lead developers have some odd ideas about what they would like C to be. I know of no operating systems other than Linux that need flags such as -fno-strict-alias in order to compile correctly - and I have seen quite a few useful operating systems that work on a wide range of target processors, and a wide range of compilers, with a wide range of compiler options. Linus Torvalds feels that some parts of Linux can be written in a simpler way if there is no type-based alias analysis. He is presumably correct on that one. He feels that enabling type-based alias analysis does not improve code efficiency significantly in other areas of the code - he may well be right there too. He feels that writing the code in a way that is correct when type-based alias analysis is enabled will lead to slower code in places - I think he is probably wrong there. But code clarity, and especially code correctness, trumps code efficiency - so it is fair enough to choose to have the "-fno-strict-aliasing" enabled on the Linux kernel. Maybe one day the code in question will be changed to use the "may_alias" gcc attribute to make it clear where code relies on messing with aliasing and avoid such compiler option requirements. However, it is perfectly acceptable for particular pieces of code to have implementation-specific requirements - C is designed to make that possible and practical.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-05 08:44 -0700 |
| Message-ID | <a42a24c8-b53f-4999-a752-b568b213ea99@googlegroups.com> |
| In reply to | #111522 |
On Monday, June 5, 2017 at 4:48:51 AM UTC-5, David Brown wrote:
> On 05/06/17 04:00, supercat wrote:
> > How many useful operating systems are there written in C (suitable for
> > use on freestanding implementations) that would be compatible with the
> > aliasing rules in the Standard?
>
> All of them, except a few where the lead developers have some odd ideas
> about what they would like C to be. I know of no operating systems
> other than Linux that need flags such as -fno-strict-alias in order to
> compile correctly - and I have seen quite a few useful operating systems
> that work on a wide range of target processors, and a wide range of
> compilers, with a wide range of compiler options.
The embedded OS code I've seen could be broken by a compiler that went out
of its way to be maximally aggressive. Given something like:
typedef struct { char dat[16]; }; string15;
string8 s1,s2;
float *fp = alloc256();
fp[3] = 1.234f;
release256(fp);
string15 *st = alloc256();
strcpy(st.dat, "Hey");
s1 = *st;
release256();
a compiler would be allowed to do anything it likes if alloc256() yields
the pointer that was just given to release256() without writing anything
into bytes 12-15 of the block in question. Would you regard the code as
defective for treating those bytes as part of a "string15" without having
first initialized them?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-05 10:37 -0700 |
| Message-ID | <95499ab6-b12c-4446-b566-f8b9ce530055@googlegroups.com> |
| In reply to | #111522 |
On Monday, June 5, 2017 at 4:48:51 AM UTC-5, David Brown wrote:
> As an indication of how useful other people think that might be, gcc
> used to have a "-fvolatile" switch doing exactly that. It was removed
> in 3.4, because it hadn't worked correctly in the entire 3.x series and
> no one had noticed. So /you/ might regard this as a useful option, but
> you are very much in the minority.
What did that do, how was it documented, how did it differ from -O0, and in
what ways was it defective? If someone had been using the flag when it was
discontinued, would any difficulties be expected if they simply change the
build options to -O0?
Also, does GCC have any option to presume that any volatile read or write
might behave as a call to an unknown function that could alter any objects
whose address has been exposed to the outside world? For example, if one
has code to perform asynchronous I/O functions and is supposed to support
usage like:
buff = malloc(buffsize);
fread(buff, 1,buffsize, someFile);
beginAudio(buff);
... and then some time later
endAudio();
free(buff);
and such code doesn't include any gcc directives, are there any options that
would prevent gcc from moving any accesses to "buff" across volatile accesses
performed in beginAudio and endAudio?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-05 18:05 +0000 |
| Message-ID | <z3hZA.10339$re5.6605@fx13.iad> |
| In reply to | #111566 |
supercat@casperkitty.com writes: >On Monday, June 5, 2017 at 4:48:51 AM UTC-5, David Brown wrote: >> As an indication of how useful other people think that might be, gcc >> used to have a "-fvolatile" switch doing exactly that. It was removed >> in 3.4, because it hadn't worked correctly in the entire 3.x series and >> no one had noticed. So /you/ might regard this as a useful option, but >> you are very much in the minority. > >What did that do, how was it documented, how did it differ from -O0, and in >what ways was it defective? If someone had been using the flag when it was >discontinued, would any difficulties be expected if they simply change the >build options to -O0? > >Also, does GCC have any option to presume that any volatile read or write >might behave as a call to an unknown function that could alter any objects >whose address has been exposed to the outside world? For example, if one >has code to perform asynchronous I/O functions and is supposed to support >usage like: > > buff = malloc(buffsize); > fread(buff, 1,buffsize, someFile); > beginAudio(buff); > ... and then some time later > endAudio(); > free(buff); > >and such code doesn't include any gcc directives, are there any options that >would prevent gcc from moving any accesses to "buff" across volatile accesses >performed in beginAudio and endAudio? https://en.wikipedia.org/wiki/Sequence_point
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-05 21:31 +0200 |
| Message-ID | <oh4bbj$3tm$1@dont-email.me> |
| In reply to | #111566 |
On 05/06/17 19:37, supercat@casperkitty.com wrote: > On Monday, June 5, 2017 at 4:48:51 AM UTC-5, David Brown wrote: >> As an indication of how useful other people think that might be, gcc >> used to have a "-fvolatile" switch doing exactly that. It was removed >> in 3.4, because it hadn't worked correctly in the entire 3.x series and >> no one had noticed. So /you/ might regard this as a useful option, but >> you are very much in the minority. > > What did that do, how was it documented, how did it differ from -O0, and in > what ways was it defective? It did as you wanted - it made gcc treat all memory as "volatile". That is very different from saying no optimisations (-O0). If you want detailed documentation, you can look it up for yourself - the gcc manuals are all online, even old ones like the 3.x series. I don't know how it was defective - I just know that the comment in the changelog for 3.4 said it was removed "GCC no longer accepts the options -fvolatile, -fvolatile-global and -fvolatile-static. It is unlikely that they worked correctly in any 3.x release." If you want to look for details, search the mailing list archives and the bugzilla archives. > If someone had been using the flag when it was > discontinued, would any difficulties be expected if they simply change the > build options to -O0? I expect that very few, if any, users /were/ using the flag - that's usually the case when developers suspect that something has been defective for a long time. And no, no one who had been successfully using the flag would have had difficulties when it was discontinued - because they could continue to use the same version of gcc that they always had. If you are relying on special flags and odd implementation-defined behaviour, you don't upgrade your compiler unless you are willing to do extensive testing and re-qualifying, and possibly re-writing of parts of your code. > > Also, does GCC have any option to presume that any volatile read or write > might behave as a call to an unknown function that could alter any objects > whose address has been exposed to the outside world? For example, if one > has code to perform asynchronous I/O functions and is supposed to support > usage like: > > buff = malloc(buffsize); > fread(buff, 1,buffsize, someFile); > beginAudio(buff); > ... and then some time later > endAudio(); > free(buff); > > and such code doesn't include any gcc directives, are there any options that > would prevent gcc from moving any accesses to "buff" across volatile accesses > performed in beginAudio and endAudio? > Yes. Make "buff" volatile.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-05 13:04 -0700 |
| Message-ID | <062623bf-c030-4a6f-80f7-baad4296a966@googlegroups.com> |
| In reply to | #111572 |
On Monday, June 5, 2017 at 2:31:28 PM UTC-5, David Brown wrote:
> On 05/06/17 19:37, supercat wrote:
> > Also, does GCC have any option to presume that any volatile read or write
> > might behave as a call to an unknown function that could alter any objects
> > whose address has been exposed to the outside world? For example, if one
> > has code to perform asynchronous I/O functions and is supposed to support
> > usage like:
> >
> > buff = malloc(buffsize);
> > fread(buff, 1,buffsize, someFile);
> > beginAudio(buff);
> > ... and then some time later
> > endAudio();
> > free(buff);
> >
> > and such code doesn't include any gcc directives, are there any options that
> > would prevent gcc from moving any accesses to "buff" across volatile accesses
> > performed in beginAudio and endAudio?
> >
>
> Yes. Make "buff" volatile.
Even if `buff` is volatile, would anything in the Standard forbid a compiler
from tweaking the code into:
void volatile *volatile buff;
unsigned char *buf1; // Address returned from malloc
buf1 = malloc(buffsize);
buff = buf1;
fread(buff, 1,buffsize, someFile);
beginAudio(buff);
// Since storage from malloc isn't qualified volatile, its contents
// are not considered "observable" except when code dereferences a
// pointer that could legitimately access it.
for (int i=0; i<buffsize; i++)
buf1[i]++;
... and then some time later [with no "visible" accesses that could
... possibly involve "buf1"]
for (int i=0; i<buffsize; i++)
buf1[i]--;
endAudio();
free(buff);
Note that this code performs the same sequences of accesses to "buff" as the
original. Note also that if the memory that was used for "buff" (rather than
just the pointer) were volatile qualified, the fread() call would invoke
Undefined Behavior since its destination pointer is not volatile qualified.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-24 14:50 -0500 |
| Message-ID | <5tobic9jas07vvpp5fgsujfusk4nb2r104@4ax.com> |
| In reply to | #110523 |
On Tue, 23 May 2017 20:52:54 -0700 (PDT), joel.rees@gmail.com wrote: >On Wednesday, May 24, 2017 at 12:10:50 PM UTC+9, robert...@somewhere wrote: >> On Tue, 23 May 2017 18:46:12 -0700 (PDT), joel.rees@somewhere wrote: >> >------------- >> >makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat] >> >makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat] >> >------------- >> > >> >============= >> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n", >> > sizeof (ullongw_t), sizeof (ulongw_t) ); >> >============= >> > >> >I suppose I should cast the result of sizeof to int, since I don't know >> >what it will be compatible with on every target, and since I know it >> >will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints): >> > >> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n", >> > (int) sizeof (ullongw_t), (int) sizeof (ulongw_t) ); >> > >> >(Or, really, change the format to %u and the cast to (unsigned) .) >> > >> >I don't remember, when I wrote the code, whether I had some reason for >> >not doing so or had just gotten stuck on wondering what format specifier >> >would cover all possible types returned by sizeof. >> >> >> Again, not different in C++, just the compiler pointing out a problem. >> [...] > >Which I fixed by casting to (int), but changed my mind, and cast to >(unsigned), changing the format to %u. Either way, I know sizeof >will not return a negative number, and I know the types I am declaring >are all well less than 32,000 bytes in size. (All well less than 128 >bytes, really.) > >But you say, > >> As mentioned above, the correct format specifier for a size_t is %zu >> (in both C and C++). > >Which is definitely not available for at least two of the compilers I >want to (eventually) be able to compile this code. > >> %u is not portable in C either. >> [...] > >I do hope you mean no more portable than %d. It's not portable *without* a cast, since the actual type of size_t can vary.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-24 13:06 -0700 |
| Message-ID | <57689159-4501-4cbc-94dd-b04ae3580477@googlegroups.com> |
| In reply to | #110578 |
On Wednesday, May 24, 2017 at 2:50:24 PM UTC-5, robert...@yahoo.com wrote: > >> %u is not portable in C either. > >> [...] > > > >I do hope you mean no more portable than %d. > > It's not portable *without* a cast, since the actual type of size_t > can vary. The type of size_t would be irrelevant, unless it the *value* it yielded exceeded UINT_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-24 15:22 -0500 |
| Message-ID | <mfqbic9en6br8pf8lrgm6a2pnsr9vvnopu@4ax.com> |
| In reply to | #110582 |
On Wed, 24 May 2017 13:06:24 -0700 (PDT), supercat@casperkitty.com wrote: >On Wednesday, May 24, 2017 at 2:50:24 PM UTC-5, robert...@yahoo.com wrote: >> >> %u is not portable in C either. >> >> [...] >> > >> >I do hope you mean no more portable than %d. >> >> It's not portable *without* a cast, since the actual type of size_t >> can vary. > >The type of size_t would be irrelevant, unless it the *value* it yielded >exceeded UINT_MAX. If size_t is an unsigned long, and longs are bigger than ints on an implementation, %u (or %d) will likely attempt to process the wrong sized argument from the stack. The actual value is irrelevant. In some cases alignment rules* may allow the compiler to successfully access subsequent items (although that's certainly not guaranteed). In some cases (little endian systems) it may be possible to process smaller-than-UINT_MAX values "correctly" (with the ability to correctly access subsequent arguments being a different issue), but again, all details very dependent on the implementation. *For example, if 16-bit ints are 32-bit aligned on the parameter stack. Note that was *not* the case in MS-DOS/Windows 16-bit code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-24 13:30 -0700 |
| Message-ID | <c166c4a0-f367-4471-8aec-e4ba01e52df1@googlegroups.com> |
| In reply to | #110585 |
On Wednesday, May 24, 2017 at 3:22:30 PM UTC-5, robert...@yahoo.com wrote: > On Wed, 24 May 2017 13:06:24 -0700 (PDT), supercat wrote: > > >On Wednesday, May 24, 2017 at 2:50:24 PM UTC-5, robert...@yahoo.com wrote: > >> It's not portable *without* a cast, since the actual type of size_t > >> can vary. > > > >The type of size_t would be irrelevant, unless it the *value* it yielded > >exceeded UINT_MAX. > > If size_t is an unsigned long, and longs are bigger than ints on an > implementation, %u (or %d) will likely attempt to process the wrong > sized argument from the stack. The actual value is irrelevant. In > some cases alignment rules* may allow the compiler to successfully > access subsequent items (although that's certainly not guaranteed). In > some cases (little endian systems) it may be possible to process > smaller-than-UINT_MAX values "correctly" (with the ability to > correctly access subsequent arguments being a different issue), but > again, all details very dependent on the implementation. I cancelled my post almost immediately after writing it, but of course such cancellation is not always effective on Usenet. Sorry for any inconvenience.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-24 08:15 -0700 |
| Message-ID | <81606e67-7839-4228-8ae4-8f978a5e1071@googlegroups.com> |
| In reply to | #110522 |
On Tuesday, May 23, 2017 at 10:10:50 PM UTC-5, robert...@yahoo.com wrote: > > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n", > > sizeof (ullongw_t), sizeof (ulongw_t) ); > >============= > > > >I suppose I should cast the result of sizeof to int, since I don't know > >what it will be compatible with on every target, and since I know it > >will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints): > If you want to printf the result of sizeof, the best solution is to > use the %zu specifier, although that's a C99-ism. The z length > modifier to the u (unsigned integer format specifier) is specific to > sizeof. If yhou actually wanted to format an unsigned long, the > correct specifier is %lu. %d is simply incorrect for any unsigned > type, and for anything other than an int. The Standard specifies that using a signed-type pointer to read an object of the corresponding unsigned type, or vice versa, is fully-specified behavior in cases where the object being read has a value which is within the common range of the two types. While it does not explicitly mandate that printf implementations must treat use of %d, %u, and %x likewise, I see no reason to believe that such omission was intended as an invitation for implementations to do otherwise in the absence of a compelling reason to do so, and I doubt that they could imagine any reason that would be compelling on any conventional hardware. A bigger issue is that on system where "int" is 16 bits, system, size_t might be an unsigned long. Using %d to output a 32-bit value on a system where int is 16 bits could easily result in a malfunction (if memory serves, on the 68000, 16-bit pushes and pops bump the stack pointer by 4 bytes, just like 32-bit pushes and pops, but the 16-bit operations use the storage that would hold the upper 16 bits of 32-bit values). In cases where the number to be printed cannot exceed 32767, I would favor casting to "int" and using "%d"; if it might exceed 32767 but not 2147483647 I'd cast to "long" and use "%ld". Those approaches will be portable without reliance upon C99 library features.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 09:38 -0700 |
| Message-ID | <ln1srexla1.fsf@kst-u.example.com> |
| In reply to | #110547 |
supercat@casperkitty.com writes:
> On Tuesday, May 23, 2017 at 10:10:50 PM UTC-5, robert...@yahoo.com wrote:
[...]
>> If you want to printf the result of sizeof, the best solution is to
>> use the %zu specifier, although that's a C99-ism. The z length
>> modifier to the u (unsigned integer format specifier) is specific to
>> sizeof. If yhou actually wanted to format an unsigned long, the
>> correct specifier is %lu. %d is simply incorrect for any unsigned
>> type, and for anything other than an int.
>
> The Standard specifies that using a signed-type pointer to read an object of
> the corresponding unsigned type, or vice versa, is fully-specified behavior
> in cases where the object being read has a value which is within the common
> range of the two types.
>
> While it does not explicitly mandate that printf implementations must treat
> use of %d, %u, and %x likewise, I see no reason to believe that such omission
> was intended as an invitation for implementations to do otherwise in the
> absence of a compelling reason to do so, and I doubt that they could imagine
> any reason that would be compelling on any conventional hardware.
The standard explicitly says (N1570 7.21.6.1p9):
If any argument is not the correct type for the corresponding
conversion specification, the behavior is undefined.
There might be some amiguity about what "the correct type" means. A
conforming compiler could recognize something like `printf("%u\n", 42)`
as incorrect and issue a warning, or in principle even reject it.
On the other hand, a non-normative footnote in 6.2.5p9, discussing the
representation of corresponding signed and unsigned types, says:
The same representation and alignment requirements are meant
to imply interchangeability as arguments to functions, return
values from functions, and members of unions.
It will almost certainly work, as long as the value is within the range
of both types, but there is *no* good reason to depend on that. Just
use the correct format.
> A bigger issue is that on system where "int" is 16 bits, system, size_t
> might be an unsigned long. Using %d to output a 32-bit value on a system
> where int is 16 bits could easily result in a malfunction (if memory serves,
> on the 68000, 16-bit pushes and pops bump the stack pointer by 4 bytes,
> just like 32-bit pushes and pops, but the 16-bit operations use the storage
> that would hold the upper 16 bits of 32-bit values).
>
> In cases where the number to be printed cannot exceed 32767, I would favor
> casting to "int" and using "%d"; if it might exceed 32767 but not 2147483647
> I'd cast to "long" and use "%ld". Those approaches will be portable without
> reliance upon C99 library features.
My preference (assuming I can't depend on support for "%zu") is to cast
to unsigned long and use "%lu", even if I happen to know that the value
is small. It saves me the trouble of thinking about what the value is
going to be. The advantage of `printf("%d\n", (int)sizeof foo)` over
`printf("%lu\n", (unsigned long)sizeof foo)` is minimal, and in my
opinion is overridden by the advantage of consistency.
Note that it's theoretically possible that "%lu" could print an
incorrect value, but only if the size being printed exceeds ULONG_MAX,
which is at least 2**31-1. That can only happen if size_t is wider than
unsigned long long; I know of no existing implementation where that's
the case.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-26 17:24 -0700 |
| Message-ID | <kfntw47f8ov.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110560 |
Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
>> On Tuesday, May 23, 2017 at 10:10:50 PM UTC-5, robert...@yahoo.com wrote:
>
> [...]
>
>>> If you want to printf the result of sizeof, the best solution is
>>> to use the %zu specifier, although that's a C99-ism. The z length
>>> modifier to the u (unsigned integer format specifier) is specific
>>> to sizeof. If yhou actually wanted to format an unsigned long,
>>> the correct specifier is %lu. %d is simply incorrect for any
>>> unsigned type, and for anything other than an int.
>>
>> The Standard specifies that using a signed-type pointer to read an
>> object of the corresponding unsigned type, or vice versa, is
>> fully-specified behavior in cases where the object being read has a
>> value which is within the common range of the two types.
>>
>> While it does not explicitly mandate that printf implementations
>> must treat use of %d, %u, and %x likewise, I see no reason to
>> believe that such omission was intended as an invitation for
>> implementations to do otherwise in the absence of a compelling
>> reason to do so, and I doubt that they could imagine any reason
>> that would be compelling on any conventional hardware.
>
> The standard explicitly says (N1570 7.21.6.1p9):
>
> If any argument is not the correct type for the corresponding
> conversion specification, the behavior is undefined.
>
> There might be some amiguity about what "the correct type" means. A
> conforming compiler could recognize something like `printf("%u\n", 42)`
> as incorrect and issue a warning, or in principle even reject it.
This conclusion depends on an interpretation that not everyone
agrees with. I believe that interpretation is not what was
intended (see below), and that a different interpretation holds
that would make this printf() call be strictly conforming (ie,
and so could not be rejected).
> On the other hand, a non-normative footnote in 6.2.5p9, discussing the
> representation of corresponding signed and unsigned types, says:
>
> The same representation and alignment requirements are meant
> to imply interchangeability as arguments to functions, return
> values from functions, and members of unions.
More pointedly, 7.16.1.1 p2 (7.15.1.1 p2 in n1256) lists these
cases where behavior is defined (that is, normatively defined):
* one type is a signed integer type, the other type is the
corresponding unsigned integer type, and the value is
representable in both types;
* one type is pointer to void and the other is a pointer to
a character type.
These descriptions apply to uses of the va_arg() macro, which is
used for getting argument values in variadic function calls.
Since printf() is a variadic function, it seems reasonable to
posit that these provisions apply also to values being formatted
with printf().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-26 18:37 -0700 |
| Message-ID | <lnh907t701.fsf@kst-u.example.com> |
| In reply to | #110775 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> On the other hand, a non-normative footnote in 6.2.5p9, discussing the
>> representation of corresponding signed and unsigned types, says:
>>
>> The same representation and alignment requirements are meant
>> to imply interchangeability as arguments to functions, return
>> values from functions, and members of unions.
>
> More pointedly, 7.16.1.1 p2 (7.15.1.1 p2 in n1256) lists these
> cases where behavior is defined (that is, normatively defined):
>
> * one type is a signed integer type, the other type is the
> corresponding unsigned integer type, and the value is
> representable in both types;
>
> * one type is pointer to void and the other is a pointer to
> a character type.
Ah, I missed that.
> These descriptions apply to uses of the va_arg() macro, which is
> used for getting argument values in variadic function calls.
> Since printf() is a variadic function, it seems reasonable to
> posit that these provisions apply also to values being formatted
> with printf().
If I really wanted to be pedantic, I might argue that although
printf() is a variadic function, there's no requirement that
its implementation must use va_arg() to process its arguments.
It might use some other mechanism that satisfies the requirements of
7.21.6.1 and .3 (fprintf and printf), but not all the requirements
of 7.16.1.1. That could even be plausible if printf() is implemented
in a language other than C.
Still, it would take a particularly perverse implementation to make
printf("%u\n", 42) do something other than printing "42". I'd say the
possibility is not worth worrying about. On the other hand, I'd also
say that it's silly to use "%u" rather than "%d" in the first place.
And if I want to print a signed value in hexadecimal, I'll probably
still cast it to an unsigned type, even though it's almost certainly
unnecessary.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-28 18:44 -0700 |
| Message-ID | <kfn8tlgfndo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110782 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> On the other hand, a non-normative footnote in 6.2.5p9, discussing the
>>> representation of corresponding signed and unsigned types, says:
>>>
>>> The same representation and alignment requirements are meant
>>> to imply interchangeability as arguments to functions, return
>>> values from functions, and members of unions.
>>
>> More pointedly, 7.16.1.1 p2 (7.15.1.1 p2 in n1256) lists these
>> cases where behavior is defined (that is, normatively defined):
>>
>> * one type is a signed integer type, the other type is the
>> corresponding unsigned integer type, and the value is
>> representable in both types;
>>
>> * one type is pointer to void and the other is a pointer to
>> a character type.
>
> Ah, I missed that.
>
>> These descriptions apply to uses of the va_arg() macro, which is
>> used for getting argument values in variadic function calls.
>> Since printf() is a variadic function, it seems reasonable to
>> posit that these provisions apply also to values being formatted
>> with printf().
>
> If I really wanted to be pedantic, I might argue that although
> printf() is a variadic function, there's no requirement that
> its implementation must use va_arg() to process its arguments.
True enough, but I'm not supposing that there is. What I'm saying
is that it's reasonable to guess the same rules apply (ie, were
meant to apply) for printf() arguments as apply for the va_arg()
macro, regardless of how printf() might be implemented.
> It might use some other mechanism that satisfies the requirements of
> 7.21.6.1 and .3 (fprintf and printf), but not all the requirements
> of 7.16.1.1. That could even be plausible if printf() is implemented
> in a language other than C.
Here you are glossing over the very point I mean to address, which
is: What /are/ the requirements for fprintf() (and printf(), etc)?
In particular, where the Standard says, "If any argument is not the
correct type for the corresponding conversion specification", is
that meant to be determined under the same rules as for va_arg()?
IMO that is the most plausible interpretation. But, even if you
don't agree this interpretation is the /most/ plausible, I expect
you will agree that it is /a/ plausible interpretation. That's all
I'm saying.
> Still, it would take a particularly perverse implementation to make
> printf("%u\n", 42) do something other than printing "42". I'd say the
> possibility is not worth worrying about. On the other hand, I'd also
> say that it's silly to use "%u" rather than "%d" in the first place.
>
> And if I want to print a signed value in hexadecimal, I'll probably
> still cast it to an unsigned type, even though it's almost certainly
> unnecessary.
There's an undercurrent in these statements that I find somewhat
philosophically disquieting. We shouldn't try to sweep ambiguities
in the Standard under the rug. On the contrary, they should be
brought out into the bright light of a sunny day, and held up so
they can be resolved one way or the other. I think it's a mistake
to adopt an attitude that it's okay for the Standard to be "mushy".
(Let me be clear that I'm not saying you have this attitude, only
that it's not a good attitude to have.)
After the ambiguity is resolved, if someone wants to use casts to
align argument types more exactly, then by all means they should do
so. But first let's be sure what the rules are, and only then
decide what programming actions should be taken to accommodate
them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-26 17:28 -0700 |
| Message-ID | <kfnpoevf8iu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110560 |
Keith Thompson <kst-u@mib.org> writes: > Note that it's theoretically possible that "%lu" could print an > incorrect value, but only if the size being printed exceeds > ULONG_MAX, which is at least 2**31-1. That can only happen if > size_t is wider than unsigned long long; I know of no existing > implementation where that's the case. P.S. Your calculations are a little bit off there.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-26 18:37 -0700 |
| Message-ID | <lnd1avt6yx.fsf@kst-u.example.com> |
| In reply to | #110777 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Note that it's theoretically possible that "%lu" could print an
>> incorrect value, but only if the size being printed exceeds
>> ULONG_MAX, which is at least 2**31-1. That can only happen if
>> size_t is wider than unsigned long long; I know of no existing
>> implementation where that's the case.
>
> P.S. Your calculations are a little bit off there.
Quite right: 2**32-1.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 08:43 -0700 |
| Message-ID | <lnmva2xnu4.fsf@kst-u.example.com> |
| In reply to | #110522 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Tue, 23 May 2017 18:46:12 -0700 (PDT), joel.rees@gmail.com wrote:
[...]
>>Anyway, changing the name array declarations to
>>
>> char const * prPtrTpDecs[] =
>>
>>clears that warning.
>>
>>(I have never been able to get comfortable with the position of the
>>"const" declaration in this kind of declaration.)
>
> This is a difference in C++, string literals are const, so assigning
> them to a non-const pointer is worthy of a warning. OTOH, it's
> undefined to actually modify a string literal in C.
And in C it's best to avoid constructing a non-const char* pointer into
a string literal. This:
char *p = "hello";
illegal in C++ and legal in C, but it's a bad idea even in C, since it
makes it possible to accidentally attempt to modify the string literal.
Adding a const:
const char *p = "hello";
makes it valid and safer in both languages.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-24 14:08 +0100 |
| Message-ID | <8737buv1vc.fsf@bsb.me.uk> |
| In reply to | #110518 |
joel.rees@gmail.com writes:
<snip>
> https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/configs/makecelltype.c
<snip>
> I had the impression from my previous reading that (char *) was the base
> pointer type in C, and perhaps that is why I remembered malloc() as
> returning that type.
In the days before C had void, malloc did return char *.
<snip>
> -------------
> makecelltype.c:92:44: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> -------------
>
> I was thinking to just show the declarations and lines 91 and 92, but
> this is one of those places where context is everything:
>
> =============
> typedef unsigned char ubyte_t;
> typedef signed char sbyte_t;
>
> int probe_byte( FILE * outfile, typeBits_t * bits )
> { ubyte_t uch = (ubyte_t) -1;
> sbyte_t schmax = (sbyte_t) (uch >> 1);
I prefer
ubyte_t uch = -1;
sbyte_t schmax = uch >> 1;
but to cover the full range of possibilities you need to use limits.h.
You say (in another post) that you want the support the widest range of
targets and yet you don't want to use limits.h that is designed to help
you do that.
> unsigned long memory = 0;
> int ui = 0;
> int status = 0;
>
> /* Must be identical to the two types declared above: */
> fputs( "typedef unsigned char ubyte_t;\n", outfile );
> fputs( "typedef signed char sbyte_t;\n", outfile );
> fputs( "/* For now, assuming two's complement: */\n", outfile );
> fprintf( outfile, "#define UBYTE_MAX ((ubyte_t) 0x%x)\n", uch );
> for ( uch = (ubyte_t) -1, ui = 0;
> ( ui <= 1024 ) && ( uch != 0 );
> )
> { memory = uch;
> uch <<= 1;
> ++ui;
> }
Since you are not using the full for-loop, I'd write
while (ui <= 1024 && uch != 0) {
memory = uch;
uch <<= 1;
++ui;
}
(don't worry about my choice of layout, but I would consider removing
the brackets as I have. Can you give 1024 and name? It would help
explain it.)
> if ( ui != CHAR_BIT )
> { status = -1;
> fprintf( outfile, "#error \"*** C CHAR_BIT is %d but actual byte width is %d. ***\"\n", CHAR_BIT, ui );
> }
> bits->byteSize = ui;
> fprintf( outfile, "#define BITSPERBYTE %d\n", ui );
> fprintf( outfile, "#define BYTE_HIGH_BIT ((ubyte_t) 0x%x)\n",
> (ubyte_t) memory );
These casts may be giving you a false sense of what's happening. They
certainly give me a false sense of what you expect.
memory is in the range of ubyte_t so the cast of it has no effect on the
value. And it will get promoted to int with the cast and, technically,
%x needs an unsigned. Personally, I'd use the right format for its
type: %lx and drop the cast. I'd also drop the cast on the generated
define or explain with a comment why you need it.
> if ( ( schmax != ((ubyte_t) ~memory) )
> || ( ( ((ubyte_t) schmax) + 1 ) != memory ) ) /**** line 92 ***/
> { status = -1;
> fputs( "#error \"*** Not two's complement! Needs fixing. ***\"\n",
> outfile );
I haven't checked all this but it seems to be designed to detect
non-two's complement implementations. A common way to detect the signed
integer representation is the look at the value of -3 % 3.
> fprintf( outfile, "#error \"filled bit shifted right: %x, rollover: %x\"\n",
> schmax, ((ubyte_t) schmax) + 1 );
> fprintf( outfile, "#error \"1 max shifted left: %x, inverted: %x\"\n",
> ((ubyte_t) memory), ((ubyte_t) ~memory) );
> }
> fprintf( outfile, "#define SBYTE_MAX ((sbyte_t) 0x%x)\n",
> (ubyte_t) schmax );
> fputs( "#define SBYTE_MIN ((sbyte_t) BYTE_HIGH_BIT)\n\n\n", outfile );
> return status;
> }
> =============
>
> I need those bit patterns to be compared exactly, and I'm depending on
> C's type promotion to get this right.
That's an odd way of putting it. It's up to you to get it right!
> I'm not confident that I know the correct C++ cast to avoid unwanted
> sign extension or suppression.
Pass. I think C++'s rules are the same, but I don't see the point in
worrying about getting your C code through a C++ compiler. (There are
reasons to do this, but I think you are just curious.)
> This code occurs several other times in this configuration file, for
> short, int, long, and long long. I'm getting this warning in each
> place.
I'd have to look at the code because the promotion rules are type
dependent, but I can't see why you are not just doing
(SCHAR_MAX >> 1) + 1
to get the top value bit.
> -------------
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat]
> -------------
>
> =============
> fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> sizeof (ullongw_t), sizeof (ulongw_t) );
> =============
>
> I suppose I should cast the result of sizeof to int, since I don't know
> what it will be compatible with on every target, and since I know it
> will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints):
>
> fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> (int) sizeof (ullongw_t), (int) sizeof (ulongw_t) );
>
> (Or, really, change the format to %u and the cast to (unsigned) .)
If you can rely on C99, you can use the format for size_t: %zu.
<snip>
> Then there are several that look like this:
>
> --------------
> makecelltype.c:380:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> --------------
>
> ==============
> char const * header[] = /* edited to char const * as mentioned above. */
> {
> "/*",
> "** %s",
> "** bif-c",
> "**",
> "** Template created by Joel Rees on 2013/06/18.",
> "** Copyright 2013 __Reiisi_Kenkyuu__. All rights reserved.",
> "**",
> "** Type information for cell proto-type.",
> "*/\n\n"
> };
> [...]
> for ( i = 0; i < sizeof header / sizeof header[ 0 ] ; ++i )
> ==============
>
> Again, this must be the difference in type promotion between C and
> C++.
I don't think so (in fact I'm pretty sure). Maybe you were not asking
for enough warnings from your C compiler?
> Parenthesis:
>
> for ( i = 0; i < ( sizeof header / sizeof header[ 0 ] ) ; ++i )
>
> doesn't fix it. Changing i to size_t fixes some of those and produces
> other errors.
Here, the warnings are useful in that you need to check that the test is
safe but once you do you can either ignore the warnings or fix one or
other type in the <.
> Letting the type change cascade back, to a variable
> named ptrSize, which I mentioned in the other thread, fixes more
> warnings, but now gives me warnings about printf() formats such as I
> mentioned above, which I can fix by casting ptrSize to (int) in the
> printf() argument lists.
Yes. If you can't ignore the warnings, the minimal change would be to
cast sizeof header / sizeof header[0] to int. If you do this sort of
loop a lot you could provide a macro.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-24 17:17 -0700 |
| Message-ID | <4b9ed40d-09ca-422c-92db-9c97eb55e37d@googlegroups.com> |
| In reply to | #110538 |
On Wednesday, May 24, 2017 at 10:08:39 PM UTC+9, Ben Bacarisse wrote:
> joel.rees@someplace writes:
> <snip>
> > https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/configs/makecelltype.c
> <snip>
> > I had the impression from my previous reading that (char *) was the base
> > pointer type in C, and perhaps that is why I remembered malloc() as
> > returning that type.
>
> In the days before C had void, malloc did return char *.
Come to think of it, I probably left the cast out because I wanted to
keep some degree of compatibility with compilers that had such libraries.
It's been a long time since I wrote that code, really.
And even longer since I wrote the original headers that I couldn't
figure out how to get to work with everything I was trying to compile
on.
> <snip>
> > -------------
> > makecelltype.c:92:44: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> > -------------
> >
> > I was thinking to just show the declarations and lines 91 and 92, but
> > this is one of those places where context is everything:
> >
> > =============
> > typedef unsigned char ubyte_t;
> > typedef signed char sbyte_t;
> >
> > int probe_byte( FILE * outfile, typeBits_t * bits )
> > { ubyte_t uch = (ubyte_t) -1;
> > sbyte_t schmax = (sbyte_t) (uch >> 1);
>
> I prefer
>
> ubyte_t uch = -1;
> sbyte_t schmax = uch >> 1;
>
> but to cover the full range of possibilities you need to use limits.h.
> You say (in another post) that you want the support the widest range of
> targets and yet you don't want to use limits.h that is designed to help
> you do that.
Well, to tell the truth, I'm trying, ultimately, to deal with compilers
whose limits.h tell "white lies".
> > unsigned long memory = 0;
> > int ui = 0;
> > int status = 0;
> >
> > /* Must be identical to the two types declared above: */
> > fputs( "typedef unsigned char ubyte_t;\n", outfile );
> > fputs( "typedef signed char sbyte_t;\n", outfile );
> > fputs( "/* For now, assuming two's complement: */\n", outfile );
> > fprintf( outfile, "#define UBYTE_MAX ((ubyte_t) 0x%x)\n", uch );
> > for ( uch = (ubyte_t) -1, ui = 0;
> > ( ui <= 1024 ) && ( uch != 0 );
> > )
> > { memory = uch;
> > uch <<= 1;
> > ++ui;
> > }
>
> Since you are not using the full for-loop, I'd write
>
> while (ui <= 1024 && uch != 0) {
> memory = uch;
> uch <<= 1;
> ++ui;
> }
You know, I probably spent an hour or two playing with both approaches.
I chose that one that seemed clearer to me at the time, and it still
seems clearer to me now.
> (don't worry about my choice of layout, but I would consider removing
> the brackets as I have. Can you give 1024 and name? It would help
> explain it.)
Braces. Don't talk to me about my braces and I won't talk to you about
yours. ;)
I know that all the fashionable tools expect the braces out on the
right, but I find it much easier to use braces to show me whether my
nesting is correct by putting the opening brace on the left where I
can line them up by eyeballing them.
There are tools that can move the braces for me when I need to make
my source available to projects that ask for the braces on the right,
and I can work with them on the right if I have to. This code is mine,
I'll put the braces where it's most convenient for me.
> > if ( ui != CHAR_BIT )
> > { status = -1;
> > fprintf( outfile, "#error \"*** C CHAR_BIT is %d but actual byte width is %d. ***\"\n", CHAR_BIT, ui );
> > }
> > bits->byteSize = ui;
> > fprintf( outfile, "#define BITSPERBYTE %d\n", ui );
> > fprintf( outfile, "#define BYTE_HIGH_BIT ((ubyte_t) 0x%x)\n",
> > (ubyte_t) memory );
>
> These casts may be giving you a false sense of what's happening. They
> certainly give me a false sense of what you expect.
>
> memory is in the range of ubyte_t so the cast of it has no effect on the
> value. And it will get promoted to int with the cast and, technically,
> %x needs an unsigned. Personally, I'd use the right format for its
> type: %lx and drop the cast. I'd also drop the cast on the generated
> define or explain with a comment why you need it.
I think the cast on memory was probably a left-over habit from trying to
get some compilers to refrain from sign-extending memory in the
conversion to int. I don't remember which compilers did that, but there
sure were some.
Theoretically, that should just be a cast to unsigned, but some compilers
I tried when I wrote this code were insisting that %x and unsigned did
not match. MSB first architectures ended up printing the size as zero
or something. Or maybe they printed the return address. I don't remember.
> > if ( ( schmax != ((ubyte_t) ~memory) )
> > || ( ( ((ubyte_t) schmax) + 1 ) != memory ) ) /**** line 92 ***/
> > { status = -1;
> > fputs( "#error \"*** Not two's complement! Needs fixing. ***\"\n",
> > outfile );
>
> I haven't checked all this but it seems to be designed to detect
> non-two's complement implementations. A common way to detect the signed
> integer representation is the look at the value of -3 % 3.
There's a nice math puzzle. I'm wondering how different compiler choices
about the way the modulo is calculated will complicate interpreting the
result, however.
> > fprintf( outfile, "#error \"filled bit shifted right: %x, rollover: %x\"\n",
> > schmax, ((ubyte_t) schmax) + 1 );
> > fprintf( outfile, "#error \"1 max shifted left: %x, inverted: %x\"\n",
> > ((ubyte_t) memory), ((ubyte_t) ~memory) );
> > }
> > fprintf( outfile, "#define SBYTE_MAX ((sbyte_t) 0x%x)\n",
> > (ubyte_t) schmax );
> > fputs( "#define SBYTE_MIN ((sbyte_t) BYTE_HIGH_BIT)\n\n\n", outfile );
> > return status;
> > }
> > =============
> >
> > I need those bit patterns to be compared exactly, and I'm depending on
> > C's type promotion to get this right.
>
> That's an odd way of putting it. It's up to you to get it right!
Maybe I should say I'm hoping C's type promotion will refrain from
misinterpreting what I wrote.
> > I'm not confident that I know the correct C++ cast to avoid unwanted
> > sign extension or suppression.
>
> Pass. I think C++'s rules are the same, but I don't see the point in
> worrying about getting your C code through a C++ compiler. (There are
> reasons to do this, but I think you are just curious.)
Well, actually, it helps me shine light on the various ways the code
can be misinterpreted.
I was talking about two or three architectures, but I'm trying to
eventually produce code that I can compile without changes on modern
and archaic compilers. I'm kind of hoping I can get it to even compile
on dead 8-bit CPUs, but it may end up with object code that is too
large to allow me to use it for bootstrapping a real Forth interpreter.
> > This code occurs several other times in this configuration file, for
> > short, int, long, and long long. I'm getting this warning in each
> > place.
>
> I'd have to look at the code because the promotion rules are type
> dependent, but I can't see why you are not just doing
>
> (SCHAR_MAX >> 1) + 1
>
> to get the top value bit.
Because I'm really not interested in what the C run-time wants to do.
> > -------------
> > makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
> > makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat]
> > -------------
> >
> > =============
> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> > sizeof (ullongw_t), sizeof (ulongw_t) );
> > =============
> >
> > I suppose I should cast the result of sizeof to int, since I don't know
> > what it will be compatible with on every target, and since I know it
> > will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints):
> >
> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> > (int) sizeof (ullongw_t), (int) sizeof (ulongw_t) );
> >
> > (Or, really, change the format to %u and the cast to (unsigned) .)
>
> If you can rely on C99, you can use the format for size_t: %zu.
Can't rely on that.
> <snip>
> > Then there are several that look like this:
> >
> > --------------
> > makecelltype.c:380:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> > --------------
> >
> > ==============
> > char const * header[] = /* edited to char const * as mentioned above. */
> > {
> > "/*",
> > "** %s",
> > "** bif-c",
> > "**",
> > "** Template created by Joel Rees on 2013/06/18.",
> > "** Copyright 2013 __Reiisi_Kenkyuu__. All rights reserved.",
> > "**",
> > "** Type information for cell proto-type.",
> > "*/\n\n"
> > };
> > [...]
> > for ( i = 0; i < sizeof header / sizeof header[ 0 ] ; ++i )
> > ==============
> >
> > Again, this must be the difference in type promotion between C and
> > C++.
>
> I don't think so (in fact I'm pretty sure). Maybe you were not asking
> for enough warnings from your C compiler?
Well, I usually compile with "-Wall", but there are stricter warnings.
But doesn't size_t divided by size_t get promoted to int?
Now that I put it that way, I suppose not.
> > Parenthesis:
> >
> > for ( i = 0; i < ( sizeof header / sizeof header[ 0 ] ) ; ++i )
> >
> > doesn't fix it. Changing i to size_t fixes some of those and produces
> > other errors.
>
> Here, the warnings are useful in that you need to check that the test is
> safe but once you do you can either ignore the warnings or fix one or
> other type in the <.
>
> > Letting the type change cascade back, to a variable
> > named ptrSize, which I mentioned in the other thread, fixes more
> > warnings, but now gives me warnings about printf() formats such as I
> > mentioned above, which I can fix by casting ptrSize to (int) in the
> > printf() argument lists.
>
> Yes. If you can't ignore the warnings, the minimal change would be to
> cast sizeof header / sizeof header[0] to int. If you do this sort of
> loop a lot you could provide a macro.
>
> <snip>
> --
> Ben.
Thanks. I think I'm ready to move on to the interpreter itself.
--
Joel Rees
Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web