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 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-30 02:19 -0700 |
| Message-ID | <5360abf3-5d04-4370-b7b0-eb4d0fe9d375@googlegroups.com> |
| In reply to | #92920 |
On Tuesday, August 30, 2016 at 9:38:11 AM UTC+3, supe...@casperkitty.com wrote: > On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: > > Perhaps this might be of interest to you: > > https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ > > Ad hoc solutions work fine if people recognize the value of recognizing > precedent, and of establishing an orderly process for deprecating bad > precedents *by providing a migration path to something that's essentially > as good in all important respects*. That's what happened with e.g. > <varargs.h> being replaced by <stdarg.h>, or old-style function declarations > being replaced by prototype syntax. > > Unfortunately, since many key precedents that were responsible for C's > popularity were never acknowledged, there was never any procedure for > deprecating them nor for defining any replacement. I'd very much like to see 'volatile' itself deprecated in favor of procedural-style alternative. Declarative nature of 'volatile' just feels wrong to my programmer's reflexes. In C++ it would be something like generic intrinsic procedures: T __globally_observed_load<T>(const T* src); void __globally_observed_store<T>(T* dst); I am not sure how it can be expressed in C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 13:26 +0200 |
| Message-ID | <nq3qgv$dq4$1@dont-email.me> |
| In reply to | #92929 |
On 30/08/16 11:19, already5chosen@yahoo.com wrote: > On Tuesday, August 30, 2016 at 9:38:11 AM UTC+3, supe...@casperkitty.com wrote: >> On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: >>> Perhaps this might be of interest to you: >>> https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ >> >> Ad hoc solutions work fine if people recognize the value of recognizing >> precedent, and of establishing an orderly process for deprecating bad >> precedents *by providing a migration path to something that's essentially >> as good in all important respects*. That's what happened with e.g. >> <varargs.h> being replaced by <stdarg.h>, or old-style function declarations >> being replaced by prototype syntax. >> >> Unfortunately, since many key precedents that were responsible for C's >> popularity were never acknowledged, there was never any procedure for >> deprecating them nor for defining any replacement. > > I'd very much like to see 'volatile' itself deprecated in favor of procedural-style alternative. Declarative nature of 'volatile' just feels wrong to my programmer's reflexes. > > In C++ it would be something like generic intrinsic procedures: > T __globally_observed_load<T>(const T* src); > void __globally_observed_store<T>(T* dst); > I am not sure how it can be expressed in C. > You can come a long way by using a simple macro: #define ACCESS_ONCE(v) *((volatile typeof((v)) *) &(v)) (I think that's how Linux defines it.) Then you can tie the "volatile" aspect to the access, rather than to the variable. With a little more sophisticated macro containing memory barriers, you could get the same effect as your suggested C++ interface.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-30 04:40 -0700 |
| Message-ID | <7ab27872-351b-4a6d-aa65-f19883d80ba4@googlegroups.com> |
| In reply to | #92934 |
On Tuesday, August 30, 2016 at 2:26:31 PM UTC+3, David Brown wrote: > On 30/08/16 11:19, already5chosen@yahoo.com wrote: > > On Tuesday, August 30, 2016 at 9:38:11 AM UTC+3, supe...@casperkitty.com wrote: > >> On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: > >>> Perhaps this might be of interest to you: > >>> https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ > >> > >> Ad hoc solutions work fine if people recognize the value of recognizing > >> precedent, and of establishing an orderly process for deprecating bad > >> precedents *by providing a migration path to something that's essentially > >> as good in all important respects*. That's what happened with e.g. > >> <varargs.h> being replaced by <stdarg.h>, or old-style function declarations > >> being replaced by prototype syntax. > >> > >> Unfortunately, since many key precedents that were responsible for C's > >> popularity were never acknowledged, there was never any procedure for > >> deprecating them nor for defining any replacement. > > > > I'd very much like to see 'volatile' itself deprecated in favor of procedural-style alternative. Declarative nature of 'volatile' just feels wrong to my programmer's reflexes. > > > > In C++ it would be something like generic intrinsic procedures: > > T __globally_observed_load<T>(const T* src); > > void __globally_observed_store<T>(T* dst); > > I am not sure how it can be expressed in C. > > > > You can come a long way by using a simple macro: > > #define ACCESS_ONCE(v) *((volatile typeof((v)) *) &(v)) > That does not advance us toward an ultimate goal of deprecation of 'volatile'. > (I think that's how Linux defines it.) > > Then you can tie the "volatile" aspect to the access, rather than to the > variable. > > With a little more sophisticated macro containing memory barriers, you > could get the same effect as your suggested C++ interface. My suggested interface does not imply memory barrier, neither HW nor compiler's. I am not even sure that I want an implied barrier relatively to other invocations of __globally_observed_xxx(). I didn't really *think* about it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 13:56 +0200 |
| Message-ID | <nq3s9p$iiu$2@dont-email.me> |
| In reply to | #92939 |
On 30/08/16 13:40, already5chosen@yahoo.com wrote: > On Tuesday, August 30, 2016 at 2:26:31 PM UTC+3, David Brown wrote: >> On 30/08/16 11:19, already5chosen@yahoo.com wrote: >>> On Tuesday, August 30, 2016 at 9:38:11 AM UTC+3, supe...@casperkitty.com wrote: >>>> On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: >>>>> Perhaps this might be of interest to you: >>>>> https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ >>>> >>>> Ad hoc solutions work fine if people recognize the value of recognizing >>>> precedent, and of establishing an orderly process for deprecating bad >>>> precedents *by providing a migration path to something that's essentially >>>> as good in all important respects*. That's what happened with e.g. >>>> <varargs.h> being replaced by <stdarg.h>, or old-style function declarations >>>> being replaced by prototype syntax. >>>> >>>> Unfortunately, since many key precedents that were responsible for C's >>>> popularity were never acknowledged, there was never any procedure for >>>> deprecating them nor for defining any replacement. >>> >>> I'd very much like to see 'volatile' itself deprecated in favor of procedural-style alternative. Declarative nature of 'volatile' just feels wrong to my programmer's reflexes. >>> >>> In C++ it would be something like generic intrinsic procedures: >>> T __globally_observed_load<T>(const T* src); >>> void __globally_observed_store<T>(T* dst); >>> I am not sure how it can be expressed in C. >>> >> >> You can come a long way by using a simple macro: >> >> #define ACCESS_ONCE(v) *((volatile typeof((v)) *) &(v)) >> > > That does not advance us toward an ultimate goal of deprecation of 'volatile'. "volatile" will never disappear from the C (or C++) language, nor will it ever be deprecated. But you might want to deprecate it's explicit use from your own code - just as Linux has done. > >> (I think that's how Linux defines it.) >> >> Then you can tie the "volatile" aspect to the access, rather than to the >> variable. >> >> With a little more sophisticated macro containing memory barriers, you >> could get the same effect as your suggested C++ interface. > > My suggested interface does not imply memory barrier, neither HW nor compiler's. > I am not even sure that I want an implied barrier relatively to > other invocations of __globally_observed_xxx(). I didn't really *think* about it. > Well, add whatever memory barriers or synchronisation instructions you feel are appropriate. Or use the C11 atomic access functions, that should already handle that sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-04 15:43 +0100 |
| Message-ID | <o21a1o$uc4$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #92929 |
In article <5360abf3-5d04-4370-b7b0-eb4d0fe9d375@googlegroups.com>, <already5chosen@yahoo.com> wrote: >On Tuesday, August 30, 2016 at 9:38:11 AM UTC+3, supe...@casperkitty.com wrote: >> On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: >> > Perhaps this might be of interest to you: >> > https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ >> >> Ad hoc solutions work fine if people recognize the value of recognizing >> precedent, and of establishing an orderly process for deprecating bad >> precedents *by providing a migration path to something that's essentially >> as good in all important respects*. That's what happened with e.g. >> <varargs.h> being replaced by <stdarg.h>, or old-style function declarations >> being replaced by prototype syntax. >> >> Unfortunately, since many key precedents that were responsible for C's >> popularity were never acknowledged, there was never any procedure for >> deprecating them nor for defining any replacement. > >I'd very much like to see 'volatile' itself deprecated in favor of procedural-style alternative. Declarative nature of 'volatile' just feels wrong to my programmer's reflexes. > >In C++ it would be something like generic intrinsic procedures: >T __globally_observed_load<T>(const T* src); >void __globally_observed_store<T>(T* dst); >I am not sure how it can be expressed in C. This corresponds with the way I handle this in my (experimental) Forth optimiser. fetch has in "input side effect", store has an "output side effect". The optimiser logic goes as follows: If the result of a fetch isn't used, the fetch itself may be dropped. If a store is done again before a fetch from the location is done, the first store can be dropped. The latter will be checked mostly as "no intervening instruction has an input side effect". Now for I/O ports. A port fetch as well as a store have "input and output side effects". Those can never be optimised away. So all the logic around this is is in functions called: @ ! P@ P! where the prefix P means port, effectively volatile. The addresses from where the fetches and stores are done don't enter the optimisation logic at all. As usual in Forth there is nothing to protect a programmer from doing a normal fetch from a port, where a port fetch is indicated. (Nor from doing a byte port fetch where a word port fetch would be indicated.) Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-30 19:34 +1200 |
| Message-ID | <e2kr7pFec6gU1@mid.individual.net> |
| In reply to | #92903 |
On 08/30/16 09:08 AM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 3:07:49 PM UTC-5, Ian Collins wrote: >> Atomics and synchroniszation primitives. > > And what kinds of primitives are available in a "bare-metal" freestanding C > implementation? The standard ones if your compiler has caught up. If it hasn't, use C++ where they are well supported. It's a real shame that C implementations have lagged behind in this important area for embedded programming. > Many of the C implementations I use give the programmer > explicit control over the reset vector and all interrupt vectors; from the > compiler's point of view, an interrupt is a piece of code that might be > executed at any time for reasons it knows nothing about. What kinds of > primitives would you expect them to provide, and how would you suggest that > I should go about using them? The same answer as above. All of the bare metal devices I'm working on now ad recently (nearly all ARM of one kind or another) support gcc (or g++) so there is a choice of the gcc or standard (in C++) atomics and either our ROTS of choice or standard (in C++) threading. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-30 00:51 -0700 |
| Message-ID | <e59548f3-843a-4f32-baaa-94a84cef8ae3@googlegroups.com> |
| In reply to | #92923 |
On Tuesday, August 30, 2016 at 2:34:27 AM UTC-5, Ian Collins wrote: > On 08/30/16 09:08 AM, supercat wrote: > > And what kinds of primitives are available in a "bare-metal" freestanding C > > implementation? ... > The same answer as above. All of the bare metal devices I'm working on > now ad recently (nearly all ARM of one kind or another) support gcc (or > g++) so there is a choice of the gcc or standard (in C++) atomics and > either our ROTS of choice or standard (in C++) threading. Where does the logic for things like locks, spin-waiting, etc. come from, if not from a library which needs to itself be written in something, and may need to be adjusted according to how the target system works?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-30 20:36 +1200 |
| Message-ID | <e2kut8Fec6gU2@mid.individual.net> |
| In reply to | #92925 |
On 08/30/16 07:51 PM, supercat@casperkitty.com wrote: > On Tuesday, August 30, 2016 at 2:34:27 AM UTC-5, Ian Collins wrote: >> On 08/30/16 09:08 AM, supercat wrote: >>> And what kinds of primitives are available in a "bare-metal" freestanding C >>> implementation? > ... >> The same answer as above. All of the bare metal devices I'm working on >> now ad recently (nearly all ARM of one kind or another) support gcc (or >> g++) so there is a choice of the gcc or standard (in C++) atomics and >> either our ROTS of choice or standard (in C++) threading. > > Where does the logic for things like locks, spin-waiting, etc. come from, > if not from a library which needs to itself be written in something, and > may need to be adjusted according to how the target system works? The low level primitives will be written in a mixture of assembler and C. It isn't any different form those on any operating system. Have a look at the gcc library for ARM if you want to see how. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-08-31 00:39 -0500 |
| Message-ID | <f0rcsb5hcieujv7sp45lgdedmu862knfc8@4ax.com> |
| In reply to | #92815 |
On Sat, 27 Aug 2016 13:10:27 -0700 (PDT), supercat@casperkitty.com wrote: >On Saturday, August 27, 2016 at 8:11:48 AM UTC-5, Jerry Stuckle wrote: >> No, but in every processor I know of which has kernel and user modes, >> including mainframes, disabling interrupts is a privileged operation, >> not available to user programs. > >I've often wished processors would include an instruction which would >allow pending interrupts to execute and then disable interrupts for >e.g. the next 16 cycles (more for machines that take multiple cycles for >each instruction). Executing such an instruction while interrupts are >disabled from the previous one shouldn't trap, but should negate the >effects of the previous one (servicing pending interrupts) before >disabling interrupts again. Getting the semantics right in system with >virtual memory would be a bit tricky, making such an instruction safely >available within user mode would allow many kinds of operations to be >greatly simplified in single-core systems without virtual memory. While hardly general purpose, x86 has always* prevented interrupts from occurring after (certain) instructions that load the SS segment register - specifically so that the corresponding address register can be loaded safely as well. *The first stepping of the 8086 didn't do that, and it was discovered that there was no actual way to safely change the stack pointer.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-26 21:40 -0700 |
| Message-ID | <npr5k9$9io$1@dont-email.me> |
| In reply to | #92780 |
On 8/26/2016 7:54 PM, Jerry Stuckle wrote: > On 8/26/2016 10:32 PM, Malcolm McLean wrote: >> On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >>> >>> Volatile is essentially useless for what it isn't intended to do! It >>> does its intended job perfectly well. >>> >> volatile means that the object is subject to change at any time >> by an outside force. But that only makes sense if it is coherent. >> >> We can obviously change the price of beer. Due to the wicked and >> excessive taxes exacted by government, it might have to go up >> 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate >> second between the barman rubbing out the 2 and writing the 3 >> when you can get a beer for 3.0. That's nonsense. Any rule that >> allows modification has to allow for temporary suspension during >> the period of modification itself. >> > > Sorry, in this case Ian is correct. Any user-mode operation which takes > more than one assembler instruction can be interrupted between > instructions, leaving the storage partially updated. > > That's why there are mutex (mutual exclusion) semaphores. But everyone > has to agree to use them. > > And user-mode programs cannot temporarily suspend interrupts. That is a > privileged operation. > > You may not like it - but that's the facts. > Also, one cannot use a mutex in an interrupt handler. Deathlocked!
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 09:22 -0400 |
| Message-ID | <nps46i$ueo$1@jstuckle.eternal-september.org> |
| In reply to | #92788 |
On 8/27/2016 12:40 AM, Chris M. Thomasson wrote: > On 8/26/2016 7:54 PM, Jerry Stuckle wrote: >> On 8/26/2016 10:32 PM, Malcolm McLean wrote: >>> On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >>>> >>>> Volatile is essentially useless for what it isn't intended to do! It >>>> does its intended job perfectly well. >>>> >>> volatile means that the object is subject to change at any time >>> by an outside force. But that only makes sense if it is coherent. >>> >>> We can obviously change the price of beer. Due to the wicked and >>> excessive taxes exacted by government, it might have to go up >>> 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate >>> second between the barman rubbing out the 2 and writing the 3 >>> when you can get a beer for 3.0. That's nonsense. Any rule that >>> allows modification has to allow for temporary suspension during >>> the period of modification itself. >>> >> >> Sorry, in this case Ian is correct. Any user-mode operation which takes >> more than one assembler instruction can be interrupted between >> instructions, leaving the storage partially updated. >> >> That's why there are mutex (mutual exclusion) semaphores. But everyone >> has to agree to use them. >> >> And user-mode programs cannot temporarily suspend interrupts. That is a >> privileged operation. >> >> You may not like it - but that's the facts. >> > > Also, one cannot use a mutex in an interrupt handler. Deathlocked! Actually, you can but you need to be careful and handle the case of the mutex already being locked. Usually this means re-enabling interrupts before attempting to lock the mutex or passing the data on to a separate thread. However, the latter generally means adding to a linked list, which also requires a mutex. So the thread handling the request has to disable interrupts while the mutex is locked. All kinds of things can happen when you're dealing with the kernel and interrupts! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-29 11:36 -0700 |
| Message-ID | <nq1vb6$207$1@dont-email.me> |
| In reply to | #92798 |
On 8/27/2016 6:22 AM, Jerry Stuckle wrote: > On 8/27/2016 12:40 AM, Chris M. Thomasson wrote: >> On 8/26/2016 7:54 PM, Jerry Stuckle wrote: >>> On 8/26/2016 10:32 PM, Malcolm McLean wrote: >>>> On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >>>>> >>>>> Volatile is essentially useless for what it isn't intended to do! It >>>>> does its intended job perfectly well. >>>>> >>>> volatile means that the object is subject to change at any time >>>> by an outside force. But that only makes sense if it is coherent. >>>> >>>> We can obviously change the price of beer. Due to the wicked and >>>> excessive taxes exacted by government, it might have to go up >>>> 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate >>>> second between the barman rubbing out the 2 and writing the 3 >>>> when you can get a beer for 3.0. That's nonsense. Any rule that >>>> allows modification has to allow for temporary suspension during >>>> the period of modification itself. >>>> >>> >>> Sorry, in this case Ian is correct. Any user-mode operation which takes >>> more than one assembler instruction can be interrupted between >>> instructions, leaving the storage partially updated. >>> >>> That's why there are mutex (mutual exclusion) semaphores. But everyone >>> has to agree to use them. >>> >>> And user-mode programs cannot temporarily suspend interrupts. That is a >>> privileged operation. >>> >>> You may not like it - but that's the facts. >>> >> >> Also, one cannot use a mutex in an interrupt handler. Deathlocked! > > Actually, you can but you need to be careful and handle the case of the > mutex already being locked. Yeah. A nasty deadlock can occur if the thread that owns the mutex is the same thread running the damn interrupt! :^o > Usually this means re-enabling interrupts > before attempting to lock the mutex or passing the data on to a separate > thread. However, the latter generally means adding to a linked list, > which also requires a mutex. So the thread handling the request has to > disable interrupts while the mutex is locked. > > All kinds of things can happen when you're dealing with the kernel and > interrupts! Big time! :^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-09 16:26 -0800 |
| Message-ID | <o2fi0i$jb5$1@dont-email.me> |
| In reply to | #92798 |
On 8/27/2016 6:22 AM, Jerry Stuckle wrote: > On 8/27/2016 12:40 AM, Chris M. Thomasson wrote: >> On 8/26/2016 7:54 PM, Jerry Stuckle wrote: >>> On 8/26/2016 10:32 PM, Malcolm McLean wrote: >>>> On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >>>>> >>>>> Volatile is essentially useless for what it isn't intended to do! It >>>>> does its intended job perfectly well. >>>>> >>>> volatile means that the object is subject to change at any time >>>> by an outside force. But that only makes sense if it is coherent. >>>> >>>> We can obviously change the price of beer. Due to the wicked and >>>> excessive taxes exacted by government, it might have to go up >>>> 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate >>>> second between the barman rubbing out the 2 and writing the 3 >>>> when you can get a beer for 3.0. That's nonsense. Any rule that >>>> allows modification has to allow for temporary suspension during >>>> the period of modification itself. >>>> >>> >>> Sorry, in this case Ian is correct. Any user-mode operation which takes >>> more than one assembler instruction can be interrupted between >>> instructions, leaving the storage partially updated. >>> >>> That's why there are mutex (mutual exclusion) semaphores. But everyone >>> has to agree to use them. >>> >>> And user-mode programs cannot temporarily suspend interrupts. That is a >>> privileged operation. >>> >>> You may not like it - but that's the facts. >>> >> >> Also, one cannot use a mutex in an interrupt handler. Deathlocked! > > Actually, you can but you need to be careful and handle the case of the > mutex already being locked. Usually this means re-enabling interrupts > before attempting to lock the mutex or passing the data on to a separate > thread. However, the latter generally means adding to a linked list, > which also requires a mutex. So the thread handling the request has to > disable interrupts while the mutex is locked. > > All kinds of things can happen when you're dealing with the kernel and > interrupts! The almighty try_lock! If this fails in an interrupt handler, well, the thread goes on its way, perhaps an atomic increment to a failure counter is in order, or something to at least loosely track mutex lock failures in the handlers... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-27 06:34 +0100 |
| Message-ID | <87inum4vxg.fsf@gmail.com> |
| In reply to | #92779 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >> >> Volatile is essentially useless for what it isn't intended to do! It >> does its intended job perfectly well. >> > volatile means that the object is subject to change at any time > by an outside force. But that only makes sense if it is coherent. > > We can obviously change the price of beer. Due to the wicked and > excessive taxes exacted by government, it might have to go up > 10p. So if I understand your analogy, you mean beer price is volatile. > So it goes from 3.20 to 3.30. But there isn't an intermediate second > between the barman rubbing out the 2 and writing the 3 when you can > get a beer for 3.0. So beer pricing is non-atomic (the barman rubs out one digit at a time), but it appears to be atomic because the barman acts as a many-reader-one-writer mutex. The price update is slow, but the barman prevents readers (drinkers) from accessing the new price (buying cheap beer) until the update is complete. > That's nonsense. Maybe, but that's the rules. Consider a large DMA buffer that is used by a camera chip to store image data. Individual byte updates are atomic, but t he entire buffer is volatile (the camera changes the data behind the programs back), but if you take a snapshot of that buffer without some sort of sync mechanism (an end-of-frame interrupt, say) you'll get a inconsistent result (i.e. tearing between a new frame and the previous)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-27 12:48 -0700 |
| Message-ID | <0b43a5ef-657e-41d7-834a-24b058d51f23@googlegroups.com> |
| In reply to | #92775 |
On Friday, August 26, 2016 at 8:12:50 PM UTC-5, Malcolm McLean wrote:
> So volatile is essentially useless without other machinery around it
> in an interrupt-driven environment.
For the scenario of one thread plus interrupts (where any interrupt will run
to conclusion before control returns to the previous context) it is possible
and not even all that difficult to handle multi-word updates safely entirely
within user code. The simplest approach, for a variable whose value is
increased within an ISR but never changed in any other way, is simply:
do
observed_total = total;
while(observed_total != total);
If reads are consistently performed performed upper-word first or lower-
word first, then if the first read gets split, there will be no way for
both values in the second read to match unless the total wraps around.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 16:12 +0200 |
| Message-ID | <nq1fso$2vk$2@dont-email.me> |
| In reply to | #92775 |
On 27/08/16 03:12, Malcolm McLean wrote: > On Friday, August 26, 2016 at 11:25:11 PM UTC+1, Ian Collins wrote: >> On 08/27/16 10:05 AM, supercat@casperkitty.com wrote: >>> On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: >>>> volatile only requires that the compiler reads the variable exactly once >>>> for every read mention and writes exactly once for every assignment in >>>> the code. They also need to be ordered based on the promises of the >>>> abstract machine. It does not guarantee atomic access. For that you need >>>> to use things with atomic guarantees. >>> >>> It is often reasonable for an implementation to limit its guarantees to >>> those the hardware would provide on a "normal" access. That does not >>> imply that programmers should not be entitled to expect that *quality* >>> implementations will provide guarantees at least as strong as those of >>> the underlying hardware unless there is an obviously-compelling reason >>> to do so. >> >> It would still be foolhardy to rely on such an assumption. >> > Word accesses are almost always inherently atomic, that's essentially > what "word" means, in a computer context. You can't raise an interrupt > mid instruction, only between instructions,at least normally. > > However if a variable is multi-word, then it seems you can have > an interrupt between the read of the low word and the read of the high > word, with potentially disastrous consequences, even more serious > because that will likely be rare and, in the case of a counter, the > algorithm will likely be robust to it except in the special case of > low word wrapping and carrying. > So volatile is essentially useless without other machinery around it > in an interrupt-driven environment. > No, "volatile" is merely insufficient by itself when dealing with interrupts (or multiple threads, or other memory masters such as DMA). It is not useless - it is essential. But it is not enough by itself - you will often need other "machinery" to make the code correct.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 16:10 +0200 |
| Message-ID | <nq1fnt$2vk$1@dont-email.me> |
| In reply to | #92765 |
On 27/08/16 00:05, supercat@casperkitty.com wrote: > On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: >> volatile only requires that the compiler reads the variable exactly >> once for every read mention and writes exactly once for every >> assignment in the code. They also need to be ordered based on the >> promises of the abstract machine. It does not guarantee atomic >> access. For that you need to use things with atomic guarantees. > > It is often reasonable for an implementation to limit its guarantees > to those the hardware would provide on a "normal" access. That does > not imply that programmers should not be entitled to expect that > *quality* implementations will provide guarantees at least as strong > as those of the underlying hardware unless there is an > obviously-compelling reason to do so. > You can expect that volatile reads and writes to memory addresses will be generated by the compiler in the order they appear in the source code, as though it were run naïvely on the "abstract machine". That is it - no more, and no less. You cannot expect that the compiler will generate instructions for ordering or flushing any cpu write-back buffers, or handling caches, or synchronising amongst other processors on a multi-core system. You cannot expect that the compiler will do any ordering with respect to non-volatile accesses. And this is a /good/ thing. Any code that involves "volatile" is low-level code, and efficiency is often a major concern (for application-level code you would typically use OS-provided synchronisation primitives, or call drivers or HAL functions for register access). You don't want extra instructions here - especially not synchronisation ones that can be very costly. That is how /quality/ implementations work. They work with the programmer in order to end up with good quality final code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 10:18 -0700 |
| Message-ID | <ef56f594-5d30-41d5-a70c-83a857133169@googlegroups.com> |
| In reply to | #92866 |
On Monday, August 29, 2016 at 9:10:14 AM UTC-5, David Brown wrote: > You cannot expect that the compiler will generate instructions for > ordering or flushing any cpu write-back buffers, or handling caches, or > synchronising amongst other processors on a multi-core system. You > cannot expect that the compiler will do any ordering with respect to > non-volatile accesses. Do you mean "cannot expect that a compiler will refrain from reordering non-volatile accesses across volatile ones? > And this is a /good/ thing. Any code that involves "volatile" is > low-level code, and efficiency is often a major concern (for > application-level code you would typically use OS-provided > synchronisation primitives, or call drivers or HAL functions for > register access). You don't want extra instructions here - especially > not synchronisation ones that can be very costly. Who's asking for synchronization instructions? Since an embedded programmer is likely to know more about the target hardware's memory configuration than the compiler writer, the programmer should be responsible for doing whatever the hardware requires to ensure that the effects of any store instructions *which have already executed* are made visible to whatever needs to see them (e.g. by writing a suitable command-word to the cache controller). If the programmer knows what needs to happen at the hardware level, a quality compiler should stay out of the way. I am well aware that for whatever reason it has become fashionable for compilers to move memory operations, even to things whose semantics are not constrained via "restrict", across volatile-qualified accesses. I also do not doubt that there are some application fields where that is useful. I would suggest, however, that in many other cases the optimizations that enables are minor compared with the optimizations that are impeded by requiring that everything which is ever accessed in "volatile" fashion must always be treated as "volatile", rather than allowing things to be treated with normal memory semantics except when code performs "volatile" accesses. Can you think of any reason the authors of the Standard would have neglected to mandate any sort of compiler-level barrier to memory reordering which would be syntactically equivalent to calling a function whose internals are unknown to the compiler, if they did not intend that "volatile" would act as such sufficient barrier to explicit barrier directives unnecessary? The need for such barriers is just about as common as the need for "volatile", and any compiler should be able to implement them. It seems antithetical to the idea of a "standard" that it should require adding *compiler-specific* extensions to code which had previously been compiler-agnostic.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-29 10:32 -0700 |
| Message-ID | <ba6ae075-5148-4002-938f-97abb2c0e058@googlegroups.com> |
| In reply to | #92883 |
On Monday, August 29, 2016 at 8:19:04 PM UTC+3, supe...@casperkitty.com wrote: > > Can you think of any reason the authors of the Standard would have neglected > to mandate any sort of compiler-level barrier to memory reordering which > would be syntactically equivalent to calling a function whose internals are > unknown to the compiler, if they did not intend that "volatile" would act as > such sufficient barrier to explicit barrier directives unnecessary? The > need for such barriers is just about as common as the need for "volatile", > and any compiler should be able to implement them. It seems antithetical > to the idea of a "standard" that it should require adding *compiler-specific* > extensions to code which had previously been compiler-agnostic. > I fully agree. May be, 1989 the need was not obvious. May be, 1999 committee's internal politics were too messy. But if they still didn't include compiler ordering barrier in ISO/IEC 9899:2011 (which I admit to never read) then it's absolutely unforgivable.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 10:49 -0700 |
| Message-ID | <15845add-f778-4009-8a97-09e052dba109@googlegroups.com> |
| In reply to | #92885 |
On Monday, August 29, 2016 at 12:32:15 PM UTC-5, already...@yahoo.com wrote: > But if they still didn't include compiler ordering barrier in ISO/IEC 9899:2011 (which I admit to never read) then it's absolutely unforgivable. Every C11 implementation is required to either implement <threads.h> or define a macro __STDC_NO_THREADS__ indicating that it does not do so. Implementations which do implement <threads.h> are required to implement the necessary barriers, but are also required to implement things which would not be practical on many freestanding implementations. I am not aware of any standard means by which a program which merely requires a compiler reordering barrier can request one on an implementation that cannot support all of the required threading features, except by forcing the generation of useless code the optimizer can't remove [e.g. calling a do-nothing function via "volatile"-qualified pointer].
[toc] | [prev] | [next] | [standalone]
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web