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 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-01 00:32 -0700 |
| Message-ID | <ln37lkaxd0.fsf@kst-u.example.com> |
| In reply to | #93038 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> 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.
To put it another way (more succinctly than my previous followup),
if the authors of the standard had *intended* to say that an
implementation gets to decide what is and is not an "access" to a
volatile object (and must document that choice), then the current
wording of 6.7.3p7:
What constitutes an access to an object that has
volatile-qualified type is implementation-defined.
would have been a clear and reasonable way to express that intent.
(Though it would have required some added or modified wording
elsewhere to make that consistent with the definition of "access"
and the semantics of "volatile".)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-02 05:19 -0700 |
| Message-ID | <kfnlgzao5oh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93042 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> 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. > > To put it another way (more succinctly than my previous followup), > if the authors of the standard had *intended* to say that an > implementation gets to decide what is and is not an "access" to a > volatile object (and must document that choice), then the current > wording of 6.7.3p7: > > What constitutes an access to an object that has > volatile-qualified type is implementation-defined. > > would have been a clear and reasonable way to express that intent. > [.. incidental parenthetical remark ..] I'm afraid I cannot agree on this one. That sentence has an ambiguity, whatever you or I think is a more "natural" way of reading it. The problem is that what would be "clear" to one person might be "obviously wrong" to someone else. Apparently the original authors of the Standard thought the "strange" way of reading this sentence is how most people would read it. That by itself says to me that we need to find a better way of expressing what is meant here if we want a clear statement, no matter which meaning is intended.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-09-01 11:38 +0200 |
| Message-ID | <8760qg5592.fsf@news.bourguet.org> |
| In reply to | #92995 |
Keith Thompson <kst-u@mib.org> writes: > 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. Looking at the rationale, the intend seems to give room for the implementation to in the choice of the width of accessing instruction as well as in how to handle ++ and other cases where there is a read and a write between two sequencing points (is it one access with a read-write cycle or two accesses, one read and one write?). Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-01 10:03 -0700 |
| Message-ID | <lny43ba6xu.fsf@kst-u.example.com> |
| In reply to | #93045 |
Jean-Marc Bourguet <jm@bourguet.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> 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.
>
> Looking at the rationale, the intend seems to give room for the
> implementation to in the choice of the width of accessing instruction as
> well as in how to handle ++ and other cases where there is a read and a
> write between two sequencing points (is it one access with a read-write
> cycle or two accesses, one read and one write?).
I'm no longer convinced that there's any latitude in the treatment of ++
for volatile objects. 6.5.3.1p2 says:
The expression ++E is equivalent to (E+=1).
and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except
that lvalue of E1 is evaluated only once.
Given that 6.7.3p7 refers to what happens when an access occurs, rather
than what is or is not an access, I don't see any room for treating ++v
as a single access. (The side effect of the two accesses, one read and
one write, are implementation-defined.)
Postfix ++ might be a little more complicated.
--
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-09-01 10:31 -0700 |
| Message-ID | <70ddef2b-604b-479f-bf0c-048a69ef3bb8@googlegroups.com> |
| In reply to | #93060 |
On Thursday, September 1, 2016 at 10:47:17 AM UTC-5, Keith Thompson wrote: > I'm no longer convinced that there's any latitude in the treatment of ++ > for volatile objects. 6.5.3.1p2 says: > > The expression ++E is equivalent to (E+=1). > > and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except > that lvalue of E1 is evaluated only once. > > Given that 6.7.3p7 refers to what happens when an access occurs, rather > than what is or is not an access, I don't see any room for treating ++v > as a single access. (The side effect of the two accesses, one read and > one write, are implementation-defined.) There are many places where it makes sense to say that X is equivalent to Y in "normal" cases, while allowing for the possibility that they may have different behavior in some special cases. I do not believe the authors of the Standard intended to mandate absolute equivalence in cases like the one you cite, but merely wished to avoid having to describe the behavior of each compound assignment operator individually. Otherwise, if someone wants to insist that such behavior is non-conforming then I would add that to the list of ways in which a compiler that is non- conforming can be more *useful* than one which is conforming, since there are targets where it's useful to be able to distinguish between load ioReg; OR the value with 1; store ioReg vs OR ioReg with 1 and quality compilers for such targets should make it easy for programmers to make such distinctions, even if doing so would make them non-conforming. On the other hand, I don't think such behavior would be non-conforming. In an expression like "foo = foo & bar & boz;", if "foo" is not volatile, there will be no ordering relation between the read(s) of "foo" and the write(s), provided that the compiler ends up storing the same result as though the computation were done on the old value of "foo". If the variables are two words long, it would be quite reasonable for a compiler to compute and store the lower word before it does the upper word, and if one word of "bar" or "boz" were known to be zero the compiler might simply zero the corresponding word of "foo" without reading it. Given that the use of "foo" in the right hand side of an expression does not make reads ordered relative to writes when "foo" isn't volatile, I would see nothing that would change that if "foo" is volatile. Consequently, I'm not sure the Standard would impose any requirements on program behavior in any expression that reads and writes the same volatile variable. Hopefully compiler writers will merely use that fact to allow useful constructs like read-modify-write instructions, rather than "optimizing" code by treating such constructs as unreachable, but nothing in the Standard would mandate that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-01 12:50 -0700 |
| Message-ID | <lnmvjr9z7y.fsf@kst-u.example.com> |
| In reply to | #93067 |
supercat@casperkitty.com writes:
> On Thursday, September 1, 2016 at 10:47:17 AM UTC-5, Keith Thompson wrote:
>> I'm no longer convinced that there's any latitude in the treatment of ++
>> for volatile objects. 6.5.3.1p2 says:
>>
>> The expression ++E is equivalent to (E+=1).
>>
>> and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except
>> that lvalue of E1 is evaluated only once.
>>
>> Given that 6.7.3p7 refers to what happens when an access occurs, rather
>> than what is or is not an access, I don't see any room for treating ++v
>> as a single access. (The side effect of the two accesses, one read and
>> one write, are implementation-defined.)
>
> There are many places where it makes sense to say that X is equivalent to
> Y in "normal" cases, while allowing for the possibility that they may have
> different behavior in some special cases. I do not believe the authors of
> the Standard intended to mandate absolute equivalence in cases like the one
> you cite, but merely wished to avoid having to describe the behavior of
> each compound assignment operator individually.
I disagree. I *do* believe that the standard clearly and deliberately
states that `++E` is exactly equivalent to `(E+=1)`.
For a non-volatile E, that of course doesn't specify what machine
code should be generated for either construct. It means that
exactly the same compiler-specific and target-specific optimizations
are valid for either are valid for both. The two expressions mean
exactly the same thing (and if E is an object whose address is never
taken and value is never read after the expression is evaluated,
the expression can be optimized away altogether).
> Otherwise, if someone wants to insist that such behavior is non-conforming
> then I would add that to the list of ways in which a compiler that is non-
> conforming can be more *useful* than one which is conforming, since there
> are targets where it's useful to be able to distinguish between
>
> load ioReg; OR the value with 1; store ioReg
> vs
> OR ioReg with 1
>
> and quality compilers for such targets should make it easy for programmers
> to make such distinctions, even if doing so would make them non-conforming.
It might be useful to specify that distinction. The standard does not
support using `++E` vs. `(E+=1)` to make that distinction. Of course if
either instruction sequence is valid for either expression, then a
compiler can choose to consistently generate one for `++E` and the other
for `(E+=1)`, and document that it does so. I wouldn't even call that
an extension, since the behavior is entirely consistent with the
standard's requirements.
Equally, a compiler can choose to generate different code depending on
whether a referenced variable has a 'q' in its name, as long as both
versions of the generated code satisfy the standard's requirements.
In either case, I personally would prefer to have an
implementation-defined method of specifying the choice more
explicitly. But where a compiler can choose one of two or more
code sequences, all of which have conforming behavior, the way it
chooses which sequence to generate is unspecified and outside the
scope of the standard.
[...]
--
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 | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-09-01 21:30 +0200 |
| Message-ID | <87inuf5sff.fsf@news.bourguet.org> |
| In reply to | #93060 |
Keith Thompson <kst-u@mib.org> writes:
> Jean-Marc Bourguet <jm@bourguet.org> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> 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.
>>
>> Looking at the rationale, the intend seems to give room for the
>> implementation to in the choice of the width of accessing instruction as
>> well as in how to handle ++ and other cases where there is a read and a
>> write between two sequencing points (is it one access with a read-write
>> cycle or two accesses, one read and one write?).
>
> I'm no longer convinced that there's any latitude in the treatment of ++
> for volatile objects. 6.5.3.1p2 says:
>
> The expression ++E is equivalent to (E+=1).
>
> and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except
> that lvalue of E1 is evaluated only once.
I'm not sure that the intend wasn't for an implementation to be allowed to
use a read-modify-write instruction for E+=1.
A static-volatile object is an appropriate model for a memory
mapped-I/O register. Implementors of C translators should take into
account relevant hardware details on the target system when
implementing accesses to volatile objects. For instance, the hardware
logic of a system may require that a two-byte memory-mapped register
not be accessed with byte operations; and a compiler for such a system
would have to assure that no such instruction were generated, even if
the source code only accesses one byte of the register. Whether
read-modify-write instructions can be used on such device registers
must also be considered. Whatever decisions are adopted on such issues
must be documented, as volatile access is implementation-defined. A
volatile object is also an appropriate model for a variable shared
among multiple processes.
Note that corresponding section of gcc documentation says
In most expressions, it is intuitively obvious what is a read and what
is a write.
mention that there is no guaranteed of atomicity and continues by explaning
when a lone
*vp;
correspond to a read or not, avoiding the issue of rmw instruction. Its
behavior seems to avoid using such instruction on volatile data. (BTW, it's
the kind of thing where an implementation will do whatever they think is
the most usefull for its users, whatever the standard says;
interoperability for such matter is not of an high importance).
--
Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-02 05:37 -0700 |
| Message-ID | <kfnh99yo4uh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93060 |
Keith Thompson <kst-u@mib.org> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> 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. >> >> Looking at the rationale, the intend seems to give room for the >> implementation to in the choice of the width of accessing instruction as >> well as in how to handle ++ and other cases where there is a read and a >> write between two sequencing points (is it one access with a read-write >> cycle or two accesses, one read and one write?). > > I'm no longer convinced that there's any latitude in the treatment of ++ > for volatile objects. 6.5.3.1p2 says: > > The expression ++E is equivalent to (E+=1). > > and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except > that lvalue of E1 is evaluated only once. > > Given that 6.7.3p7 refers to what happens when an access occurs, rather > than what is or is not an access, I don't see any room for treating ++v > as a single access. (The side effect of the two accesses, one read and > one write, are implementation-defined.) I sort of agree with you, but there is a big "but". The "but" is this. Although two accesses (one for reading, one for writing) are required, my understanding is that both accesses may be accomplished by a single machine instruction (eg, some sort of read-modify-write). This possibility (to emphasize, as I understand things) is a consequence of the famous last sentence of 6.7.3p7 (and conveniently quoted above). I believe it was intended to provide enough latitude so that, eg, a VQ read access could be "the first half" of a read-modify-write, and a VQ write access could be "the second half" of a read-modify-write. So even though two accesses are required, that doesn't necessarily translate into two separate machine instructions. Of course, even assuming the above interpretation is correct, an implementation is required to document what the correspondence is between VQAs in the abstract machine and particular actions in the real machine. So we should be able to discover, by reading said documentation, whether such a mapping can occur in a given implementation.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-02 08:16 -0700 |
| Message-ID | <55bf2843-9e17-4221-bd1d-a5c6f71c7677@googlegroups.com> |
| In reply to | #93104 |
On Friday, September 2, 2016 at 7:37:22 AM UTC-5, Tim Rentsch wrote: > The "but" is this. Although two accesses (one for reading, one > for writing) are required, my understanding is that both accesses > may be accomplished by a single machine instruction (eg, some > sort of read-modify-write). Given the code someVolatile = someVolatile & 0; would there be anything in the Standard that would forbid an implementation from generating code equivalent to: someVolatile = 0; temp = someVolatile; // Value of temp is ignored. The Standard does require that if the same lvalue is used on the left and right side of an assignment a compiler must ensure that expression computes the same value it would have computed if the right-hand reads were performed before the left-hand writes, but that doesn't imply any sequencing relation beyond what would be necessary to achieve that.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-04 22:20 -0700 |
| Message-ID | <kfnmvjmncsd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93113 |
supercat@casperkitty.com writes: > On Friday, September 2, 2016 at 7:37:22 AM UTC-5, Tim Rentsch wrote: >> The "but" is this. Although two accesses (one for reading, one >> for writing) are required, my understanding is that both accesses >> may be accomplished by a single machine instruction (eg, some >> sort of read-modify-write). > > Given the code > > someVolatile = someVolatile & 0; > > would there be anything in the Standard that would forbid an implementation > from generating code equivalent to: > > someVolatile = 0; > temp = someVolatile; // Value of temp is ignored. > > [...] This question seems designed to start an argument more than elicit an answer.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-06 07:32 -0700 |
| Message-ID | <c06c2620-8fc9-4c66-a600-97d02c3c7014@googlegroups.com> |
| In reply to | #93201 |
On Monday, September 5, 2016 at 12:20:11 AM UTC-5, Tim Rentsch wrote: > supercat writes: > > > On Friday, September 2, 2016 at 7:37:22 AM UTC-5, Tim Rentsch wrote: > >> The "but" is this. Although two accesses (one for reading, one > >> for writing) are required, my understanding is that both accesses > >> may be accomplished by a single machine instruction (eg, some > >> sort of read-modify-write). > > > > Given the code > > > > someVolatile = someVolatile & 0; > > > > would there be anything in the Standard that would forbid an implementation > > from generating code equivalent to: > > > > someVolatile = 0; > > temp = someVolatile; // Value of temp is ignored. > > > > [...] > > This question seems designed to start an argument more than > elicit an answer. If there is anything in the Standard that would specify the order, it should be possible to cite it. If there isn't, then it should be possible to simply say that. If the latter is the case, that would imply that a compiler given code which does a read and a write without rigid sequencing would be allowed to do anything it likes, a state of affairs which should pose no problem if compiler writers recognize that quality compilers should behave in a fashion appropriate to the underlying hardware platform (as the authors of the Standard expected compilers would typically do in many places where they imposed no requirements).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-11 06:54 -0700 |
| Message-ID | <kfnfup6leyh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93257 |
supercat@casperkitty.com writes: > On Monday, September 5, 2016 at 12:20:11 AM UTC-5, Tim Rentsch wrote: >> supercat writes: >> >>> On Friday, September 2, 2016 at 7:37:22 AM UTC-5, Tim Rentsch wrote: >>>> The "but" is this. Although two accesses (one for reading, one >>>> for writing) are required, my understanding is that both accesses >>>> may be accomplished by a single machine instruction (eg, some >>>> sort of read-modify-write). >>> >>> Given the code >>> >>> someVolatile = someVolatile & 0; >>> >>> would there be anything in the Standard that would forbid an implementation >>> from generating code equivalent to: >>> >>> someVolatile = 0; >>> temp = someVolatile; // Value of temp is ignored. >>> >>> [...] >> >> This question seems designed to start an argument more than >> elicit an answer. > > If there is anything in the Standard that would specify the order, it > should be possible to cite it. If there isn't, then it should be possible > to simply say that. [...] If you think that's true then you shouldn't have any problem finding the relevant passages to reach an appropriate conclusion. When you do that be sure to quote those passages in your posting so people can follow your reasoning. If you do that I can post a followup response if anything looks like it merits further attention. And if you don't, I will just stand by my previous comment.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-02 08:40 -0700 |
| Message-ID | <lneg529unt.fsf@kst-u.example.com> |
| In reply to | #93104 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Given that 6.7.3p7 refers to what happens when an access occurs, rather
>> than what is or is not an access, I don't see any room for treating ++v
>> as a single access. (The side effect of the two accesses, one read and
>> one write, are implementation-defined.)
>
> I sort of agree with you, but there is a big "but".
>
> The "but" is this. Although two accesses (one for reading, one
> for writing) are required, my understanding is that both accesses
> may be accomplished by a single machine instruction (eg, some
> sort of read-modify-write). This possibility (to emphasize, as I
> understand things) is a consequence of the famous last sentence
> of 6.7.3p7 (and conveniently quoted above). I believe it was
> intended to provide enough latitude so that, eg, a VQ read access
> could be "the first half" of a read-modify-write, and a VQ write
> access could be "the second half" of a read-modify-write. So
> even though two accesses are required, that doesn't necessarily
> translate into two separate machine instructions.
I agree. More generally, the standard says nothing about the
machine instructions that are generated for any given C code. If a
"hello world" program can be implemented by a single HELLOWORLD
CPU instruction, that's fine.
> Of course, even assuming the above interpretation is correct, an
> implementation is required to document what the correspondence is
> between VQAs in the abstract machine and particular actions in
> the real machine. So we should be able to discover, by reading
> said documentation, whether such a mapping can occur in a given
> implementation.
It's not clear how much detail the implementation's documentation
has to go into. Certainly gcc's documentation doesn't go down to
the machine level. (It would have to do so separately for each
target it supports.)
--
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-09-02 10:16 -0700 |
| Message-ID | <2fe3f021-1aaf-438f-bc03-fd4f233d160f@googlegroups.com> |
| In reply to | #93117 |
On Friday, September 2, 2016 at 10:36:10 AM UTC-5, Keith Thompson wrote: > It's not clear how much detail the implementation's documentation > has to go into. Certainly gcc's documentation doesn't go down to > the machine level. (It would have to do so separately for each > target it supports.) That's a general problem with a lot of "implementation-defined" aspects. The Standard really should use different terminology to distinguish between cases where implementations must document a choice from among a discrete set of possibilities (e.g. the number of bits in a character), versus cases where there is an essentially infinite set of possibilities but most implementations will do one of a few things (e.g. the effect of right-shifting a negative number), versus those where possibilities are more wide open (e.g. the way in which volatile accesses are handled with constant or non-constant addresses).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-04 15:16 -0700 |
| Message-ID | <kfnvaybmht4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93117 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [can 'v += 1', with 'v' volatile, be done with, eg, one opcode?] > >> Of course, even assuming the above interpretation is correct, an >> implementation is required to document what the correspondence is >> between VQAs in the abstract machine and particular actions in >> the real machine. So we should be able to discover, by reading >> said documentation, whether such a mapping can occur in a given >> implementation. > > It's not clear how much detail the implementation's documentation > has to go into. Certainly gcc's documentation doesn't go down to > the machine level. [...] I agree it isn't clear how much detail is required. OTOH if the documentation provided doesn't allow one to answer questions like this then IMO the implementation is not doing its job. The point of requiring certain behaviors be defined /and documented/ is so we can know how the implementation will behave. The property in question seems like one it is reasonable to want to know the answer to.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-25 08:28 -0700 |
| Message-ID | <11e2bb75-ee3c-4904-b7c8-77023426fb45@googlegroups.com> |
| In reply to | #92696 |
On Thursday, August 25, 2016 at 3:29:43 PM UTC+1, supe...@casperkitty.com wrote: > 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? > A flag will do. The difficult isn't in setting a flag, assuming that writes of a single byte are atomic and can't be interrupted. It's what to do if the resource is locked. Sometimes you can yield until it comes free, sometimes you can skip the operation and hope to pick it up on the next pass, sometimes you can use double buffering.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-25 10:14 -0700 |
| Message-ID | <c61b98eb-0d30-40aa-986e-0914e2680d96@googlegroups.com> |
| In reply to | #92698 |
On Thursday, August 25, 2016 at 10:28:20 AM UTC-5, Malcolm McLean wrote:
> On Thursday, August 25, 2016 at 3:29:43 PM UTC+1, supercat wrote:
> > 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?
> >
> A flag will do.
>
> The difficult isn't in setting a flag, assuming that writes of a single byte are atomic
> and can't be interrupted. It's what to do if the resource is locked.
Do you means a "flag", as in:
unsigned char data_source_1[64], data_source_2[64];
unsigned char data_buff[64];
volatile atomic_byte buffer_busy;
while(buffer_busy)
;
memcpy(data_buff, data_source_1, 64);
buffer_busy = 1; // Tell interrupt to send data & clear flag
while(buffer_busy)
;
memcpy(data_buff, data_source_1, 64);
buffer_busy = 1;
That's the pattern I'd like to use, but nothing in the Standard would
forbid a compiler from moving the memcpy operation before the "while()"
statement.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 00:54 -0700 |
| Message-ID | <dbd18ddd-01c1-445a-92f1-1198c0c51539@googlegroups.com> |
| In reply to | #92702 |
On Thursday, August 25, 2016 at 6:15:00 PM UTC+1, supe...@casperkitty.com wrote: > > Do you means a "flag", as in: > > unsigned char data_source_1[64], data_source_2[64]; > unsigned char data_buff[64]; > > volatile atomic_byte buffer_busy; > > while(buffer_busy) > ; > memcpy(data_buff, data_source_1, 64); > buffer_busy = 1; // Tell interrupt to send data & clear flag > while(buffer_busy) > ; > memcpy(data_buff, data_source_1, 64); > buffer_busy = 1; > > That's the pattern I'd like to use, but nothing in the Standard would > forbid a compiler from moving the memcpy operation before the "while()" > statement.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 01:00 -0700 |
| Message-ID | <ffdc9c87-29a2-4769-9399-667ee00491a1@googlegroups.com> |
| In reply to | #92702 |
On Thursday, August 25, 2016 at 6:15:00 PM UTC+1, supe...@casperkitty.com wrote: > On Thursday, August 25, 2016 at 10:28:20 AM UTC-5, Malcolm McLean wrote: > > On Thursday, August 25, 2016 at 3:29:43 PM UTC+1, supercat wrote: > > > 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? > > > > > A flag will do. > > > > The difficult isn't in setting a flag, assuming that writes of a single byte are atomic > > and can't be interrupted. It's what to do if the resource is locked. > > Do you means a "flag", as in: > > unsigned char data_source_1[64], data_source_2[64]; > unsigned char data_buff[64]; > > volatile atomic_byte buffer_busy; > > while(buffer_busy) > ; > memcpy(data_buff, data_source_1, 64); > buffer_busy = 1; // Tell interrupt to send data & clear flag > while(buffer_busy) > ; > memcpy(data_buff, data_source_1, 64); > buffer_busy = 1; > > That's the pattern I'd like to use, but nothing in the Standard would > forbid a compiler from moving the memcpy operation before the "while()" > statement. > Exactly. Details would vary according to the thread mechanism (interrupt service routines, threads, etc). But the basic idea is that a single flag says who owns the data and whether it is safe to read or safe to write. Because you can only read from the buffer when it is in a coherent state. If this is not allowed, then it is deeply problematic for anyone using C for low-level, hardware interacting routines.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 11:17 +0100 |
| Message-ID | <87vaynj0l9.fsf@bsb.me.uk> |
| In reply to | #92712 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, August 25, 2016 at 6:15:00 PM UTC+1, supe...@casperkitty.com wrote: >> On Thursday, August 25, 2016 at 10:28:20 AM UTC-5, Malcolm McLean wrote: >> > On Thursday, August 25, 2016 at 3:29:43 PM UTC+1, supercat wrote: >> > > 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? >> > > >> > A flag will do. >> > >> > The difficult isn't in setting a flag, assuming that writes of a >> > single byte are atomic >> > and can't be interrupted. It's what to do if the resource is locked. >> >> Do you means a "flag", as in: >> >> unsigned char data_source_1[64], data_source_2[64]; >> unsigned char data_buff[64]; >> >> volatile atomic_byte buffer_busy; >> >> while(buffer_busy) >> ; >> memcpy(data_buff, data_source_1, 64); >> buffer_busy = 1; // Tell interrupt to send data & clear flag >> while(buffer_busy) >> ; >> memcpy(data_buff, data_source_1, 64); >> buffer_busy = 1; >> >> That's the pattern I'd like to use, but nothing in the Standard would >> forbid a compiler from moving the memcpy operation before the "while()" >> statement. >> > Exactly. > Details would vary according to the thread mechanism (interrupt > service routines, threads, etc). But the basic idea is that a > single flag says who owns the data and whether it is safe to read > or safe to write. Maybe you have a broader concept of what's a detail than I do, but unless there is some magic involved, a single atomic flag won't work even with two threads using the buffer as above. I think supercat is thinking that there will only ever be one thread putting data in the buffer. Than again, you may not be suggesting that this scheme generalises -- I was not sure exactly what your point was. > Because you can only read from the buffer when it > is in a coherent state. > If this is not allowed, then it is deeply problematic for anyone > using C for low-level, hardware interacting routines. C11 has atomic read/modify/write operations and various memory access ordering primitives, but I think this thread grew out of a desire to mange things with only minimal language support. If you don't have these, you pretty much have to rely on other implementation-provided mechanisms and guarantees. That's obviously what's going on in supercat's example. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web