Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92512 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-08-19 14:22 -0700 |
| Last post | 2016-08-22 05:11 -0700 |
| Articles | 20 on this page of 355 — 30 participants |
Back to article view | Back to comp.lang.c
Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:22 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 09:36 +1200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:48 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:56 -0700
Re: Default values in #define Chad <cdalten@gmail.com> - 2016-08-22 07:56 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 17:09 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:47 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:55 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 09:27 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 09:41 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 20:19 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 12:54 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:14 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:23 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 05:42 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:52 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 06:01 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:06 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:56 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:59 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-23 10:42 -0700
Re: Default values in #define matt@godbolt.org - 2016-08-23 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:57 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:31 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:06 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:15 -0700
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 13:26 +0100
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:07 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-06 06:22 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 00:50 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-07 06:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 01:44 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-08 06:58 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:16 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:47 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:49 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:52 -0800
Re: Default values in #define asetofsymbols@gmail.com - 2016-12-09 00:52 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:19 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-07 04:43 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 14:18 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 07:22 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 08:00 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 22:14 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 13:44 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:07 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 17:00 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 17:46 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:37 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-10 09:42 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 10:05 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:51 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 04:40 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 03:15 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-12 16:12 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 01:45 -0600
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 16:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 10:25 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 10:50 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 04:02 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 13:14 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:57 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 14:32 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:58 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:21 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 14:41 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:47 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 16:24 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:30 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:12 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:21 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 15:02 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 13:19 -0800
Petty and unprofessional (Was: Default values in #define) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-13 16:46 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 09:04 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 20:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:19 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-13 11:33 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:44 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-14 10:04 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:37 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:28 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:23 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:10 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:54 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:57 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:53 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 05:59 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:03 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:22 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 17:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 18:37 -0800
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:25 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 07:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:35 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 09:17 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 11:03 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 11:41 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 12:31 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 13:13 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-12 20:22 +0000
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 07:10 -0800
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:21 -0800
Re: Default values in #define jameskuyper@verizon.net - 2016-12-11 10:33 -0800
Re: Default values in #define Melzzzzz <mel@zzzzz.com> - 2016-12-11 16:22 +0100
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:16 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 13:54 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 14:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:11 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:49 -0700
Re: Default values in #define Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-21 05:50 -0600
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-21 13:10 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 12:56 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 21:11 +0100
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-22 15:47 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 11:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 20:07 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 14:30 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-24 06:25 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 10:34 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-24 08:50 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 15:37 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 11:58 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 01:27 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 22:28 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 23:38 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:44 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 07:29 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 07:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:26 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 11:11 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 12:03 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:31 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 09:28 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 22:51 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 16:35 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 01:44 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 10:06 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:41 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:24 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:32 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-30 22:30 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 09:17 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:46 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 10:29 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:12 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 12:30 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 11:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:56 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 08:17 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:18 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:34 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 00:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:19 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 11:38 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 10:03 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 10:31 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 12:50 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 21:30 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:37 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 08:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-06 07:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:54 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-02 08:40 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 10:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 15:16 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-25 08:28 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 00:54 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 01:00 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 11:17 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 04:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 13:45 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:09 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:11 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:31 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:48 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:50 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:01 +0200
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 10:57 -0700
Re: Default values in #define Ike Naar <ike@iceland.freeshell.org> - 2016-08-31 06:09 +0000
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 12:24 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:39 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:49 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:51 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:46 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-26 17:37 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 15:05 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 10:25 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 16:25 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 18:12 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 13:47 +1200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 19:32 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:54 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:11 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 18:25 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:11 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 06:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:16 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:17 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:26 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:10 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:35 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:28 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 15:38 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 13:27 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 16:42 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:16 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 17:24 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:21 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 08:12 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 15:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:53 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:34 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 14:44 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 12:48 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:19 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 11:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:33 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:51 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:46 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 16:26 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-03 17:31 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:03 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:36 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:30 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:39 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 03:57 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 15:34 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 07:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:46 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:03 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:52 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 07:41 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 14:58 -0400
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:27 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:05 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:15 -0700
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-09-02 22:22 +0200
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-28 08:41 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:34 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:41 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 08:07 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:08 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 15:41 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:30 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:14 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 23:37 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:19 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:26 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 04:40 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:56 +0200
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 15:43 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 19:34 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 00:51 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 20:36 +1200
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-08-31 00:39 -0500
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 21:40 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:22 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 11:36 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:26 -0800
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-27 06:34 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 12:48 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:12 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:10 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:18 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 10:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:49 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:13 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:48 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:14 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 08:59 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:43 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-29 22:58 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-30 07:14 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 00:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 00:26 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:10 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 10:47 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 03:32 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:38 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:44 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 14:00 +0200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 18:55 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:24 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 14:11 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 16:28 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 16:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-31 06:27 +0100
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 23:09 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 16:06 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:35 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:30 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:40 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:17 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:58 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 09:09 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:16 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:49 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:31 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:24 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:29 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 10:02 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:33 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 14:12 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 14:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:27 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 23:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 14:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:32 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:33 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:13 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:35 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 19:08 +0100
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-08-24 09:05 +0200
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-24 00:49 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-24 05:40 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-19 22:56 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 10:14 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 18:09 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 13:15 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 19:10 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 14:50 +1200
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 10:35 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-20 03:13 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 12:24 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-21 00:14 +1200
Re: Default values in #define gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-20 14:13 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:17 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:14 -0700
Re: Default values in #define Philipp Klaus Krause <pkk@spth.de> - 2016-08-21 12:51 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:11 -0700
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-22 12:56 -0700 |
| Message-ID | <a60b8751-0ae6-4796-abee-5a88ff0630fd@googlegroups.com> |
| In reply to | #92602 |
On Monday, August 22, 2016 at 2:19:32 PM UTC-5, Ben Bacarisse wrote:
> I see a problem even without the array. At first glance it looks like a
> bug. Have you communicated with the clang people to see if they think
> it's a bug? My test case was:
>
> #include <stdint.h>
> #include <stdio.h>
>
> union U {long long l; int64_t ll;};
>
> long long f(union U *p1, union U *p2)
> {
> p2->l = 42;
> p1->ll = 0;
> return p2->l;
> }
>
> int main(void)
> {
> union U u;
> printf("%lld\n", f(&u, &u));
> }
>
> prints 42 with clang -std=c11 -pedantic -O2 (version 3.6.2-1). Is this
> what you mean or are you describing something else?
That seems like the issue, though I'd noticed the issue first when testing
with two arrays (which used to be an accepted way of handling cases where
data will sometimes be read with one sized of chunk and written as another).
I hadn't thought clang would go so far as to ignore the possibility of
aliasing with directly-accessed lvalue members.
The problem, of course, is that while the authors of the Standard have
sought to avoid defining behaviors that might not be meaningful on
absolutely all platforms, modern compiler writers treat the Standard as
passing judgement on whether quality implementations should support
behaviors on platforms where they are meaningful. Given that the Standard
makes no effort to forbid conforming-but-useless implementations in other
respects, there's no reason the Standard should have to mandate that an
implementation where "long long" and "int64_t" have identical representations
should recognize aliasing between them, especially when both appear in the
same union. Good quality implementations will recognize such aliasing, and
poor quality implementations could find some other excuse to behave in
arbitrary function any time such aliasing would be relevant.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-22 21:11 +0100 |
| Message-ID | <87fupwtvgo.fsf@bsb.me.uk> |
| In reply to | #92604 |
supercat@casperkitty.com writes:
> On Monday, August 22, 2016 at 2:19:32 PM UTC-5, Ben Bacarisse wrote:
>> I see a problem even without the array. At first glance it looks like a
>> bug. Have you communicated with the clang people to see if they think
>> it's a bug? My test case was:
>>
>> #include <stdint.h>
>> #include <stdio.h>
>>
>> union U {long long l; int64_t ll;};
>>
>> long long f(union U *p1, union U *p2)
>> {
>> p2->l = 42;
>> p1->ll = 0;
>> return p2->l;
>> }
>>
>> int main(void)
>> {
>> union U u;
>> printf("%lld\n", f(&u, &u));
>> }
>>
>> prints 42 with clang -std=c11 -pedantic -O2 (version 3.6.2-1). Is this
>> what you mean or are you describing something else?
>
> That seems like the issue,
<snip>
> The problem, of course, is that while the authors of the Standard have
> sought to avoid defining behaviors that might not be meaningful on
> absolutely all platforms, modern compiler writers...
...and off you go. Have you asked if the clang people think this is a
bug or not?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-22 15:47 -0700 |
| Message-ID | <lnoa4kfmkv.fsf@kst-u.example.com> |
| In reply to | #92604 |
supercat@casperkitty.com writes:
> On Monday, August 22, 2016 at 2:19:32 PM UTC-5, Ben Bacarisse wrote:
>> I see a problem even without the array. At first glance it looks like a
>> bug. Have you communicated with the clang people to see if they think
>> it's a bug? My test case was:
>>
>> #include <stdint.h>
>> #include <stdio.h>
>>
>> union U {long long l; int64_t ll;};
>>
>> long long f(union U *p1, union U *p2)
>> {
>> p2->l = 42;
>> p1->ll = 0;
>> return p2->l;
>> }
>>
>> int main(void)
>> {
>> union U u;
>> printf("%lld\n", f(&u, &u));
>> }
>>
>> prints 42 with clang -std=c11 -pedantic -O2 (version 3.6.2-1). Is this
>> what you mean or are you describing something else?
>
> That seems like the issue, though I'd noticed the issue first when testing
> with two arrays (which used to be an accepted way of handling cases where
> data will sometimes be read with one sized of chunk and written as another).
> I hadn't thought clang would go so far as to ignore the possibility of
> aliasing with directly-accessed lvalue members.
>
> The problem, of course, is that while the authors of the Standard have
> sought to avoid defining behaviors that might not be meaningful on
> absolutely all platforms, modern compiler writers treat the Standard as
> passing judgement on whether quality implementations should support
> behaviors on platforms where they are meaningful.
The problem, of course, is that Clang apparently has a bug.
The C standard has a footnote in section 6.5.2.3:
If the member used to read the contents of a union object is
not the same as the member last used to store a value in the
object, the appropriate part of the object representation of
the value is reinterpreted as an object representation in the
new type as described in 6.2.6 (a process sometimes called
"type punning"). This might be a trap representation.
I can confirm that the bug occurs with clang 3.8.1 on x86-64
(with -O2, but not with -O1). int64_t is defined as long. If I
change long long to long in the program (they have the same size
and representation), the problem goes away.
Not everything is about the vast conspiracy to produce deliberately
useless compilers.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-23 11:54 -0700 |
| Message-ID | <1d377167-a33a-402e-89ee-d3efa06d95ab@googlegroups.com> |
| In reply to | #92606 |
On Monday, August 22, 2016 at 3:39:43 PM UTC-5, Keith Thompson wrote: > Not everything is about the vast conspiracy to produce deliberately > useless compilers. Compiler writers don't sit down and say "Hey, let's write a useless compiler". They do, however, fail to recognize what has traditionally made C useful for many applications. If general-purpose compilers for platforms with some common feature have for decades made that feature available to the programmer, and programmers have benefited from being able to use it, code which makes use of that feature shouldn't be considered "defective". Instead, the feature should be viewed as part of what makes C useful on such platforms. If it is necessary to deprecate support for a feature, it should be done via proper deprecation process, not by a compiler writer claiming it was never defined (ignoring years of precedent showing both support and usage).
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-23 20:07 +0100 |
| Message-ID | <87twebuwwn.fsf@gmail.com> |
| In reply to | #92657 |
supercat@casperkitty.com writes: > On Monday, August 22, 2016 at 3:39:43 PM UTC-5, Keith Thompson wrote: >> Not everything is about the vast conspiracy to produce deliberately >> useless compilers. > > Compiler writers don't sit down and say "Hey, let's write a useless > compiler". They do, however, fail to recognize what has traditionally > made C useful for many applications. Of the uncountable stupid things you've said, this may be the stupidest.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-23 14:30 -0700 |
| Message-ID | <36a5bcc3-9e30-468c-a3e1-4b9c9788d395@googlegroups.com> |
| In reply to | #92658 |
On Tuesday, August 23, 2016 at 2:07:36 PM UTC-5, gwowen wrote: > supercat writes: > > Compiler writers don't sit down and say "Hey, let's write a useless > > compiler". They do, however, fail to recognize what has traditionally > > made C useful for many applications. > > Of the uncountable stupid things you've said, this may be the stupidest. There are many applications (including 99.99999% of embedded programs) for which C's usefulness is a result of widespread support for features beyond what the Standard mandates. Do you disagree with that? At least some compiler writers have taken the attitude that code which relies upon such features has no real meaning, and works only by "happenstance", no matter how many earlier compilers have interpreted it consistently. Do you disagree with that? Such dismissal may reasonably be interpreted as a refusal to recognize the existence and usefulness of such features. Do you disagree with that? With what, then, are you disagreeing?
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-24 06:25 +0100 |
| Message-ID | <87eg5ed9gu.fsf@gmail.com> |
| In reply to | #92663 |
supercat@casperkitty.com writes: > On Tuesday, August 23, 2016 at 2:07:36 PM UTC-5, gwowen wrote: >> supercat writes: >> > Compiler writers don't sit down and say "Hey, let's write a useless >> > compiler". They do, however, fail to recognize what has traditionally >> > made C useful for many applications. >> >> Of the uncountable stupid things you've said, this may be the stupidest. > > There are many applications (including 99.99999% of embedded programs) > for which C's usefulness is a result of widespread support for features > beyond what the Standard mandates. Do you disagree with that? No. > At least some compiler writers have taken the attitude that code which > relies upon such features has no real meaning, and works only by > "happenstance", no matter how many earlier compilers have interpreted it > consistently. Do you disagree with that? Yes. Completely.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-24 10:34 +0200 |
| Message-ID | <npjm5q$vho$1@dont-email.me> |
| In reply to | #92663 |
On 23/08/16 23:30, supercat@casperkitty.com wrote: > On Tuesday, August 23, 2016 at 2:07:36 PM UTC-5, gwowen wrote: >> supercat writes: >>> Compiler writers don't sit down and say "Hey, let's write a useless >>> compiler". They do, however, fail to recognize what has traditionally >>> made C useful for many applications. >> >> Of the uncountable stupid things you've said, this may be the stupidest. > > There are many applications (including 99.99999% of embedded programs) > for which C's usefulness is a result of widespread support for features > beyond what the Standard mandates. Do you disagree with that? Most of the code in most embedded programs that are written in C can be written using only standard-mandated features. And most of the rest can all be done using implementation-dependent behaviour, as allowed by the standards. That is not to say that most embedded programs are written in a way that does not depend on undefined or unspecified behaviour acting in a particular way. And sometimes code can be smaller or faster while relying on what one might call "undocumented implementation-dependent behaviour" from compilers. People who take embedded programming seriously - like other serious programmers - strive to avoid undefined behaviour in their code. But they are often much happier to rely on implementation-dependent behaviour than "mainstream" C programmers, because they often know exactly which compiler and target processor their code will run on. But since serious embedded programmers know that they are fallible, and they know that compiler writers are fallible, they will write code that /should/ be independent of details of the compiler, flags, etc., and then lock down exact versions of the tools and flags just in case they have accidentally relied on "undocumented implementation-defined behaviour". > > At least some compiler writers have taken the attitude that code which > relies upon such features has no real meaning, and works only by > "happenstance", no matter how many earlier compilers have interpreted it > consistently. Do you disagree with that? I disagree with that. Certainly compiler writers will not bother unduly with source code that has no real meaning - but if many compilers have treated code in one way before, then they will take that into account. But they will not artificially limit the efficiency of code written by people who understand C programming, in order to placate those who don't understand. Let us take an example, and see how gcc handles it. In C, signed integer overflow is undefined behaviour. But in the underlying processor, in most cases, signed arithmetic overflow wraps as two's complement arithmetic in a defined manner. Some people may have written code that relies on this hardware behaviour - their code perhaps worked on some compilers during testing. Other people may have written code which can result in more efficient object code if the compiler assumes integer overflow does not occur. Should the compiler limit the efficiency of the good programmer's code, just because the bad programmer does not understand the way C works here? On the other hand (the one you favour), should the compiler break code that worked fine previously, simply in order to slightly speed up someone else's code? gcc lets you answer "no" to both points - it gives /you/ the choice. The compiler can optimise on the assumption that signed overflow will not occur - but /only/ if the optimisation option is enabled (with "-fstrict-overflow", or -O2). You can keep the old code working by limiting optimisation to -O1 or -O0 (with -O0 being the default), or by explicitly disabling that optimisation with "-fno-strict-overflow". You can also tell gcc that you want integer overflow to work as two's complement wraparound in all circumstances, and that the compiler can optimise using that knowledge, with the "-fwrapv" option. What if you are worried that you might accidentally have signed overflow? gcc supports "-ftrapv" on some targets to catch overflows at run-time. The newer "-fsanitize=signed-integer-overflow" also makes checks, and is probably better for future use. Then there are compile-time warnings, the "-Wstrict-overflow" flag that will warn when strict overflow optimisations affect code. It is configurable to different levels. Warnings on overflows of constant calculations need to be explicitly disabled if you don't want them. gcc is the compiler that you apparently consider most "evil" regarding optimisations, with clang as a close competitor (clang supports the same options here, I believe). Yet this shows just how much effort the gcc folks put in to helping people work with legacy, incorrect code that happened to work before - or people who would rather program in a language slightly different from C in which integer overflow always wraps. Other cases such as type-based alias analysis are similar, with a similar set of flags and options. And note that in the embedded world, far and away the biggest single compiler used is gcc. (I don't mean most embedded programs are compiled with gcc - but more are compiled with gcc than with any other compiler.) It turns out that in real life, people seem quite capable of using the "evil" gcc compiler to make working embedded systems. And the gcc developers are perfectly aware that this is a major market for their compiler, especially for C (as distinct from C++, Go, or other languages supported by gcc). > > Such dismissal may reasonably be interpreted as a refusal to recognize the > existence and usefulness of such features. Do you disagree with that? > See above. > With what, then, are you disagreeing? > In a nutshell, I disagree with your ignorant paranoia and conspiracy theories. You have made good points in the past regarding surprising or hidden undefined behaviour in innocent-looking code. But your ideas about compiler optimisations, and the motivations and priorities of compiler developers, are completely and utterly wrong.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-08-24 08:50 -0400 |
| Message-ID | <1Kgvz.279$6d.174@fx26.iad> |
| In reply to | #92675 |
On 8/24/16 4:34 AM, David Brown wrote: > On 23/08/16 23:30, supercat@casperkitty.com wrote: >> On Tuesday, August 23, 2016 at 2:07:36 PM UTC-5, gwowen wrote: >>> supercat writes: >>>> Compiler writers don't sit down and say "Hey, let's write a useless >>>> compiler". They do, however, fail to recognize what has traditionally >>>> made C useful for many applications. >>> >>> Of the uncountable stupid things you've said, this may be the stupidest. >> >> There are many applications (including 99.99999% of embedded programs) >> for which C's usefulness is a result of widespread support for features >> beyond what the Standard mandates. Do you disagree with that? > > Most of the code in most embedded programs that are written in C can be > written using only standard-mandated features. And most of the rest can > all be done using implementation-dependent behaviour, as allowed by the > standards. > > That is not to say that most embedded programs are written in a way that > does not depend on undefined or unspecified behaviour acting in a > particular way. And sometimes code can be smaller or faster while > relying on what one might call "undocumented implementation-dependent > behaviour" from compilers. > In my experience, it is impossible to write a useful embedded program (maybe you can even drop the embedded) without using something beyond 'standard mandated'. In the embedded case, you virtually always are going to need to talk to some hardware, which will require you to normally include a header outside the list mandated by the standard, or write some statements yourself that either use an extension or invoke the technical undefined behavior of casting an integer value (not gotten from casting a pointer) to a pointer and referencing it. These are normally well documented implementation defined behaviors. supercat's 'problem' is that he want behavior that was never (or maybe rarely back then) promised by implementations, but which happened to have worked on simple implementations to be required by the standard to always work that way. The key issue he misses is that it is basically impossible to write in the standard such a requirement without breaking some of the fundamental philosophies of the standard (that a C implementation that is reasonably efficient be possible on virtually all processors that meet some very basic minimum requirements). What he misses is that the writers of the standard EXPECT that most programs are going to rely on some features beyond the minimum the standard requires, using implementation defined behavior, but hopefully do so in a deliberate manner where they can document what behavior they need. He also misses that most of the systems he rails against DO provide the promises he want IF he uses the right set of options. He sometimes proposes a method of letting the program 'make requests' for certain possible implementation defined behaviors (often of things the standard for simplicity just leaves undefined). Normally his proposal is just a bit of a snippet of a sample way to do this. Perhaps if he really wants to be useful (or to understand why it hasn't been done) he should take the effort to formally develop it to be closer to a real proposal to the committee. Make a REAL listing of the vast majority of behaviors that having, documenting, and being able to programmatically test would be useful. Make it broad enough that so that other programmers who may want different assumptions than what he wants can find it useful. The alternative, is to define an auxiliary standard (in sort of a similar manner as POSIX) that adds the defined behavior that he wants so that just by invoking the implement in the mode documented to be compliant to this extended standard gets what he wants. This leaves the basic standard clean, and possible to use on the oddball machines as has been the policy of the committee, and still lets people like him get what they want. The fact that this hasn't already been done makes me think that the existing implementations do well enough at this with the right options that it isn't really that highly demanded as a formal (or informal) standard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-24 15:37 +0200 |
| Message-ID | <npk7v8$p1c$1@dont-email.me> |
| In reply to | #92677 |
On 24/08/16 14:50, Richard Damon wrote: > On 8/24/16 4:34 AM, David Brown wrote: >> On 23/08/16 23:30, supercat@casperkitty.com wrote: >>> On Tuesday, August 23, 2016 at 2:07:36 PM UTC-5, gwowen wrote: >>>> supercat writes: >>>>> Compiler writers don't sit down and say "Hey, let's write a useless >>>>> compiler". They do, however, fail to recognize what has traditionally >>>>> made C useful for many applications. >>>> >>>> Of the uncountable stupid things you've said, this may be the >>>> stupidest. >>> >>> There are many applications (including 99.99999% of embedded programs) >>> for which C's usefulness is a result of widespread support for features >>> beyond what the Standard mandates. Do you disagree with that? >> >> Most of the code in most embedded programs that are written in C can be >> written using only standard-mandated features. And most of the rest can >> all be done using implementation-dependent behaviour, as allowed by the >> standards. >> >> That is not to say that most embedded programs are written in a way that >> does not depend on undefined or unspecified behaviour acting in a >> particular way. And sometimes code can be smaller or faster while >> relying on what one might call "undocumented implementation-dependent >> behaviour" from compilers. >> > > In my experience, it is impossible to write a useful embedded program > (maybe you can even drop the embedded) without using something beyond > 'standard mandated'. In the embedded case, you virtually always are > going to need to talk to some hardware, which will require you to > normally include a header outside the list mandated by the standard, or > write some statements yourself that either use an extension or invoke > the technical undefined behavior of casting an integer value (not gotten > from casting a pointer) to a pointer and referencing it. These are > normally well documented implementation defined behaviors. Exactly - such behaviour is implementation-dependent behaviour, not undefined behaviour. Sometimes the documentation is not too great, and there is a grey area around "implementation-dependent behaviour that the vendor forgot to document" and "undefined or unspecified behaviour that works one way now, but may change in future versions of the compiler". > > supercat's 'problem' is that he want behavior that was never (or maybe > rarely back then) promised by implementations, but which happened to > have worked on simple implementations to be required by the standard to > always work that way. Yes. > The key issue he misses is that it is basically > impossible to write in the standard such a requirement without breaking > some of the fundamental philosophies of the standard (that a C > implementation that is reasonably efficient be possible on virtually all > processors that meet some very basic minimum requirements). What he > misses is that the writers of the standard EXPECT that most programs are > going to rely on some features beyond the minimum the standard requires, > using implementation defined behavior, but hopefully do so in a > deliberate manner where they can document what behavior they need. Yes. > > He also misses that most of the systems he rails against DO provide the > promises he want IF he uses the right set of options. > Yes. > He sometimes proposes a method of letting the program 'make requests' > for certain possible implementation defined behaviors (often of things > the standard for simplicity just leaves undefined). Normally his > proposal is just a bit of a snippet of a sample way to do this. Perhaps > if he really wants to be useful (or to understand why it hasn't been > done) he should take the effort to formally develop it to be closer to a > real proposal to the committee. Make a REAL listing of the vast majority > of behaviors that having, documenting, and being able to > programmatically test would be useful. Make it broad enough that so that > other programmers who may want different assumptions than what he wants > can find it useful. > > The alternative, is to define an auxiliary standard (in sort of a > similar manner as POSIX) that adds the defined behavior that he wants so > that just by invoking the implement in the mode documented to be > compliant to this extended standard gets what he wants. This leaves the > basic standard clean, and possible to use on the oddball machines as has > been the policy of the committee, and still lets people like him get > what they want. The fact that this hasn't already been done makes me > think that the existing implementations do well enough at this with the > right options that it isn't really that highly demanded as a formal (or > informal) standard. > Agreed. Sometimes I think that such an auxiliary standard could be useful, and define "normal C systems". It could say things like "CHAR_BIT is always either 8, 16 or 32," "signed ints are always two's complement," and "integer types are always either little-endian or big-endian, with no mixtures, padding bits, or other awkwardness". Exactly what goes into the standard is debatable - people will have different opinions. But it would mean that at least some types of code could be more easily written in a way that is portable across a range of systems - basically it's just a minimum set of implementation-dependent behaviour. But as you say, no such standard exists. That is likely to be because people do well enough with the normal C standard, the posix standard, the defacto "standard" of gcc behaviour (which is followed to a fair degree by clang, icc, and several other compilers), and the implementation-dependent behaviour of the target they are actually using.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-24 11:58 -0700 |
| Message-ID | <8277ffd2-121d-4f3a-9bb0-ad3068696415@googlegroups.com> |
| In reply to | #92678 |
On Wednesday, August 24, 2016 at 8:37:52 AM UTC-5, David Brown wrote: > Exactly - such behaviour is implementation-dependent behaviour, not > undefined behaviour. Sometimes the documentation is not too great, and > there is a grey area around "implementation-dependent behaviour that the > vendor forgot to document" and "undefined or unspecified behaviour that > works one way now, but may change in future versions of the compiler". The vast majority of documentation for products of all kinds relies upon the reader to make assumptions beyond what is stated; documentation that says something behaves exactly as any reasonable person would expect it to behave is often viewed as redundant. When reading any kind of old documentation, it is thus important to keep in mind the expected mindset of the target audience. Do you think that many compiler writers or programmers in 1988 would have imagined that a two's-complement implementation on silent-wraparound hardware would have any reason not to interpret "uint1x = usmall1 * usmall2;" as being equivalent to "uint1x = (unsigned)usmall1 * usmall2;", 100% of the time? If there was no reason to imagine that a compiler might do such a thing, what would be the benefit of promising that it wouldn't? Also, what terminology do you think that the Standard would use to describe situations in which 90%+ of implementations behaved in the same consistent fashion, but mandating that the remaining platforms document a consistent behavior would impose a significant runtime cost? Do you believe that the authors of the Standard intended that it be interpreted as doing anything other than maintaining the status quo in such cases? It would have been helpful if the Standard had indicated that compilers that offer features and guarantees beyond the Standard should document them if they expect programmers to use them, and had included a list of common guarantees for which implementations should document such support when applicable. The Standard, however, implies that such features are not to be considered "extensions", since the it lists extensions which were supported by a minority of implementations, but fails to list behavioral guarantees which, according to the authors, were applicable to a majority. If the authors of the Standard wanted to improve the state of documentation they should have set a better example. > > The alternative, is to define an auxiliary standard (in sort of a > > similar manner as POSIX) that adds the defined behavior that he wants so > > that just by invoking the implement in the mode documented to be > > compliant to this extended standard gets what he wants. This leaves the > > basic standard clean, and possible to use on the oddball machines as has > > been the policy of the committee, and still lets people like him get > > what they want. The fact that this hasn't already been done makes me > > think that the existing implementations do well enough at this with the > > right options that it isn't really that highly demanded as a formal (or > > informal) standard. > > Agreed. Embedded compilers have to date generally refrained from the kinds of aggressive optimizations that seem to be becoming fashionable elsewhere. Unfortunately, their documentation tends to be rather sloppy with regard to such issues. What should one assume about future versions of an embedded compiler whose documentation says nothing about type-based aliasing because it ensures all variables' states are kept in memory any time a non-restrict-qualified pointer is accessed? > Sometimes I think that such an auxiliary standard could be useful, and > define "normal C systems". It could say things like "CHAR_BIT is always > either 8, 16 or 32," "signed ints are always two's complement," and > "integer types are always either little-endian or big-endian, with no > mixtures, padding bits, or other awkwardness". Exactly what goes into > the standard is debatable - people will have different opinions. But it > would mean that at least some types of code could be more easily written > in a way that is portable across a range of systems - basically it's > just a minimum set of implementation-dependent behaviour. POSIX defines some such issues, but also mandates a lot of other things which would not be meaningful on many free-standing implementations. > But as you say, no such standard exists. That is likely to be because > people do well enough with the normal C standard, the posix standard, > the defacto "standard" of gcc behaviour (which is followed to a fair > degree by clang, icc, and several other compilers), and the > implementation-dependent behaviour of the target they are actually using. Is there any logical reason why "implementation-dependent" behavior should be limited to actions for which every platform is capable of defining a fully-predictable behavior? Is a programmer any more entitled to expect that a silent-wraparound two's-complement implementation will regard "(unsigned)(int)x" as equivalent to "(unsigned)x" than to expect that "-1<<x" will be equivalent to "-(1<<x)" for values of x from 0 to 14?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-25 01:27 +0200 |
| Message-ID | <nplahs$ngv$1@dont-email.me> |
| In reply to | #92689 |
On 24/08/16 20:58, supercat@casperkitty.com wrote: > Embedded compilers have to date generally refrained from the kinds of > aggressive optimizations that seem to be becoming fashionable elsewhere. > Unfortunately, their documentation tends to be rather sloppy with regard > to such issues. What should one assume about future versions of an > embedded compiler whose documentation says nothing about type-based > aliasing because it ensures all variables' states are kept in memory > any time a non-restrict-qualified pointer is accessed? > I don't know what embedded compilers /you/ have been using, but I have been using ones that do "aggressive optimisations" such as type-based alias analysis for 20+ years. I have used a few that have very little in the way of optimisation (effectively treating all variables as "volatile", for example). But many embedded compilers are far more sophisticated and advanced than you seem to think. Documentation quality does vary, though - from very good to very poor, with little regard for price of the product.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-24 22:28 -0700 |
| Message-ID | <ee1434bc-5a52-4cea-91e3-432d67f2727c@googlegroups.com> |
| In reply to | #92690 |
On Wednesday, August 24, 2016 at 6:28:07 PM UTC-5, David Brown wrote:
> I don't know what embedded compilers /you/ have been using, but I have
> been using ones that do "aggressive optimisations" such as type-based
> alias analysis for 20+ years.
Got some names? How aggressively did they do type-based analysis, and to
what extent did they try to recognize indications that aliasing was likely?
Given a construct like:
void set_lower_half_to_0x8000(uint32_t *n)
{
((uint16_t*)n)[IS_BIG_ENDIAN] = 0x8000;
}
would the compilers of 20 years ago assume that the method would only be
called with the addresses of uint16_t objects, or would they recognize
that the code is modifying something that has been identified with a
pointer of type uint32_t, and thus is likely modifying something of type
uint32_t?
How do the compilers you use regard the relative sequencing of volatile-
qualified and non-volatile-qualified operations? If volatile accesses
aren't treated as memory barriers, how would you handle something like
copying arbitrary-type data to a buffer and then starting a DMA transfer?
There is no standard library version of "memcpy" which uses volatile-
qualified pointers, and copying data one byte at a time is apt to be
sufficiently slow as to negate much of the speed benefit from using DMA
in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-24 23:38 -0700 |
| Message-ID | <502669cd-f0fc-4b99-8c8a-0d806c8b5f20@googlegroups.com> |
| In reply to | #92691 |
On Thursday, August 25, 2016 at 6:28:27 AM UTC+1, supe...@casperkitty.com wrote: > > How do the compilers you use regard the relative sequencing of volatile- > qualified and non-volatile-qualified operations? If volatile accesses > aren't treated as memory barriers, how would you handle something like > copying arbitrary-type data to a buffer and then starting a DMA transfer? > There is no standard library version of "memcpy" which uses volatile- > qualified pointers, and copying data one byte at a time is apt to be > sufficiently slow as to negate much of the speed benefit from using DMA > in the first place. > There's really no answer to that one. "volatile" means that the object can change at any time, except when the program is actually in the process of writing to it. So if doubles are implemented in software on an 8 bit machine, the object has to be locked for 8 bytes of read / write, then unlocked. But what does it mean to declare a buffer volatile? You can't just read or write from it, you're going to need some, probably trivial index operation. Really you need to lock the buffer, perform your operation, then unlock it, just as with the volatile double on an 8 bit machine, assuming that the buffer needs to be in a coherent state. Once you've locked the buffer, it is of course no longer volatile.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-25 10:44 +0200 |
| Message-ID | <npmb61$a0i$1@dont-email.me> |
| In reply to | #92692 |
On 25/08/16 08:38, Malcolm McLean wrote:
> On Thursday, August 25, 2016 at 6:28:27 AM UTC+1, supe...@casperkitty.com wrote:
>>
>> How do the compilers you use regard the relative sequencing of volatile-
>> qualified and non-volatile-qualified operations? If volatile accesses
>> aren't treated as memory barriers, how would you handle something like
>> copying arbitrary-type data to a buffer and then starting a DMA transfer?
>> There is no standard library version of "memcpy" which uses volatile-
>> qualified pointers, and copying data one byte at a time is apt to be
>> sufficiently slow as to negate much of the speed benefit from using DMA
>> in the first place.
>>
> There's really no answer to that one.
> "volatile" means that the object can change at any time, except when
> the program is actually in the process of writing to it. So if
> doubles are implemented in software on an 8 bit machine, the
> object has to be locked for 8 bytes of read / write, then unlocked.
You are confusing volatile accesses with atomic accesses. They are
significantly different things.
Volatile accesses are used when you want to read or write something in
memory in a controlled manner - no more and no fewer accesses than the
source code says, and in the given order with respect to other volatile
accesses (and other observable behaviour).
Atomic accesses are used when code (especially other threads or signal
handlers) must see a consistent view of an object - either the complete
old value, or the complete new value, but never a mixture of the two.
Often the concepts are used together, and you are not alone in confusing
them - but they are different, and they can be used independently.
>
> But what does it mean to declare a buffer volatile? You can't just
> read or write from it, you're going to need some, probably trivial
> index operation.
Yes, you just read or write to it.
volatile uint8_t buffer[128];
void copyToBuffer(const uint8_t *pSrc, int count) {
int n = 0;
while (count--) {
buffer[n++] = *pSrc++;
}
}
Problem solved.
You can also use a buffer that is not declared volatile, and make the
accesses volatile:
uint8_t buffer[128];
void copyToBuffer(const uint8_t *pSrc, int count) {
int n = 0;
while (count--) {
*((volatile uint8_t*) (&(buffer[n++]))) = *pSrc++;
}
}
(I know there are unnecessary extra brackets there - it's often best to
do this sort of thing with macros such as Linux's ACCESS_ONCE, or
alternatively to use a "volatile uint8_t *" pointer rather than an
explicit cast.)
> Really you need to lock the buffer, perform your
> operation, then unlock it, just as with the volatile double on an
> 8 bit machine, assuming that the buffer needs to be in a coherent
> state.
No, really you don't need to lock the buffer. You just need to
understand what you are doing.
> Once you've locked the buffer, it is of course no longer volatile.
>
As long as your lock methods have appropriate memory barriers, then
locking the buffer will work. But it is completely unnecessary in most
cases.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-25 07:29 -0700 |
| Message-ID | <aa1be119-a537-4df5-97da-ade93afdba0c@googlegroups.com> |
| In reply to | #92692 |
On Thursday, August 25, 2016 at 1:38:28 AM UTC-5, Malcolm McLean wrote: > Once you've locked the buffer, it is of course no longer volatile. Since many freestanding implementations of C generally won't support the C11 threading extensions (since that would require that the implementation be much heavier weight than one which lets programmers operate on bare metal), by what standard means would you suggest that programmers tell the compiler that something is locked? One of the things that made C useful for embedded systems was that a programmer who was familiar with a hardware platform could pretty well guess what needed to be written in C to access it. If a platform has a uniform linear addressing space and one wants to write a 32-bit word 0xCAFEBABE to address 0xABCD1234, a non-oddball implementation for that platform will allow that to be accomplished via * ((uint32_t volatile*)0xABCD1234) = 0xCAFEBABE; If a compiler treats volatile variables as memory barriers, then code which ensures that compiler-produced accesses to a variable will be separated from other accesses by volatile I/O can work correctly without having to use any further language extensions.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-25 07:32 -0700 |
| Message-ID | <566c947b-91d6-43c1-86aa-772f6cf21e35@googlegroups.com> |
| In reply to | #92696 |
On Thursday, August 25, 2016 at 10:29:43 AM UTC-4, supe...@casperkitty.com > One of the things that made C useful for embedded systems was that a > programmer who was familiar with a hardware platform could pretty well > guess what needed to be written in C to access it. If a platform has > a uniform linear addressing space and one wants to write a 32-bit word > 0xCAFEBABE to address 0xABCD1234, a non-oddball implementation for that > platform will allow that to be accomplished via > > * ((uint32_t volatile*)0xABCD1234) = 0xCAFEBABE; > > If a compiler treats volatile variables as memory barriers, then code > which ensures that compiler-produced accesses to a variable will be > separated from other accesses by volatile I/O can work correctly without > having to use any further language extensions. Does the C Standard allow for volatile casts on non-volatile variables? And to explicitly cast hard-coded values like that as pointers? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-25 10:26 -0700 |
| Message-ID | <ed11fd7f-abac-49a8-a36b-5c056b4d46af@googlegroups.com> |
| In reply to | #92697 |
On Thursday, August 25, 2016 at 9:32:49 AM UTC-5, Rick C. Hodgin wrote: > On Thursday, August 25, 2016 at 10:29:43 AM UTC-4, supe...@casperkitty.com > > One of the things that made C useful for embedded systems was that a > > programmer who was familiar with a hardware platform could pretty well > > guess what needed to be written in C to access it. If a platform has > > a uniform linear addressing space and one wants to write a 32-bit word > > 0xCAFEBABE to address 0xABCD1234, a non-oddball implementation for that > > platform will allow that to be accomplished via > > > > * ((uint32_t volatile*)0xABCD1234) = 0xCAFEBABE; > > > > If a compiler treats volatile variables as memory barriers, then code > > which ensures that compiler-produced accesses to a variable will be > > separated from other accesses by volatile I/O can work correctly without > > having to use any further language extensions. > > Does the C Standard allow for volatile casts on non-volatile variables? > And to explicitly cast hard-coded values like that as pointers? If an implementation does not define uintptr_t or intptr_t, it may specify that every pointer-to-integer cast will yield UB; even if an implementation does so, however, it would still be required to accept the syntax. IMHO, it would have been better to make such casts an optional feature, since mandating that a compiler accept a syntax without mandating that it have a useful behavior seems a bit silly. I don't think an integer-to-pointer cast is allowed to ever invoke UB (despite the fact that on some implementations, trapping on invalid casts could be a useful feature) but if an implementation does not define intptr_t or uintptr_t, there is no requirement that there exist any integer values that would not produce trap representations. Casting addresses to pointers and accessing them in the indicated fashion is among the useful behaviors which should be part of a "commonplace C" standard. Someone using a new compiler on a linear-address platform should not have to consult the documentation to see how it defines integer-to- pointer conversions in the absence of any particular reason to expect it to do anything other than yield a pointer to the indicated address.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-25 11:11 -0700 |
| Message-ID | <0a1fe57e-8a3f-444b-93ab-1e4c43c0af70@googlegroups.com> |
| In reply to | #92703 |
On Thursday, August 25, 2016 at 1:27:04 PM UTC-4, supe...@casperkitty.com wrote: > On Thursday, August 25, 2016 at 9:32:49 AM UTC-5, Rick C. Hodgin wrote: > > On Thursday, August 25, 2016 at 10:29:43 AM UTC-4, supe...@casperkitty.com > > > One of the things that made C useful for embedded systems was that a > > > programmer who was familiar with a hardware platform could pretty well > > > guess what needed to be written in C to access it. If a platform has > > > a uniform linear addressing space and one wants to write a 32-bit word > > > 0xCAFEBABE to address 0xABCD1234, a non-oddball implementation for that > > > platform will allow that to be accomplished via > > > > > > * ((uint32_t volatile*)0xABCD1234) = 0xCAFEBABE; > > > > > > If a compiler treats volatile variables as memory barriers, then code > > > which ensures that compiler-produced accesses to a variable will be > > > separated from other accesses by volatile I/O can work correctly without > > > having to use any further language extensions. > > > > Does the C Standard allow for volatile casts on non-volatile variables? > > And to explicitly cast hard-coded values like that as pointers? > > If an implementation does not define uintptr_t or intptr_t, it may > specify that every pointer-to-integer cast will yield UB; even if an > implementation does so, however, it would still be required to accept > the syntax. IMHO, it would have been better to make such casts an > optional feature, since mandating that a compiler accept a syntax > without mandating that it have a useful behavior seems a bit silly. Very silly. > I don't think an integer-to-pointer cast is allowed to ever invoke UB > (despite the fact that on some implementations, trapping on invalid > casts could be a useful feature) but if an implementation does not > define intptr_t or uintptr_t, there is no requirement that there exist > any integer values that would not produce trap representations. > > Casting addresses to pointers and accessing them in the indicated fashion > is among the useful behaviors which should be part of a "commonplace C" > standard. Someone using a new compiler on a linear-address platform should > not have to consult the documentation to see how it defines integer-to- > pointer conversions in the absence of any particular reason to expect it to > do anything other than yield a pointer to the indicated address. Agreed. Can you cast an otherwise non-volatile thing to be volatile on an instance use, or the other-way around cast a volatile thing to be non-volatile on an instance use? I was not aware of that ability (if it's legal in the C Standard). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-25 12:03 -0700 |
| Message-ID | <712811a9-1680-41fb-904f-d3346282802f@googlegroups.com> |
| In reply to | #92706 |
On Thursday, August 25, 2016 at 1:11:48 PM UTC-5, Rick C. Hodgin wrote: > Can you cast an otherwise non-volatile thing to be volatile on an > instance use, or the other-way around cast a volatile thing to be > non-volatile on an instance use? Conversions between pointer types that are identical but for the presence or absence of a "volatile" qualifier are fully defined. Use of a pointer that is not volatile-qualified to access an object that is volatile qualified invokes UB, regardless of whether the variable is ever accessed in any way the compiler doesn't know about [likely to allow for the possibility that a system might locate such variables in a region of memory that requires special instructions to access, but a silly restriction on implementations where volatile variables are allocated the same as any other]. It's not clear what rules would apply to storage supplied by "malloc()", since there are applications that need the ability to create buffers that can be accessed outside the compiler's control.
[toc] | [prev] | [next] | [standalone]
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web