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 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 15:31 +0200 |
| Message-ID | <nq1dfn$ola$1@dont-email.me> |
| In reply to | #92697 |
On 25/08/16 16:32, 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? > The C standard is weak on this area - "What constitutes an access to an object that has volatile-qualified type" is implementation defined behaviour. So I think your answer here is that it depends on the compiler. However, I have never used a compiler that did not treat an object accessed through a volatile cast as a straight memory access, nor one that did not interpret hard-coded values (like the example above) in the "obvious" way. I think as long as you are dealing with an "ordinary" target, rather than a really awkward processor or compiler, you should be safe here. Certainly such hard-coded casts are an extremely common way to define and access hardware registers in embedded systems of all sorts. But unlike Supercat's pet theories about "old" compilers, a hard-coded access like the one above does /not/ form any sort of memory barrier. With volatiles, you must always be careful to remember that they are only ordered with respect to observable behaviour, such as external function calls and other volatile accesses - they are not ordered with respect to ordinary data accesses. You also have to remember that orders between sequence points is not specified, nor are details of read-modify-write operations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-29 09:28 -0700 |
| Message-ID | <ln8tvfczff.fsf@kst-u.example.com> |
| In reply to | #92859 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The C standard is weak on this area - "What constitutes an access to an
> object that has volatile-qualified type" is implementation defined
> behaviour. So I think your answer here is that it depends on the compiler.
[...]
That's not what the standard says.
N1570 6.7.3p7:
What constitutes an access to an object that has volatile-qualified
type is implementation-defined.
It's the question of whether a given operation is an access to a
volatile object that's implementation-defined, not the behavior.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 22:51 +0200 |
| Message-ID | <nq277p$4sb$1@dont-email.me> |
| In reply to | #92873 |
On 29/08/16 18:28, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> The C standard is weak on this area - "What constitutes an access to an >> object that has volatile-qualified type" is implementation defined >> behaviour. So I think your answer here is that it depends on the compiler. > [...] > > That's not what the standard says. > > N1570 6.7.3p7: > > What constitutes an access to an object that has volatile-qualified > type is implementation-defined. > > It's the question of whether a given operation is an access to a > volatile object that's implementation-defined, not the behavior. > That is really the question. When you make a pointer-to-volatile using a cast, and access that, is it a volatile access or not? I /think/ the standard says the answer is implementation-defined - but I also think that compilers would treat all accesses via pointers as volatile accesses. That includes things like: * ((uint32_t volatile *) 0xabcd1234) = 0xcafebabe; and also extern int foo; * ((int volatile *) &foo) = 1234; I haven't seen any compiler that does not interpret code like this in the obvious way - but I am not sure that the standard actually guarantees it here. (Correct me if I'm wrong - you are better at interpreting the standards than I am.) I think the implementation-defined clause in the standards is so that the implementation can pick different implementations of things like: volatile int v; v += 1; If the cpu supports instructions that operate directly on memory, the implementation can decide if this is a read, an operation, then a write, or if it is a single read-modify-write instruction.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-29 16:35 -0700 |
| Message-ID | <lninujb133.fsf@kst-u.example.com> |
| In reply to | #92901 |
David Brown <david.brown@hesbynett.no> writes:
> On 29/08/16 18:28, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> The C standard is weak on this area - "What constitutes an access to an
>>> object that has volatile-qualified type" is implementation defined
>>> behaviour. So I think your answer here is that it depends on the compiler.
>> [...]
>>
>> That's not what the standard says.
>>
>> N1570 6.7.3p7:
>>
>> What constitutes an access to an object that has volatile-qualified
>> type is implementation-defined.
>>
>> It's the question of whether a given operation is an access to a
>> volatile object that's implementation-defined, not the behavior.
>
> That is really the question. When you make a pointer-to-volatile
> using a cast, and access that, is it a volatile access or not? I
> /think/ the standard says the answer is implementation-defined - but I
> also think that compilers would treat all accesses via pointers as
> volatile accesses.
My point is that you incorrectly introduce the phrase
"implementation defined behaviour". It's not the *behavior* that's
implementation-defined, it's the determination of what constitutes
an access. Once that's determined, the behavior might be either
well defined, implementation-defined, unspecified, or undefined,
depending on the specific code.
One example of how this is defined is here (for gcc):
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 01:44 +0200 |
| Message-ID | <nq2hcm$4sp$1@dont-email.me> |
| In reply to | #92912 |
On 30/08/16 01:35, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 29/08/16 18:28, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> The C standard is weak on this area - "What constitutes an access to an >>>> object that has volatile-qualified type" is implementation defined >>>> behaviour. So I think your answer here is that it depends on the compiler. >>> [...] >>> >>> That's not what the standard says. >>> >>> N1570 6.7.3p7: >>> >>> What constitutes an access to an object that has volatile-qualified >>> type is implementation-defined. >>> >>> It's the question of whether a given operation is an access to a >>> volatile object that's implementation-defined, not the behavior. >> >> That is really the question. When you make a pointer-to-volatile >> using a cast, and access that, is it a volatile access or not? I >> /think/ the standard says the answer is implementation-defined - but I >> also think that compilers would treat all accesses via pointers as >> volatile accesses. > > My point is that you incorrectly introduce the phrase > "implementation defined behaviour". It's not the *behavior* that's > implementation-defined, it's the determination of what constitutes > an access. Once that's determined, the behavior might be either > well defined, implementation-defined, unspecified, or undefined, > depending on the specific code. > OK, I see what you mean. However, I was taking this example from Annex J.3.10 (in N1570, C11 draft). Annex J.3 is titled "Implementation-defined behaviour", with the description "A conforming implementation is required to document its choice of behavior in each of the areas listed in this subclause. The following are implementation-defined:" and J.3.10 Qualifiers says "What constitutes an access to an object that has volatile-qualified type". So perhaps you are making more of a distinction than the standards do. However, I agree that the behaviour itself may be well defined or otherwise depending on the code - if you have a volatile null pointer, dereferencing it is still going to be undefined behaviour even if the implementation clearly describes what sort of access it is. > One example of how this is defined is here (for gcc): > > https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-30 10:06 -0700 |
| Message-ID | <kfnshtmp4nu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92912 |
Keith Thompson <kst-u@mib.org> writes: > David Brown <david.brown@hesbynett.no> writes: >> On 29/08/16 18:28, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> The C standard is weak on this area - "What constitutes an access to an >>>> object that has volatile-qualified type" is implementation defined >>>> behaviour. So I think your answer here is that it depends on the compiler. >>> >>> [...] >>> >>> That's not what the standard says. >>> >>> N1570 6.7.3p7: >>> >>> What constitutes an access to an object that has volatile-qualified >>> type is implementation-defined. >>> >>> It's the question of whether a given operation is an access to a >>> volatile object that's implementation-defined, not the behavior. >> >> That is really the question. When you make a pointer-to-volatile >> using a cast, and access that, is it a volatile access or not? I >> /think/ the standard says the answer is implementation-defined - but I >> also think that compilers would treat all accesses via pointers as >> volatile accesses. > > My point is that you incorrectly introduce the phrase > "implementation defined behaviour". It's not the *behavior* that's > implementation-defined, it's the determination of what constitutes > an access. How this is phrased makes it hard to know what you mean. Let me try to break this down, as I understand what the Standard is saying. Which C constructs require a "volatile access" is exactly defined by the ISO standard. They are precisely those expressions whose evaluations cause an access (either reading or writing), and whose type is volatile-qualified. This aspect is not affected by 6.7.3p7. What is to be done to effect, or carry out, a volatile-qualified access is what must be defined by each implementation. This might be, eg: (a) ordinary reads and writes; (b) ordinary reads and "cache write-through" writes; (c) atomic reads and writes, and atomic read-modify-write for things like += or similar; or perhaps (d) reads and writes with memory barriers before and after. (This list is not meant to be exhaustive.) This aspect, "how a volatile-access is to be carried out", is exactly what an implementation must define (and document) under 6.7.3p7. The Standard isn't very good at spelling this out, but discussion in the Rationale document makes it all fairly clear (as usual, IMO). > Once that's determined, the behavior might be either > well defined, implementation-defined, unspecified, or undefined, > depending on the specific code. To me this just seems wrong. What is to be done is determined by an implementation-defined statement. The Standard requires that this action, whatever it is, be carried out. The /consequences/ of carrying out said action may be unbounded, but that is not the same as undefined behavior. > One example of how this is defined is here (for gcc): > > https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html In my view what is described on that page crosses the line, at least in spirit. Implementations are not allowed to decide which volatile-qualified accesses will be done and which will not; they only get to decide how a VQA is carried out. Not whether, only how. Not doing any access at all (the text doesn't say this outright but it is implied) is not conforming, or at least not spirit-conforming.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-30 10:41 -0700 |
| Message-ID | <d0fc00ef-3fe6-4301-8d0c-3005b3031dc0@googlegroups.com> |
| In reply to | #92951 |
On Tuesday, August 30, 2016 at 12:06:56 PM UTC-5, Tim Rentsch wrote: > > https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html > > In my view what is described on that page crosses the line, at > least in spirit. Implementations are not allowed to decide which > volatile-qualified accesses will be done and which will not; > they only get to decide how a VQA is carried out. Not whether, > only how. Not doing any access at all (the text doesn't say this > outright but it is implied) is not conforming, or at least not > spirit-conforming. A common fix I've seen for that is to apply a unary plus to the operand. In cases where an lvalue isn't used syntactically it may be unclear whether an rvalue conversion will be applied, but adding a "+" makes it unambiguous. It also makes it clearer to anyone reading the code that one didn't simply write out the lvalue and forget to do something with it. An alternative would be a cast to void, but that seems a little verbose for my taste.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 21:24 +0200 |
| Message-ID | <nq4mht$gf4$1@dont-email.me> |
| In reply to | #92953 |
On 30/08/16 19:41, supercat@casperkitty.com wrote: > On Tuesday, August 30, 2016 at 12:06:56 PM UTC-5, Tim Rentsch wrote: >>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html >> >> In my view what is described on that page crosses the line, at >> least in spirit. Implementations are not allowed to decide which >> volatile-qualified accesses will be done and which will not; >> they only get to decide how a VQA is carried out. Not whether, >> only how. Not doing any access at all (the text doesn't say this >> outright but it is implied) is not conforming, or at least not >> spirit-conforming. > > A common fix I've seen for that is to apply a unary plus to the operand. > In cases where an lvalue isn't used syntactically it may be unclear > whether an rvalue conversion will be applied, but adding a "+" makes it > unambiguous. It also makes it clearer to anyone reading the code that > one didn't simply write out the lvalue and forget to do something with > it. An alternative would be a cast to void, but that seems a little > verbose for my taste. > Suppose you have a UART buffer register that clears the "buffer full" state on reading (this is a fine example of a volatile read having a clear effect). extern volatile uint32_t uart_read_buffer; You are suggesting that to read the buffer but ignore the result, you would write: +uart_read_buffer; That, IMHO, does not make anything clear to anyone. The most common way to dump a volatile read, as used in many embedded systems, is: (void) uart_read_buffer; // Read the buffer but dump the result i.e., a cast to void and a comment to make the effect clear. I have also seen macros used to provide a kind of documentation here: #define DUMP(v) (void) v DUMP(uart_read_buffer);
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 12:32 -0700 |
| Message-ID | <12217c29-57d9-42d7-a131-d68e5518f1b6@googlegroups.com> |
| In reply to | #92956 |
On Tuesday, August 30, 2016 at 8:24:56 PM UTC+1, David Brown wrote: > On 30/08/16 19:41, supercat@casperkitty.com wrote: > > On Tuesday, August 30, 2016 at 12:06:56 PM UTC-5, Tim Rentsch wrote: > >>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html > >> > >> In my view what is described on that page crosses the line, at > >> least in spirit. Implementations are not allowed to decide which > >> volatile-qualified accesses will be done and which will not; > >> they only get to decide how a VQA is carried out. Not whether, > >> only how. Not doing any access at all (the text doesn't say this > >> outright but it is implied) is not conforming, or at least not > >> spirit-conforming. > > > > A common fix I've seen for that is to apply a unary plus to the operand. > > In cases where an lvalue isn't used syntactically it may be unclear > > whether an rvalue conversion will be applied, but adding a "+" makes it > > unambiguous. It also makes it clearer to anyone reading the code that > > one didn't simply write out the lvalue and forget to do something with > > it. An alternative would be a cast to void, but that seems a little > > verbose for my taste. > > > > Suppose you have a UART buffer register that clears the "buffer full" > state on reading (this is a fine example of a volatile read having a > clear effect). > > extern volatile uint32_t uart_read_buffer; > > You are suggesting that to read the buffer but ignore the result, you > would write: > > +uart_read_buffer; > > That, IMHO, does not make anything clear to anyone. > > The most common way to dump a volatile read, as used in many embedded > systems, is: > > (void) uart_read_buffer; // Read the buffer but dump the result > > i.e., a cast to void and a comment to make the effect clear. > > I have also seen macros used to provide a kind of documentation here: > > #define DUMP(v) (void) v > DUMP(uart_read_buffer); /* buffercontrol.h */ extern volatile uint32_t uart_read_buffer; /* reading this memory mapped register clears buffer full flag */ #define clear_uart_buffer() ((void) uart_read_buffer) Now it just looks like a function that does something. Unless you need to know that it's a macro.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-30 22:30 +0200 |
| Message-ID | <87h9a2yp74.fsf@news.bourguet.org> |
| In reply to | #92958 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > /* buffercontrol.h */ > extern volatile uint32_t uart_read_buffer; > /* reading this memory mapped register clears buffer full flag */ > #define clear_uart_buffer() ((void) uart_read_buffer) > > Now it just looks like a function that does something. Unless you > need to know that it's a macro. The usual reason for which one want macro to be clearly marked is that they don't obey usual scoping rules, and thus may have surprising influence. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-31 09:17 +0200 |
| Message-ID | <nq60an$44r$1@dont-email.me> |
| In reply to | #92958 |
On 30/08/16 21:32, Malcolm McLean wrote:
> On Tuesday, August 30, 2016 at 8:24:56 PM UTC+1, David Brown wrote:
>> On 30/08/16 19:41, supercat@casperkitty.com wrote:
>>> On Tuesday, August 30, 2016 at 12:06:56 PM UTC-5, Tim Rentsch wrote:
>>>>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html
>>>>
>>>> In my view what is described on that page crosses the line, at
>>>> least in spirit. Implementations are not allowed to decide which
>>>> volatile-qualified accesses will be done and which will not;
>>>> they only get to decide how a VQA is carried out. Not whether,
>>>> only how. Not doing any access at all (the text doesn't say this
>>>> outright but it is implied) is not conforming, or at least not
>>>> spirit-conforming.
>>>
>>> A common fix I've seen for that is to apply a unary plus to the operand.
>>> In cases where an lvalue isn't used syntactically it may be unclear
>>> whether an rvalue conversion will be applied, but adding a "+" makes it
>>> unambiguous. It also makes it clearer to anyone reading the code that
>>> one didn't simply write out the lvalue and forget to do something with
>>> it. An alternative would be a cast to void, but that seems a little
>>> verbose for my taste.
>>>
>>
>> Suppose you have a UART buffer register that clears the "buffer full"
>> state on reading (this is a fine example of a volatile read having a
>> clear effect).
>>
>> extern volatile uint32_t uart_read_buffer;
>>
>> You are suggesting that to read the buffer but ignore the result, you
>> would write:
>>
>> +uart_read_buffer;
>>
>> That, IMHO, does not make anything clear to anyone.
>>
>> The most common way to dump a volatile read, as used in many embedded
>> systems, is:
>>
>> (void) uart_read_buffer; // Read the buffer but dump the result
>>
>> i.e., a cast to void and a comment to make the effect clear.
>>
>> I have also seen macros used to provide a kind of documentation here:
>>
>> #define DUMP(v) (void) v
>> DUMP(uart_read_buffer);
>
> /* buffercontrol.h */
> extern volatile uint32_t uart_read_buffer;
> /* reading this memory mapped register clears buffer full flag */
> #define clear_uart_buffer() ((void) uart_read_buffer)
>
> Now it just looks like a function that does something. Unless you
> need to know that it's a macro.
>
Or for people living and working in this century, you can use:
static inline void clear_uart_buffer(void) {
(void) uart_read_buffer;
}
Then it not only /looks/ like a function, but it /is/ a function.
It is fine to use function-like macros when you have to - such as when
it must work with a variety of types (such as the "DUMP" macro), or if
you are restricted to C90 for compatibility with other people who are
stuck with C90. But other than that, a static inline function in a case
like this is better in almost every way.
Whether you /need/ a specific function for a clear like this is another
matter - you almost certainly do not need it, because you are likely to
have this stuff contained within a single low-level uart driver file.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-31 22:46 -0700 |
| Message-ID | <kfnk2ewp3ym.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92953 |
supercat@casperkitty.com writes: > On Tuesday, August 30, 2016 at 12:06:56 PM UTC-5, Tim Rentsch wrote: >>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html >> >> In my view what is described on that page crosses the line, at >> least in spirit. Implementations are not allowed to decide which >> volatile-qualified accesses will be done and which will not; >> they only get to decide how a VQA is carried out. Not whether, >> only how. Not doing any access at all (the text doesn't say this >> outright but it is implied) is not conforming, or at least not >> spirit-conforming. > > A common fix I've seen for that is to apply a unary plus to the operand. > In cases where an lvalue isn't used syntactically it may be unclear > whether an rvalue conversion will be applied, [...] The Standard unambiguously requires: one, that an evaluated lvalue conversion access the designated object; and two, when the accessing type is volatile-qualified, then an access must be effected in the actual machine (and not just the abstract machine) during program execution. As far as I am concerned that settles the matter. If someone is unclear on these points then they are either ignorant or confused.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-31 10:29 -0700 |
| Message-ID | <lneg54c0dt.fsf@kst-u.example.com> |
| In reply to | #92951 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 29/08/16 18:28, Keith Thompson wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>> [...]
>>>>> The C standard is weak on this area - "What constitutes an access to an
>>>>> object that has volatile-qualified type" is implementation defined
>>>>> behaviour. So I think your answer here is that it depends on the compiler.
>>>>
>>>> [...]
>>>>
>>>> That's not what the standard says.
>>>>
>>>> N1570 6.7.3p7:
>>>>
>>>> What constitutes an access to an object that has volatile-qualified
>>>> type is implementation-defined.
>>>>
>>>> It's the question of whether a given operation is an access to a
>>>> volatile object that's implementation-defined, not the behavior.
>>>
>>> That is really the question. When you make a pointer-to-volatile
>>> using a cast, and access that, is it a volatile access or not? I
>>> /think/ the standard says the answer is implementation-defined - but I
>>> also think that compilers would treat all accesses via pointers as
>>> volatile accesses.
>>
>> My point is that you incorrectly introduce the phrase
>> "implementation defined behaviour". It's not the *behavior* that's
>> implementation-defined, it's the determination of what constitutes
>> an access.
>
> How this is phrased makes it hard to know what you mean. Let me
> try to break this down, as I understand what the Standard is
> saying.
>
> Which C constructs require a "volatile access" is exactly defined
> by the ISO standard. They are precisely those expressions whose
> evaluations cause an access (either reading or writing), and
> whose type is volatile-qualified. This aspect is not affected
> by 6.7.3p7.
That's not how I interpret(ed) it. Again, here's what the standard
says:
N1570 6.7.3p7:
What constitutes an access to an object that has
volatile-qualified type is implementation-defined.
Perhaps it's poorly phrased (or perhaps I'm just reading it poorly),
but I've always understood that to mean that the implementation
defines what is or is not an access to a volatile object.
The word "access" means "to read or modify the value of an object"
(the use of "access" as a noun rather than a verb follows naturally
from that). The definition says it's an "execution-time action".
It's stated in terms of C semantics, not whatever machine-level
operations are used to implement those semantics.
For a non-volatile object, an access is a read or a write. I
interpreted 6.7.3p7 to give the implementation some latitude in
determining what is or is not an access to a volatile object.
I was (somewhat vaguely) thinking that an implementation is still
allowed to optimize away some apparent accesses to volatile objects.
Which, now that I think about it, doesn't make a whole lot of sense.
> What is to be done to effect, or carry out, a volatile-qualified
> access is what must be defined by each implementation. This
> might be, eg: (a) ordinary reads and writes; (b) ordinary reads
> and "cache write-through" writes; (c) atomic reads and writes,
> and atomic read-modify-write for things like += or similar; or
> perhaps (d) reads and writes with memory barriers before and
> after. (This list is not meant to be exhaustive.) This aspect,
> "how a volatile-access is to be carried out", is exactly what an
> implementation must define (and document) under 6.7.3p7.
>
> The Standard isn't very good at spelling this out, but discussion
> in the Rationale document makes it all fairly clear (as usual,
> IMO).
Now that I think about it, your interpretation makes more sense
than mine (though I still think mine is more strongly suggested by
the wording). As you point out, the Rationale is clear on this:
No cacheing through this lvalue: each operation in the abstract
semantics must be performed (that is, no cacheing assumptions may be
made, since the location is not guaranteed to contain any previous
value).
though it doesn't discuss the implementation-defined something-or-other
of 6.7.3p7.
Perhaps the word "constitutes" is the problem?
So the idea is that the implementation must document *what happens*
when a volatile object is accessed. (And any such documentation
would have to be in terms of low-level semantics, below the usual
level of the abstract machine.)
The gcc documentation says (I'm paraphrasing here) that given
volatile SOME_TYPE *v = SOME_VALUE;
*v;
the expression `*v` may or may not read the volatile object,
depending on its type. That's consistent with my previous reading
of 6.7.3p7, but not with yours.
>> Once that's determined, the behavior might be either
>> well defined, implementation-defined, unspecified, or undefined,
>> depending on the specific code.
>
> To me this just seems wrong. What is to be done is determined by
> an implementation-defined statement. The Standard requires that
> this action, whatever it is, be carried out. The /consequences/
> of carrying out said action may be unbounded, but that is not the
> same as undefined behavior.
For example, `*v` where v is a null pointer has undefined
behavior, as does `v` (if v itself is volatile) where v's value
is indeterminate. But yes, if loading an indeterminate pointer
value into a register might cause a trap, the compiler still has
to generate code that actually attempts to load that value if the
pointer object is volatile; it can't assume that it's indeterminate
based on previous execution.
>> One example of how this is defined is here (for gcc):
>>
>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html
>
> In my view what is described on that page crosses the line, at
> least in spirit. Implementations are not allowed to decide which
> volatile-qualified accesses will be done and which will not;
> they only get to decide how a VQA is carried out. Not whether,
> only how. Not doing any access at all (the text doesn't say this
> outright but it is implied) is not conforming, or at least not
> spirit-conforming.
I think I agree.
--
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-31 10:12 -0700 |
| Message-ID | <e8bd75c3-14cb-469d-a864-e62d8085cc5f@googlegroups.com> |
| In reply to | #92995 |
On Wednesday, August 31, 2016 at 11:22:01 AM UTC-5, Keith Thompson wrote:
> I was (somewhat vaguely) thinking that an implementation is still
> allowed to optimize away some apparent accesses to volatile objects.
> Which, now that I think about it, doesn't make a whole lot of sense.
If a compiler knows that code will be running on hardware where volatile
reads of a certain location will always yield the value 12, it would be
entitled to replace reads of that location with loads of a constant 12
*provided* that the read still acted as a barrier to certain kinds of
optimization.
For example, given:
unsigned long long l1=0;
while((ll=func_with_no_outside_side_effects(ll)) != 12)
;
printf("Hey there!");
a compiler would be allowed to decide that the loop has no side-effects and
thus print "Hey there!" whether or not there's any way the function could
actually yield 12. If the loop had been:
while((ll=func_with_no_outside_side_effects(ll)) != volatile_yielding_12)
;
printf("Hey there!");
a compiler could compare the result of the function with a constant 12, but
would be required to loop forever if the function never yields that value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-31 12:30 -0700 |
| Message-ID | <lna8fsbut3.fsf@kst-u.example.com> |
| In reply to | #92998 |
supercat@casperkitty.com writes:
> On Wednesday, August 31, 2016 at 11:22:01 AM UTC-5, Keith Thompson wrote:
>> I was (somewhat vaguely) thinking that an implementation is still
>> allowed to optimize away some apparent accesses to volatile objects.
>> Which, now that I think about it, doesn't make a whole lot of sense.
>
> If a compiler knows that code will be running on hardware where volatile
> reads of a certain location will always yield the value 12, it would be
> entitled to replace reads of that location with loads of a constant 12
> *provided* that the read still acted as a barrier to certain kinds of
> optimization.
Not if the read has effects other than yielding 12.
[...]
--
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-31 11:32 -0700 |
| Message-ID | <db2ea16c-4f71-4259-a3d4-a557ed872c8f@googlegroups.com> |
| In reply to | #93007 |
On Wednesday, August 31, 2016 at 1:21:44 PM UTC-5, Keith Thompson wrote: > supercat writes: > > On Wednesday, August 31, 2016 at 11:22:01 AM UTC-5, Keith Thompson wrote: > >> I was (somewhat vaguely) thinking that an implementation is still > >> allowed to optimize away some apparent accesses to volatile objects. > >> Which, now that I think about it, doesn't make a whole lot of sense. > > > > If a compiler knows that code will be running on hardware where volatile > > reads of a certain location will always yield the value 12, it would be > > entitled to replace reads of that location with loads of a constant 12 > > *provided* that the read still acted as a barrier to certain kinds of > > optimization. > > Not if the read has effects other than yielding 12. Sorry--in reworking an earlier version of my statement, I accidentally left out "will always yield a value 12 *with no other side-effects*". My point was that if the compiler knows that a certain volatile access will not have any observable consequences at the hardware level, the as-if rule would allow it to omit the instructions that would perform those accesses, but cannot perform optimizations which would be precluded by their existence (e.g. treating a loop which has no side-effects other than those accesses as a loop which has no side effects at all).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-31 22:56 -0700 |
| Message-ID | <kfnfupkp3im.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92998 |
supercat@casperkitty.com writes: > On Wednesday, August 31, 2016 at 11:22:01 AM UTC-5, Keith Thompson wrote: >> I was (somewhat vaguely) thinking that an implementation is still >> allowed to optimize away some apparent accesses to volatile objects. >> Which, now that I think about it, doesn't make a whole lot of sense. > > If a compiler knows that code will be running on hardware where > volatile reads of a certain location will always yield the value > 12, it would be entitled to replace reads of that location with > loads of a constant 12 [...] No, it would not. The definition of volatile precludes such an inference. The whole point of volatile is so that a program can say, "Whatever it is you think you know about what is going on, forget it." The Standard requires implementations to disregard any such assumptions, and just blindly follow orders. Any implementation that does otherwise is not conforming.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-01 08:17 -0700 |
| Message-ID | <c6438dd0-c93c-4df4-8f50-dc24e66050a5@googlegroups.com> |
| In reply to | #93040 |
On Thursday, September 1, 2016 at 12:56:09 AM UTC-5, Tim Rentsch wrote:
> No, it would not. The definition of volatile precludes such an
> inference. The whole point of volatile is so that a program can
> say, "Whatever it is you think you know about what is going on,
> forget it." The Standard requires implementations to disregard
> any such assumptions, and just blindly follow orders. Any
> implementation that does otherwise is not conforming.
A number of platforms have instructions whose effects cannot be mimicked via
loads and stores of objects addresses via pointers. In some cases, it may be
useful to have a volatile store to a hard-coded address be translated by the
compiler into the instructions necessary to perform such operations. For
example, a platform that generally uses 16-bit addresses might apply special
treatment to "pointers" which are formed by casting certain 32-bit constants
and using them immediately, e.g.
(uint8_t volatile*)0xC0DE00AB = 0xCD;
might mask ask the compiler to load the accumulator with 0xCD and perform
an "OUT 0ABh" instruction. While the standard could be interpreted as
requiring that any pointer that can be constructed in such fashion must be
assignable to a "volatile*", such an interpretation wouldn't give
programmers any new abilities but would merely force the compiler to use
some other syntax for performing I/O (if a processor requires that I/O
addresses be hard-coded in the instruction, as do the 8080, 8051, and
a number of others, a compiler won't be able to let programmers store I/O
addresses in pointers regardless of what the Standard mandates). If an
implementation can specify that accesses to different addresses generate
different instructions, I see no reason it couldn't specify that accesses
to some particular address generate no code whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-04 22:18 -0700 |
| Message-ID | <kfnr38yncuj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93055 |
supercat@casperkitty.com writes: > On Thursday, September 1, 2016 at 12:56:09 AM UTC-5, Tim Rentsch wrote: >> No, it would not. The definition of volatile precludes such an >> inference. The whole point of volatile is so that a program can >> say, "Whatever it is you think you know about what is going on, >> forget it." The Standard requires implementations to disregard >> any such assumptions, and just blindly follow orders. Any >> implementation that does otherwise is not conforming. > > A number of platforms have instructions whose effects cannot be mimicked via > loads and stores of objects addresses via pointers. In some cases, it may be > useful to have a volatile store to a hard-coded address be translated by the > compiler into the instructions necessary to perform such operations. For > example, a platform that generally uses 16-bit addresses might apply special > treatment to "pointers" which are formed by casting certain 32-bit constants > and using them immediately, e.g. > > (uint8_t volatile*)0xC0DE00AB = 0xCD; > > might mask ask the compiler to load the accumulator with 0xCD and perform > an "OUT 0ABh" instruction. While the standard could be interpreted as > requiring that any pointer that can be constructed in such fashion must be > assignable to a "volatile*", such an interpretation wouldn't give > programmers any new abilities but would merely force the compiler to use > some other syntax for performing I/O (if a processor requires that I/O > addresses be hard-coded in the instruction, as do the 8080, 8051, and > a number of others, a compiler won't be able to let programmers store I/O > addresses in pointers regardless of what the Standard mandates). If an > implementation can specify that accesses to different addresses generate > different instructions, I see no reason it couldn't specify that accesses > to some particular address generate no code whatsoever. The situation described has undefined behavior before it ever gets to the volatile access.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-31 22:34 -0700 |
| Message-ID | <kfnoa48p4hs.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92995 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 29/08/16 18:28, Keith Thompson wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> [...] >>>>>> The C standard is weak on this area - "What constitutes an access >>>>>> to an object that has volatile-qualified type" is implementation >>>>>> defined behaviour. So I think your answer here is that it >>>>>> depends on the compiler. >>>>> >>>>> [...] >>>>> >>>>> That's not what the standard says. >>>>> >>>>> N1570 6.7.3p7: >>>>> >>>>> What constitutes an access to an object that has >>>>> volatile-qualified type is implementation-defined. >>>>> >>>>> It's the question of whether a given operation is an access to a >>>>> volatile object that's implementation-defined, not the behavior. >>>> >>>> That is really the question. When you make a pointer-to-volatile >>>> using a cast, and access that, is it a volatile access or not? [...] As I read the Standard (and tacitly said earlier), it is. >>> My point is that you incorrectly introduce the phrase >>> "implementation defined behaviour". It's not the *behavior* that's >>> implementation-defined, it's the determination of what constitutes >>> an access. >> >> How this is phrased makes it hard to know what you mean. Let me >> try to break this down, as I understand what the Standard is >> saying. >> >> Which C constructs require a "volatile access" is exactly defined >> by the ISO standard. They are precisely those expressions whose >> evaluations cause an access (either reading or writing), and >> whose type is volatile-qualified. This aspect is not affected >> by 6.7.3p7. > > That's not how I interpret(ed) it. [...] I was (somewhat > vaguely) thinking that an implementation is still allowed to > optimize away some apparent accesses to volatile objects. Which, > now that I think about it, doesn't make a whole lot of sense. Your comments do a great job of clarifying both viewpoints. I have almost nothing to add, except on an up-thread point above that I missed earlier, and to agree/amplify on your comment next. >> What is to be done to effect, or carry out, a volatile-qualified >> access is what must be defined by each implementation. [...] This >> aspect, "how a volatile-access is to be carried out", is exactly >> what an implementation must define (and document) under 6.7.3p7. >> >> The Standard isn't very good at spelling this out, but discussion >> in the Rationale document makes it all fairly clear (as usual, >> IMO). > > Now that I think about it, your interpretation makes more sense > than mine (though I still think mine is more strongly suggested by > the wording). As you point out, the Rationale is clear on this: > > No cacheing through this lvalue: each operation in the abstract > semantics must be performed (that is, no cacheing assumptions may be > made, since the location is not guaranteed to contain any previous > value). > > though it doesn't discuss the implementation-defined something-or-other > of 6.7.3p7. > > Perhaps the word "constitutes" is the problem? Yes, 6.7.3p7 is ambiguous by virtue of how "constitutes" is used: does it mean /what qualifies/ as a VQA, or does it mean /what actions will be used to carry out/ a VQA? And I pretty much agree that the first of these (which corresponds to your initial interpretation) is an easier impression to get on a first reading, despite my belief that the second is what was intended. That is unfortunate and would be nice to address in a future revision.
[toc] | [prev] | [next] | [standalone]
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web