Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71436 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2015-09-29 09:49 -0700 |
| Last post | 2015-10-04 22:16 -0700 |
| Articles | 20 on this page of 172 — 16 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-09-29 09:49 -0700
Re: C pointer semantics with dynamically allocated struct wssimms@gmail.com - 2015-09-30 21:18 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-01 09:35 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 09:41 -0700
Re: C pointer semantics with dynamically allocated struct gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-01 18:34 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 12:02 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:03 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 06:20 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 16:07 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 08:46 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 17:28 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 10:30 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 20:32 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 12:58 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 22:06 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:31 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 14:31 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:27 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 20:36 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 13:00 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 23:37 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 17:42 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:49 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 23:28 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 00:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:24 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 14:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 14:40 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 18:04 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 20:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 22:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-05 08:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 08:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 12:34 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 17:16 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 21:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 11:05 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 11:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 13:50 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 18:10 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:33 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 09:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 10:43 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 11:50 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 12:19 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 15:32 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 08:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 11:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 12:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 13:30 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 14:15 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 14:53 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 15:23 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 17:24 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 08:02 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 09:02 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 12:43 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 14:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 15:14 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-13 18:37 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-07 20:56 -0500
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 19:41 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 23:15 -0400
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:05 +0000
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 11:23 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:24 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-16 11:12 +0000
Re: C pointer semantics with dynamically allocated struct Gareth Owen <gwowen@gmail.com> - 2015-10-16 21:55 +0100
Re: C pointer semantics with dynamically allocated struct Les Cargill <lcargill99@comcast.com> - 2015-10-16 22:08 -0500
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-14 11:12 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-07 10:34 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 07:23 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 09:53 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:13 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:36 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:35 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 06:23 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 15:34 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 08:07 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 14:42 +0000
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-04 15:37 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 00:33 +0100
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:20 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:55 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:06 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:30 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:39 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-14 23:47 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 10:20 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 11:10 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:11 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 13:52 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 14:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 15:51 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 06:48 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 08:50 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 10:06 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 12:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 13:56 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 14:29 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 14:52 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 15:32 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 15:59 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-17 00:03 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 00:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 15:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:38 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 23:43 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 23:57 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:50 -0700
Re: C pointer semantics with dynamically allocated struct Ian Collins <ian-news@hotmail.com> - 2015-10-18 10:55 +1300
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:24 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 18:39 -0400
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:56 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:17 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-18 11:46 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 19:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:48 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:14 +0100
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 20:22 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 17:26 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:44 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 20:09 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-18 11:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 04:42 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 16:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:20 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 19:53 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 09:41 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 19:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:07 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:55 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-18 04:28 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:49 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:48 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 08:21 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:23 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 09:10 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-02 11:58 -0500
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 11:38 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-05 09:36 -0500
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:47 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 02:51 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-12 23:45 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 13:54 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 01:07 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 15:33 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 19:21 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 12:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 21:24 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 14:32 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 23:43 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 16:49 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 02:01 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 21:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-05 08:19 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 15:16 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 22:52 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:48 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-03 08:22 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 12:05 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:38 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 00:00 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:16 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-07 18:10 -0400 |
| Message-ID | <56159862.10802@verizon.net> |
| In reply to | #72156 |
On 10/07/2015 04:50 PM, Keith Thompson wrote: > supercat@casperkitty.com writes: >> On Wednesday, October 7, 2015 at 1:05:34 PM UTC-5, Keith Thompson wrote: ... >>> The only point I'm making here is about your use of the word >>> "prohibition". >> >> If the Standard says code shall not do X, is there any verb you would >> consider suitable for the sentence "The Standard ___s code from doing X"? >> I would think "prohibit" would seem the most natural, but perhaps something >> else would be better? ... > I suggest that "undefined behavior" is a better term. It's the one the > standard uses, it's accurate, ... I fully agree with everything except: > ... and we all know what it means. Popular misunderstandings: 1. They can't believe that "no requirements" actually means "no requirements" - they believe that there are some specific things that are not allowed by the standard, even when it says "undefined behavior". 2. They somehow manage to read it backwards, as MANDATING some specific type of behavior. I've never seen anyone who believed this who could coherently describe the specific type of behavior they thought was mandated, but immediately aborting the program with a helpful error message seems to be a common expectation. 3. They forget about the "this international standard" part, and assume that if there is anything that defines the behavior, even if that thing isn't the C standard, then that means the behavior isn't undefined. 4. A weird one: the standard prohibits anyone from knowing what the behavior of the code would be. I never got a good answer from this person as to what an implementation was supposed to do if there happened to be someone who did know what the behavior would be. Were they required to execute that person in order to qualify as conforming? In particular, since the behavior of a C program is constrained by the laws of physics (even though the C standard itself fails to mention that fact), does that mean that anyone who's familiar with the constraints imposed by those laws must be executed? Example of #1: >> Nothing prevents implementations from generating the same behavior as would >> result from code which behaved as described in the implementation's >> documentation, but if they don't have the authority to overrule the "shall >> not" rule that would not make the program in question "conforming". > > There is nothing to "overrule". The behavior is undefined, which means > that the rule is infinitely permissive. In the presence of undefined > behavior (behavior that is not defined *by the Standard*), an > implementation is free to do anything it likes. ... > I agree that it's strange. I don't think that "conforming program" is a > particularly useful category. I think there was some politics behind > its inclusion in the standard. As I understand it, the politics wasn't very complicated, nor was it very secret: agreement could not be reached as to what should count as "conforming code". Every proposed definition caused someone's favorite code base to be stigmatized as non-conforming. In the end they chose a compromise that left everyone equally unhappy, by labeling just about anything "conforming".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-07 16:10 -0700 |
| Message-ID | <869ba0c3-93c1-4ec0-9454-a83d7aa0b81c@googlegroups.com> |
| In reply to | #72158 |
On Wednesday, October 7, 2015 at 5:11:01 PM UTC-5, James Kuyper wrote:
> On 10/07/2015 04:50 PM, Keith Thompson wrote:
> > I suggest that "undefined behavior" is a better term. It's the one the
> > standard uses, it's accurate, ...
>
> I fully agree with everything except:
>
> > ... and we all know what it means.
> Popular misunderstandings:
> 3. They forget about the "this international standard" part, and assume
> that if there is anything that defines the behavior, even if that thing
> isn't the C standard, then that means the behavior isn't undefined.
If an implementation defines a behavioral consequences of some action, but
something else in the Standard says such action has Undefined Behavior,
is that behavior defined or undefined?
For example, would a compiler that does not bundle its own standard library
functions be entitled to assume that:
void hey(int x)
{
unsigned char *p = malloc(10);
p[x]++;
return x;
}
will never be invoked with a value of x outside the range 0 to 9 even if
code happens to be linked with a library that specifies the layout of
memory around a malloc'ed block and such specification makes clear what
the consequence of modifying a particular location would be?
> 4. A weird one: the standard prohibits anyone from knowing what the
> behavior of the code would be. I never got a good answer from this
> person as to what an implementation was supposed to do if there happened
> to be someone who did know what the behavior would be.
In general, if a standard requires an implementation to document something,
an implementation whose documentation doesn't match what the thing actually
does would be non-compliant.
It would, however, be possible for a Standard to expressly disclaim any
normal requirements for accuracy with regard to certain aspects of an
implementation's documentation. For example, if the C Standard were to
specify that conforming implementations are allowed to document anything
they want--true or false--about the contents of argv[argc+2], that would
mean that no programmer would be entitled to expect any particular
behavior from argv[argc+2] even when using implementations whose
documentation happened to describe the behavior accurately.
> In
> particular, since the behavior of a C program is constrained by the laws
> of physics...
Well, sort of...
Some people seem to think that a good C compiler should aggressively make
use of the fact that certain code paths will invoke Undefined Behavior to
decide that the program will never receive input that would cause code
to go down those paths, even if there exist data dependencies which would
make it impossible for code to ever reach any particular point that would
invoke Undefined Behavior. For example, given:
int main(void)
{
int c;
printf"Hey there!");
c=getchar();
if (c == '1')
printf("%d", 1/(ch-'1'));
else
printf("%d", 1<<(ch+33));
}
If "getchar" returns '1', the program will cause a division by zero. If
it returns any other value, the program will cause an oversized shift.
There is no value that "getchar()" could return which will not invoke
Undefined Behavior. While I would argue that the behavior of the program
should be regarded as completely defined in the event that the user never
actually types a character, some people would suggest that because there
is no defined execution path for the program as a whole the effects of
the Undefined Behavior should be able to time-travel across the "getchar"
since the Standard says that if a program invokes Undefined Behavior, the
entire execution is undefined.
> As I understand it, the politics wasn't very complicated, nor was it
> very secret: agreement could not be reached as to what should count as
> "conforming code". Every proposed definition caused someone's favorite
> code base to be stigmatized as non-conforming. In the end they chose a
> compromise that left everyone equally unhappy, by labeling just about
> anything "conforming".
That's believable, but still not very helpful. What's needed is to
have standards of conformity such that if a program documents in standard
fashion that it requires language extensions X, Y, and Z, and if it is
written so that it will work on all compilers which (as configured) support
those extensions, then the program would be deemed as being a strictly-
conforming program of "C with extensions X, Y, and Z". It should not
be necessary for the Standard to impose value judgments upon which features
implementations should support; compiler writers could figure that out by
seeing what their customers ask for.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 16:33 -0700 |
| Message-ID | <lnsi5mi79l.fsf@kst-u.example.com> |
| In reply to | #72161 |
supercat@casperkitty.com writes:
> On Wednesday, October 7, 2015 at 5:11:01 PM UTC-5, James Kuyper wrote:
>> On 10/07/2015 04:50 PM, Keith Thompson wrote:
>> > I suggest that "undefined behavior" is a better term. It's the one the
>> > standard uses, it's accurate, ...
>>
>> I fully agree with everything except:
>>
>> > ... and we all know what it means.
>
>> Popular misunderstandings:
>> 3. They forget about the "this international standard" part, and assume
>> that if there is anything that defines the behavior, even if that thing
>> isn't the C standard, then that means the behavior isn't undefined.
>
> If an implementation defines a behavioral consequences of some action, but
> something else in the Standard says such action has Undefined Behavior,
> is that behavior defined or undefined?
If there were such a case, it would be a defect in the standard. I'm
not aware of any such defect.
> For example, would a compiler that does not bundle its own standard library
> functions be entitled to assume that:
>
> void hey(int x)
> {
> unsigned char *p = malloc(10);
> p[x]++;
> return x;
> }
>
> will never be invoked with a value of x outside the range 0 to 9 even if
> code happens to be linked with a library that specifies the layout of
> memory around a malloc'ed block and such specification makes clear what
> the consequence of modifying a particular location would be?
Yes. malloc() is a standard library function, and its behavior is
defined by the standard. The behavior of attempting to modify p[10] is
not defined by the standard (though of course an implementation is free
to document the behavior if it likes).
>> 4. A weird one: the standard prohibits anyone from knowing what the
>> behavior of the code would be. I never got a good answer from this
>> person as to what an implementation was supposed to do if there happened
>> to be someone who did know what the behavior would be.
>
> In general, if a standard requires an implementation to document something,
> an implementation whose documentation doesn't match what the thing actually
> does would be non-compliant.
James was talking about misunderstandings of the meaning of the phrase
"undefined behavior". If the standard requires an implementation to
document something, then it's not undefined behavior; it's
implementation-defined behavior
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-08 09:08 -0700 |
| Message-ID | <04a9dae0-29bb-4e83-9608-5a2b2e36b004@googlegroups.com> |
| In reply to | #72164 |
On Wednesday, October 7, 2015 at 6:33:18 PM UTC-5, Keith Thompson wrote: > Yes. malloc() is a standard library function, and its behavior is > defined by the standard. The behavior of attempting to modify p[10] is > not defined by the standard (though of course an implementation is free > to document the behavior if it likes). If the library documents the behavior of "malloc", "free", etc. in greater detail than required by the Standard, and such documentation implies that modifying certain bytes immediately outside the allocation will have particular effects, would there be any standard means to ensure that a compiler would honor the semantics of the library?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 10:43 -0700 |
| Message-ID | <lnfv1li7ch.fsf@kst-u.example.com> |
| In reply to | #72200 |
supercat@casperkitty.com writes:
> On Wednesday, October 7, 2015 at 6:33:18 PM UTC-5, Keith Thompson wrote:
>> Yes. malloc() is a standard library function, and its behavior is
>> defined by the standard. The behavior of attempting to modify p[10] is
>> not defined by the standard (though of course an implementation is free
>> to document the behavior if it likes).
>
> If the library documents the behavior of "malloc", "free", etc. in greater
> detail than required by the Standard, and such documentation implies that
> modifying certain bytes immediately outside the allocation will have
> particular effects, would there be any standard means to ensure that a
> compiler would honor the semantics of the library?
No, why would there be? A conforming implementation is free to document
whatever it likes, and to behave in any way it likes within the rules
set by the standard. Enforcement of an implementation's non-standard
documentation is outside the scope of the standard.
I suppose a future C standard could add a rule requiring implementations
to conform to their own documentation, but I see no point in doing so.
If an implementation violates its own documentation, it's a bug, and you
can complain to the vendor.
--
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 | 2015-10-08 11:50 -0700 |
| Message-ID | <d59fc209-f61f-413b-bde5-9aa1de7c297a@googlegroups.com> |
| In reply to | #72205 |
On Thursday, October 8, 2015 at 12:44:02 PM UTC-5, Keith Thompson wrote: > No, why would there be? A conforming implementation is free to document > whatever it likes, and to behave in any way it likes within the rules > set by the standard. Enforcement of an implementation's non-standard > documentation is outside the scope of the standard. Is there any purpose served by a rule that requires compilers to document certain behaviors if it doesn't require that they be documented correctly? If one tries to say that the Standard only requires that a compiler correctly document Implementation-Defined behaviors, but nothing else in the documentation is required to be correct, how does one resolve cases where it would be impossible to really understand the full effects of Implementation-Defined behaviors without (correctly) understanding other platform-specific behaviors? It seems much easier to say that a platform's documentation must be correct in order for the platform to be deemed as standards-conforming, than to distinguish which parts are required to be correct and which parts are not. Besides, in what case would it be desirable to have a compiler declared to be "standards-conforming" when its documentation didn't match its behavior?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 12:19 -0700 |
| Message-ID | <ln7fmxi2wl.fsf@kst-u.example.com> |
| In reply to | #72210 |
supercat@casperkitty.com writes:
> On Thursday, October 8, 2015 at 12:44:02 PM UTC-5, Keith Thompson wrote:
>> No, why would there be? A conforming implementation is free to document
>> whatever it likes, and to behave in any way it likes within the rules
>> set by the standard. Enforcement of an implementation's non-standard
>> documentation is outside the scope of the standard.
>
> Is there any purpose served by a rule that requires compilers to document
> certain behaviors if it doesn't require that they be documented correctly?
I've already said that the requirement that certain behaviors must
be documented implies that that documentation must be accurate.
The standard does not require documentation for other behaviors to
exist at all.
> If one tries to say that the Standard only requires that a compiler
> correctly document Implementation-Defined behaviors,
Implementation-defined and locale-specific characteristics and
extensions.
> but nothing else in
> the documentation is required to be correct, how does one resolve cases
> where it would be impossible to really understand the full effects of
> Implementation-Defined behaviors without (correctly) understanding other
> platform-specific behaviors?
I suppose that any documentation required to understand
implementation-defined behavior is part of the documentation for that
behavior, and therefore must be accurate.
> It seems much easier to say that a platform's
> documentation must be correct in order for the platform to be deemed as
> standards-conforming, than to distinguish which parts are required to be
> correct and which parts are not.
Why do you insist that any problem with an implementation must
be a violation of the standard? If a compiler is buggy and/or
incorrectly documented, complain to the vendor. That complaint
doesn't have to refer to the ISO C standard.
> Besides, in what case would it be desirable to have a compiler declared to
> be "standards-conforming" when its documentation didn't match its behavior?
Whether it's desirable or not, it's an accurate statement.
An otherwise conforming implementation whose documentation states
that it will shine your shoes during translation phase 2, but does
not actually do so, does not violate the standard.
If you want to advocate adding a clause to the standard that says
an implementation's documentation must be entirely accurate, even
for things that are outside the scope of the standard, that's fine.
I think it would be a silly requirement, I don't know what problem
it would solve, and it does not exist in the current 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-07 15:32 -0700 |
| Message-ID | <d4a54a0b-a2a9-4165-9c53-9d32e9198e58@googlegroups.com> |
| In reply to | #72156 |
On Wednesday, October 7, 2015 at 3:50:14 PM UTC-5, Keith Thompson wrote:
> If the Standard says code *shall* not do X, and the word "shall" is not
> in a constraint, then (again, ignoring 4p1) it does not "prohibit" doing
> X. That's because the Standard is using the word "shall" in a specific
> technical sense that doesn't necessarily match common English usage.
I'd say it's actually misusing the word "shall" in a sense which doesn't
really match any other usage anywhere that I can think of, since generally
when a standard mandates that an X shall do Y, that implies that from the
point of view of the standard, the fact that something fails to do Y is
sufficient in and of itself to imply that--from the point of view of the
standard--the thing in question is, *by definition*, not a legitimate X.
Can you think of any other standards which use the word "shall" in the
same way as the C Standard applies it to run-time behavior?
> If you want to argue that you're using the word "prohibition" in the
> sense that the standard uses it in 4p1, then you have a point -- but I
> don't *think* that's what you're doing (please correct me if I'm
> mistaken on that point).
Suppose an implementation specifies that a pointer of any type identifies
a machine address, that a write to a uint32_t* identifying the first byte
of a word will cause the indicated value to be stored in that byte and
the next three in LSB-first format, and that a read of a uint16_t* which
identifies the first or third byte of a word will cause the values held
in that byte and the next one to be interpreted as a 16-bit unsigned
integer in LSB-first format.
Suppose further that the implementation makes no reference whatsoever to
N1570 6.5p7.
Would someone writing code for such an implementation be entitled to expect
that casting the address of a "uint32_t" to "uint16_t*" and reading it
would yield the low-order 16 bits of the 32-bit value? A lot of people
seem to think that the answer would be "no", because of N1570 6.5p7.
Perhaps rather than getting caught up on the word "prohibition", perhaps
it would be better to focus on a point that should be non-controversial:
It should not be possible for a non-defective standard to be reasonably
interpreted as saying that a a programmer is entitled to expect that a
certain construct will yield a certain behavior on a particular platform
whose documentation conforms with the requirements imposed by the Standard,
but also be possible for it to be reasonably interpreted as saying that
a compiler for that same platform with that same documentation would be
entitled to expect that a program will never receive input that would
cause such a construct to be executed.
A good standard should minimize the number of cases where there might be
disagreements, but I would posit that for a standard to be considered as
non-defective, it must ensure that in every place that was ambiguous,
either programmers were clearly not entitled to expectations (and the only
ambiguity would be whether compilers were entitled to take advantage of
this) or else compilers were clearly not entitled to expectations (and
the only ambiguity was whether programmers were entitled to take advantage
of that)
To my mind, the fact that the parts of the C standard admit to common
contradictory readings would imply that those parts are defective. Alas,
I have a sneaking suspicion that there are two competing factions who both
believe that N1570 6.5p7 supports their view and will never agree to any
alternate wording which would contradict that view.
IMHO, the proper solution is to define a standard macro which will indicate
whether or not the behavioral guarantees of a particular compiler render
that section moot. It wouldn't matter which faction was "right", since
code which tests the macro and observes that the compiler has rendered
that section moot would clearly be entitled to make use of the behaviors
guaranteed thereby, and a compiler which defines the macro in such fashion
as to indicate that it regards that section as applicable would be entitled
to do anything it likes with code that violates it.
> A compiler is prohibited from successfully translating a source file
> containing a #error directive that survives preprocessing...
...
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any strictly conforming program.
Is there any language which would resolve the contradiction imposed by a
compiler which documented an extension which would cause the following
line, within method scope
#error JUST KIDDING
to insert a call to a library function which prints a joke on the console,
given that such an extension would not alter the behavior of any conforming
program?
> I agree that it's strange. I don't think that "conforming program" is a
> particularly useful category. I think there was some politics behind
> its inclusion in the standard.
What do you think of the idea of defining a category of programs which
indicate in some standardized means what optional features and guarantees
they require, and which will work on any compiler which meets those
requirements?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 16:21 -0700 |
| Message-ID | <ln1td6jmdc.fsf@kst-u.example.com> |
| In reply to | #72159 |
supercat@casperkitty.com writes:
> On Wednesday, October 7, 2015 at 3:50:14 PM UTC-5, Keith Thompson wrote:
>> If the Standard says code *shall* not do X, and the word "shall" is not
>> in a constraint, then (again, ignoring 4p1) it does not "prohibit" doing
>> X. That's because the Standard is using the word "shall" in a specific
>> technical sense that doesn't necessarily match common English usage.
>
> I'd say it's actually misusing the word "shall" in a sense which doesn't
> really match any other usage anywhere that I can think of, since generally
> when a standard mandates that an X shall do Y, that implies that from the
> point of view of the standard, the fact that something fails to do Y is
> sufficient in and of itself to imply that--from the point of view of the
> standard--the thing in question is, *by definition*, not a legitimate X.
>
> Can you think of any other standards which use the word "shall" in the
> same way as the C Standard applies it to run-time behavior?
No, though other standards do use the word "shall" in somewhat
idiosyncratic ways. But the C standard does use it that way, and has
consistently done so for 26 years. Once you know how the standard uses
the word "shall", the meaning is in my opinion crystal clear.
The standard does not say that pointer-based type-punning is prohibited.
It says that its behavior is undefined. Do you not get that?
>> If you want to argue that you're using the word "prohibition" in the
>> sense that the standard uses it in 4p1, then you have a point -- but I
>> don't *think* that's what you're doing (please correct me if I'm
>> mistaken on that point).
>
> Suppose an implementation specifies that a pointer of any type identifies
> a machine address, that a write to a uint32_t* identifying the first byte
> of a word will cause the indicated value to be stored in that byte and
> the next three in LSB-first format, and that a read of a uint16_t* which
> identifies the first or third byte of a word will cause the values held
> in that byte and the next one to be interpreted as a 16-bit unsigned
> integer in LSB-first format.
>
> Suppose further that the implementation makes no reference whatsoever to
> N1570 6.5p7.
I presume you mean that it doesn't *explicitly* refer to 6.5p7. (Any
implementation that claims to conform to the standard implicitly refers
to all of it.)
> Would someone writing code for such an implementation be entitled to expect
> that casting the address of a "uint32_t" to "uint16_t*" and reading it
> would yield the low-order 16 bits of the 32-bit value? A lot of people
> seem to think that the answer would be "no", because of N1570 6.5p7.
"A lot of people"? Name one.
Certainly if an implementation documents the behavior of such code,
you're entitled to expect the implementation to behave as its
documentation says it does. The standard doesn't define the behavior;
that in no way implies that an implementation can't define the behavior.
Of course if the implementation fails to obey its own documentation,
that's not a violation of the C standard -- but presumably you'd still
be entitled to submit a bug report and/or get your money (if any) back.
> Perhaps rather than getting caught up on the word "prohibition", perhaps
> it would be better to focus on a point that should be non-controversial:
>
> It should not be possible for a non-defective standard to be reasonably
> interpreted as saying that a a programmer is entitled to expect that a
> certain construct will yield a certain behavior on a particular platform
> whose documentation conforms with the requirements imposed by the Standard,
> but also be possible for it to be reasonably interpreted as saying that
> a compiler for that same platform with that same documentation would be
> entitled to expect that a program will never receive input that would
> cause such a construct to be executed.
>
> A good standard should minimize the number of cases where there might be
> disagreements, but I would posit that for a standard to be considered as
> non-defective, it must ensure that in every place that was ambiguous,
> either programmers were clearly not entitled to expectations (and the only
> ambiguity would be whether compilers were entitled to take advantage of
> this) or else compilers were clearly not entitled to expectations (and
> the only ambiguity was whether programmers were entitled to take advantage
> of that)
>
> To my mind, the fact that the parts of the C standard admit to common
> contradictory readings would imply that those parts are defective. Alas,
> I have a sneaking suspicion that there are two competing factions who both
> believe that N1570 6.5p7 supports their view and will never agree to any
> alternate wording which would contradict that view.
N1570 6.5p7 says that if a program accesses an object's stored value by
an lvalue that doesn't have one of the listed types, then that program's
behavior *is not defined by the standard*. That's all it says.
The only way I can think of that someone could reach a different
conclusion is if they didn't know how the standard uses the word
"shall".
> IMHO, the proper solution is
[snip]
I don't see how we can discuss a solution without defining what the
problem is, and I don't believe we can do that without understanding
what the standard actually says. Your insistence on using the word
"prohibition" (assuming you're not basing your using on 4p1) indicates
to me either than you don't understand what the Standard actually says,
or that I don't understand what you're saying.
As I've said before, I think you have some interesting ideas. But if we
can't agree on what the standard actually says, it's going to be
impossible to discuss them meaningfully.
[...]
--
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 | 2015-10-08 08:54 -0700 |
| Message-ID | <212091ef-f3a2-4aa2-816c-6eb76428ca8e@googlegroups.com> |
| In reply to | #72162 |
On Wednesday, October 7, 2015 at 6:21:49 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> No, though other standards do use the word "shall" in somewhat
> idiosyncratic ways. But the C standard does use it that way, and has
> consistently done so for 26 years. Once you know how the standard uses
> the word "shall", the meaning is in my opinion crystal clear.
Since the rules in 6.5p7 make it essentially impossible to write certain
kinds of code efficiently, but they could easily be changed to alleviate
that problem without affecting their usefulness for their intended purpose
(e.g. define a directive __syncmem(ptr,size) which would cause the most
recent writes to all items within that block of memory to be regarded as
though they were performed using a sequence of "unsigned char" values,
thus allowing type punning on subsequent reads) I would suggest that the
reason that section hasn't been changed since C89 is that until recently
just JUST ABOUT EVERYBODY HAS BEEN IGNORING IT, since there are very
few platforms where it serves any useful purpose, and it would have been
pointless to waste time trying to clarify rules that nobody cared about.
> > Suppose an implementation specifies that a pointer of any type identifies
> > a machine address...
> >
> > Suppose further that the implementation makes no reference whatsoever to
> > N1570 6.5p7.
>
> I presume you mean that it doesn't *explicitly* refer to 6.5p7. (Any
> implementation that claims to conform to the standard implicitly refers
> to all of it.)
Naturally.
> Certainly if an implementation documents the behavior of such code,
> you're entitled to expect the implementation to behave as its
> documentation says it does. The standard doesn't define the behavior;
> that in no way implies that an implementation can't define the behavior.
>
> Of course if the implementation fails to obey its own documentation,
> that's not a violation of the C standard -- but presumably you'd still
> be entitled to submit a bug report and/or get your money (if any) back.
Given the code:
volatile uint32_t *p = 0x12340000;
*p = 0xCAFEBABE;
would an implementation whose documentation specified that the above code
would use a word-write instruction to store 0xCAFEBABE to address 0x12340000
but which instead output "BARNEY RULES!" to the console without having
performed the indicated word-write instruction be considered "Standard
Conforming"? Nothing in the Standard would prohibit a platform from
specifying that code which writes 0xCAFEBABE to address 0x12340000 will
cause "BARNEY RULES!" to be sent to the console, and nothing in the Standard
would generally concern itself with implementation details, but I would posit
that if an implementation claims to provide behavioral guarantees but does
not honor them, such an implementation should be deemed non-conforming
whether or not it the Standard would have required it to make the guarantees
in question.
For that matter, suppose a compiler is documented as using a 1MB call stack
but programs which use subroutines nested more than four deep sometimes
behave randomly for no apparent reason. Would such random behavior in any
way render the compiler non-complaint given that (1) overly deep subroutine
nesting invokes Undefined Behavior; (2) the Standard does not require that
implementations provide any way of guaranteeing that a certain level of
nesting will work beyond a rather paltry minimum?
> N1570 6.5p7 says that if a program accesses an object's stored value by
> an lvalue that doesn't have one of the listed types, then that program's
> behavior *is not defined by the standard*. That's all it says.
The Standard requires compilers to provide documentation; in many cases,
what is meaningful is not the behaviors guaranteed by the standard, but
the behaviors guaranteed by the combination of the standard and the
compiler's documentation. If one part of that combination says how a
certain behavior will work, and another says that some specific forms
of that behavior will invoked Undefined Behavior, it's not inherently
obvious which should take precedence.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 11:15 -0700 |
| Message-ID | <lnbnc9i5vx.fsf@kst-u.example.com> |
| In reply to | #72199 |
supercat@casperkitty.com writes:
> On Wednesday, October 7, 2015 at 6:21:49 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> No, though other standards do use the word "shall" in somewhat
>> idiosyncratic ways. But the C standard does use it that way, and has
>> consistently done so for 26 years. Once you know how the standard uses
>> the word "shall", the meaning is in my opinion crystal clear.
>
> Since the rules in 6.5p7 make it essentially impossible to write certain
> kinds of code efficiently, but they could easily be changed to alleviate
> that problem without affecting their usefulness for their intended purpose
> (e.g. define a directive __syncmem(ptr,size) which would cause the most
> recent writes to all items within that block of memory to be regarded as
> though they were performed using a sequence of "unsigned char" values,
> thus allowing type punning on subsequent reads) I would suggest that the
> reason that section hasn't been changed since C89 is that until recently
> just JUST ABOUT EVERYBODY HAS BEEN IGNORING IT, since there are very
> few platforms where it serves any useful purpose, and it would have been
> pointless to waste time trying to clarify rules that nobody cared about.
Nevertheless, the standard says what it says. If you want to change it,
you should first acknowledge what it says now. I'm willing to discuss
possible changes to the standard, but not without agreeing on where
we're starting from.
6.5p7 doesn't make *anything* impossible. It refrains from requiring
implementations to make certain things possible.
Note that a conforming implementation has always free to ignore 6.5p7,
since it can do anything it likes in the presence of undefined behavior.
Let's start with an example:
#include <stdio.h>
#include <assert.h>
int main(void) {
assert(sizeof (float) == sizeof (unsigned) &&
_Alignof (float) == _Alignof (unsigned));
float f = 1.0;
printf("0x%x\n", *(unsigned*)&f);
}
Assume that the assert doesn't fire.
Do you agree that the second argument in the printf call violates
the "shall" requirement in N1570 6.5p7?
Do you agree that this means that the evaluation of that argument
has undefined behavior?
Do you agree that "undefined behavior" means only that the C standard
does not define the behavior?
Do you agree that an implementation is free to define the behavior
if it chooses to do so?
If not, can you explain your disagreement? Please note that I'm not
asking whether you approve of the rules given in the standard, just
whether you agree on what they are.
>> > Suppose an implementation specifies that a pointer of any type identifies
>> > a machine address...
>> >
>> > Suppose further that the implementation makes no reference whatsoever to
>> > N1570 6.5p7.
>>
>> I presume you mean that it doesn't *explicitly* refer to 6.5p7. (Any
>> implementation that claims to conform to the standard implicitly refers
>> to all of it.)
>
> Naturally.
>
>> Certainly if an implementation documents the behavior of such code,
>> you're entitled to expect the implementation to behave as its
>> documentation says it does. The standard doesn't define the behavior;
>> that in no way implies that an implementation can't define the behavior.
>>
>> Of course if the implementation fails to obey its own documentation,
>> that's not a violation of the C standard -- but presumably you'd still
>> be entitled to submit a bug report and/or get your money (if any) back.
>
> Given the code:
>
> volatile uint32_t *p = 0x12340000;
> *p = 0xCAFEBABE;
>
> would an implementation whose documentation specified that the above code
> would use a word-write instruction to store 0xCAFEBABE to address 0x12340000
> but which instead output "BARNEY RULES!" to the console without having
> performed the indicated word-write instruction be considered "Standard
> Conforming"? Nothing in the Standard would prohibit a platform from
> specifying that code which writes 0xCAFEBABE to address 0x12340000 will
> cause "BARNEY RULES!" to be sent to the console, and nothing in the Standard
> would generally concern itself with implementation details, but I would posit
> that if an implementation claims to provide behavioral guarantees but does
> not honor them, such an implementation should be deemed non-conforming
> whether or not it the Standard would have required it to make the guarantees
> in question.
First off, that code violates a constraint, since there is no implicit
conversion from 0x12340000 to uint32_t*. A compiler may provide such a
conversion as an extension, but I'll assume that the first line is
replaced by:
volatile uint32_t *p = (uint32_t*)0x12340000;
The result of the conversion of 0x12340000 to uint32_t* is
implementation-defined. Either this line or the next one *may or may
not* have undefined behavior. I suggest that this is not the best
possible example.
If the implementation's documentation says that it uses a word-write
instruction, and the implementation does not in fact do so, then it's
violating its own documentation. I would consider that a bug, but not a
violation of the standard, since the standard (a) says nothing about
word-write instructions, and (b) says nothing about implementation
documentation beyond the items that it requires to be documented.
Similarly, if a C compiler runs a background task that embezzles money
from your bank account, that would probably be a violation of criminal
law, but not of the C standard.
Not all compiler bugs are violations of the C standard.
> For that matter, suppose a compiler is documented as using a 1MB call stack
> but programs which use subroutines nested more than four deep sometimes
> behave randomly for no apparent reason. Would such random behavior in any
> way render the compiler non-complaint given that (1) overly deep subroutine
> nesting invokes Undefined Behavior; (2) the Standard does not require that
> implementations provide any way of guaranteeing that a certain level of
> nesting will work beyond a rather paltry minimum?
>
>> N1570 6.5p7 says that if a program accesses an object's stored value by
>> an lvalue that doesn't have one of the listed types, then that program's
>> behavior *is not defined by the standard*. That's all it says.
>
> The Standard requires compilers to provide documentation; in many cases,
> what is meaningful is not the behaviors guaranteed by the standard, but
> the behaviors guaranteed by the combination of the standard and the
> compiler's documentation. If one part of that combination says how a
> certain behavior will work, and another says that some specific forms
> of that behavior will invoked Undefined Behavior, it's not inherently
> obvious which should take precedence.
N1570 4p8:
An implementation shall be accompanied by a document that defines
all implementation-defined and locale-specific characteristics and
all extensions.
I think we can agree that that implicitly requires such documentation to
be accurate. Any documentation beyond that is 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-08 12:38 -0700 |
| Message-ID | <e9de65c7-7dfa-4cb1-82c9-151e31c09756@googlegroups.com> |
| In reply to | #72208 |
On Thursday, October 8, 2015 at 1:15:26 PM UTC-5, Keith Thompson wrote: > supercat writes: > > ... I would suggest that the > > reason that section hasn't been changed since C89 is that until recently > > just JUST ABOUT EVERYBODY HAS BEEN IGNORING IT, since there are very > > few platforms where it serves any useful purpose, and it would have been > > pointless to waste time trying to clarify rules that nobody cared about. > > Nevertheless, the standard says what it says. If you want to change it, > you should first acknowledge what it says now. I'm willing to discuss > possible changes to the standard, but not without agreeing on where > we're starting from. The biggest difficulty I think is that there is a major disconnect between C as defined by the standards, and the language that programmers actually use; unfortunately, some compiler vendors seem to be trying to replace the useful language which won out in the compiler marketplace with the version that the marketplace rejected. What's needed is to unify the two languages in such a way that programmers who rely upon the features which the marketplace has shown to be useful can continue to use them, but machines that can't support those features would be able to use C for applications that don't require them. > Do you agree that the second argument in the printf call violates > the "shall" requirement in N1570 6.5p7? > > Do you agree that this means that the evaluation of that argument > has undefined behavior? An implementation whose documentation does not provide enough behavioral guarantees to indicate how that program should behave could do anything it likes with it and not be considered in violation of the Standard. We differ on whether an implementation which did provide enough behavioral documentation could behave in a manner contrary to that while still being in conformance of the Standard. > If not, can you explain your disagreement? Please note that I'm not > asking whether you approve of the rules given in the standard, just > whether you agree on what they are. If an implementation is not bound by the behavioral guarantees made in its documentation, then most C compilers actually implement two languages: 1. Some version of Standard C, which is used when programs contain no #pragma directives, nor any identifiers that start with two underscores and are not defined by the C Standard, and when they do not perform any action which would invoke Undefined Behavior. 2. A language totally unrelated to Standard C, which is used for all other programs. I think it would be more useful to say that if an implementation specifies that a #pragma has some particular effect but that the file will otherwise be processed in standard fashion, that the C Standard would continue to be applicable to the rest of the file except for the effects of the #pragma. That only works, though, if the Standard regards the documentation on the effects of the pragma as binding. > First off, that code violates a constraint, since there is no implicit > conversion from 0x12340000 to uint32_t*. A compiler may provide such a > conversion as an extension, but I'll assume that the first line is > replaced by: > > volatile uint32_t *p = (uint32_t*)0x12340000; Thanks. > The result of the conversion of 0x12340000 to uint32_t* is > implementation-defined. Either this line or the next one *may or may > not* have undefined behavior. I suggest that this is not the best > possible example. I specifically stated that the platform's documentation states that the effect of the code [as corrected] will be to perform a machine write of the indicated value to the indicated address. If the behavior would be deemed undefined even in the presence of such documentation, why does the Standard not simply say that all conversions from integer types to pointers yield Undefined Behavior? > If the implementation's documentation says that it uses a word-write > instruction, and the implementation does not in fact do so, then it's > violating its own documentation. I would consider that a bug, but not a > violation of the standard, since the standard (a) says nothing about > word-write instructions, and (b) says nothing about implementation > documentation beyond the items that it requires to be documented. The behavior of volatile reads and writes is Implementation-Defined, as is the effect of casting integers to pointers. That means a compiler is required to document how those operations are performed. Can you identify any useful purpose that would be served by requiring that compilers have something in their documentation claiming to specify what those operations do, without requiring them to say what they actually do? > N1570 4p8: > > An implementation shall be accompanied by a document that defines > all implementation-defined and locale-specific characteristics and > all extensions. > > I think we can agree that that implicitly requires such documentation to > be accurate. Any documentation beyond that is outside the scope of the > standard. There often won't be a clear hard line between that information and more general information about an implementation. For example, the Standard does not concern itself with the details of what form stdin and stdout will take. What sorts of mistakes could an implemetation include in its definition of those things while remaining standards-compliant? >Whether it's desirable or not, it's an accurate statement. >An otherwise conforming implementation whose documentation states >that it will shine your shoes during translation phase 2, but does >not actually do so, does not violate the standard. Why should the Shoe-Shining Extension be exempt from the requirement that all extensions be documented accurately?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 13:30 -0700 |
| Message-ID | <lnziztgl2j.fsf@kst-u.example.com> |
| In reply to | #72212 |
supercat@casperkitty.com writes:
> On Thursday, October 8, 2015 at 1:15:26 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > ... I would suggest that the
>> > reason that section hasn't been changed since C89 is that until recently
>> > just JUST ABOUT EVERYBODY HAS BEEN IGNORING IT, since there are very
>> > few platforms where it serves any useful purpose, and it would have been
>> > pointless to waste time trying to clarify rules that nobody cared about.
>>
>> Nevertheless, the standard says what it says. If you want to change it,
>> you should first acknowledge what it says now. I'm willing to discuss
>> possible changes to the standard, but not without agreeing on where
>> we're starting from.
>
> The biggest difficulty I think is that there is a major disconnect between
> C as defined by the standards, and the language that programmers actually
> use; unfortunately, some compiler vendors seem to be trying to replace the
> useful language which won out in the compiler marketplace with the version
> that the marketplace rejected.
I'm asking that we first reach an understanding of what the Standard
says. Until we've done that, I'm unwilling to discuss changes.
[...]
>> Do you agree that the second argument in the printf call violates
>> the "shall" requirement in N1570 6.5p7?
>>
>> Do you agree that this means that the evaluation of that argument
>> has undefined behavior?
I request that you provide direct yes or no answers to my questions,
including the two that you snipped. By all means feel free to elaborate
on those answers. These are not meant to be trick questions; each
should be easy to answer with a yes or a no.
[SNIP]
--
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 | 2015-10-08 14:15 -0700 |
| Message-ID | <13aee181-00df-4fb3-bff6-9ee5c7481a7a@googlegroups.com> |
| In reply to | #72215 |
On Thursday, October 8, 2015 at 3:30:22 PM UTC-5, Keith Thompson wrote: > >> Do you agree that the second argument in the printf call violates > >> the "shall" requirement in N1570 6.5p7? > >> > >> Do you agree that this means that the evaluation of that argument > >> has undefined behavior? > > I request that you provide direct yes or no answers to my questions, > including the two that you snipped. By all means feel free to elaborate > on those answers. These are not meant to be trick questions; each > should be easy to answer with a yes or a no. I would say that there are implementations where it would invoke Undefined Behavior, and implementations where it would not. If an implementation were to document that, as an extension, it explicitly guarantees that even in cases beyond those specifically allowed by the Standard it will interpret code which writes memory as one type and reads it as another, but were to nonetheless process the code above in any way other than implied by that documentation, such an implementation would seem to run afoul of the requirement that implementations document extensions to the language. Unless one were to say that the documentation requirement only applies to extensions the implementation actually provides, and that implementations are allowed to make any claims they like with regard to extensions they don't actually provide, an implementation which includes the aforementioned language in the documentation would seem to have only one allowable behavior which would conform to the Standard. Can you see any wiggle room by which an implementation with documentation as described could do anything else and still be standard-conformant?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 14:53 -0700 |
| Message-ID | <lnmvvtgh80.fsf@kst-u.example.com> |
| In reply to | #72216 |
supercat@casperkitty.com writes:
> On Thursday, October 8, 2015 at 3:30:22 PM UTC-5, Keith Thompson wrote:
>> >> Do you agree that the second argument in the printf call violates
>> >> the "shall" requirement in N1570 6.5p7?
>> >>
>> >> Do you agree that this means that the evaluation of that argument
>> >> has undefined behavior?
>>
>> I request that you provide direct yes or no answers to my questions,
>> including the two that you snipped. By all means feel free to elaborate
>> on those answers. These are not meant to be trick questions; each
>> should be easy to answer with a yes or a no.
>
> I would say that there are implementations where it would invoke Undefined
> Behavior, and implementations where it would not.
[...]
You raise a valid point: it's not entirely clear what constitutes an
"extension".
For purposes of the four questions I asked previously (I can repost
them if you like), assume that the implementation does not document
any relevant extensions. It may document whatever it likes about
the behavior of constructs whose behavior is not defined by the
standard, but it does not refer to any such behaviors as "extensions"
for the purpose of conforming to 4p6.
--
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 | 2015-10-08 15:23 -0700 |
| Message-ID | <7af02bf3-0b39-41ed-b6f0-a901ccbd6baa@googlegroups.com> |
| In reply to | #72220 |
On Thursday, October 8, 2015 at 4:53:35 PM UTC-5, Keith Thompson wrote: > For purposes of the four questions I asked previously (I can repost > them if you like), assume that the implementation does not document > any relevant extensions. It may document whatever it likes about > the behavior of constructs whose behavior is not defined by the > standard, but it does not refer to any such behaviors as "extensions" > for the purpose of conforming to 4p6. Is there any requirement that documentation must refer to extensions as extensions, or would the fact that the documentations specifies behaviors in situations where the Standard does not imply that such behaviors are to be regarded as extensions regardless of whether the document refers to them as such? If the additional behaviors are described in a way which would not require them to be regarded as extensions, then I will grant that the C Standard might not require that compiler behavior match the documentation. On the other hand, I would posit that unless the term "extension" is applied very broadly there will be cases in which it is ambiguous whether something is an extension, which could in turn create ambiguity as to whether some particular behaviors were defined.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-08 17:24 -0700 |
| Message-ID | <lnio6ghota.fsf@kst-u.example.com> |
| In reply to | #72224 |
supercat@casperkitty.com writes:
> On Thursday, October 8, 2015 at 4:53:35 PM UTC-5, Keith Thompson wrote:
>> For purposes of the four questions I asked previously (I can repost
>> them if you like), assume that the implementation does not document
>> any relevant extensions. It may document whatever it likes about
>> the behavior of constructs whose behavior is not defined by the
>> standard, but it does not refer to any such behaviors as "extensions"
>> for the purpose of conforming to 4p6.
>
> Is there any requirement that documentation must refer to extensions as
> extensions, or would the fact that the documentations specifies behaviors
> in situations where the Standard does not imply that such behaviors are
> to be regarded as extensions regardless of whether the document refers
> to them as such?
>
> If the additional behaviors are described in a way which would not require
> them to be regarded as extensions, then I will grant that the C Standard
> might not require that compiler behavior match the documentation. On the
> other hand, I would posit that unless the term "extension" is applied very
> broadly there will be cases in which it is ambiguous whether something is
> an extension, which could in turn create ambiguity as to whether some
> particular behaviors were defined.
The standard doesn't say much about extensions, so the boundary
between extensions and non-extensions is vague. I suppose
if a compiler implements a feature that's relevant only for
constructs whose behavior is not defined by the standard, it can
avoid documenting it simply by not describing it as an extension.
For example, if a shift with a negative right operand always happens
to yield 42, that satisfies the requirements of the standard and
needn't be documented.
I suppose the decision about what is or is not an extension is a
matter of common sense. If some compiler-specific feature is
significant, there's no good reason *not* to document it.
--
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 | 2015-10-09 08:02 -0700 |
| Message-ID | <57951b68-dbfb-4f16-8ed9-fad2a970ad19@googlegroups.com> |
| In reply to | #72232 |
On Thursday, October 8, 2015 at 7:24:08 PM UTC-5, Keith Thompson wrote: > The standard doesn't say much about extensions, so the boundary > between extensions and non-extensions is vague. I suppose > if a compiler implements a feature that's relevant only for > constructs whose behavior is not defined by the standard, it can > avoid documenting it simply by not describing it as an extension. > For example, if a shift with a negative right operand always happens > to yield 42, that satisfies the requirements of the standard and > needn't be documented. My interpretation of the Standard would be that if a compiler says nothing about the effect of x>>(-1), then even if the the current version of the compiler would always yield 42, that would not constitute an extension and future versions would be under no obligation to keep doing the same thing. If, however, an implementation does document that for all x, x>>(-1) will always yield 42, then I would interpret such a statement as documenting an extension in the absence of language explicitly specifying otherwise (e.g. saying that such an expression is expected to yield 42 under typical conditions, but it's not possible to list all the factors that might cause it to do something else). Do you know anything in the Standard which would contradict such a reading? Would you agree that it would create the possibility of an implementation requirements specification... 1. whose author believed that it intended that it be interpreted as an extension mandating particular behavior in the event that an pointer is written using one type and read as another, and 2. whose consumers interpreted it in such fashion, but 3. which was nonetheless interpreted by someone trying to implement that spec as not mandating any particular behavior in such case? Would you agree with the notion that a good language specification which allows for extensions should make clear what sort of textual descriptions should be: 1. Interpreted to indicate that the specification makes a guarantee 2. Interpreted to indicate that the specification does not make a guarantee 3. Should not be used at all in the specification, but replaced by whichever of the above reflects the actual intention. In some cases, it may not be clear whether a particular piece of text should be classified as #1 or #3, but any such piece of text should clearly be recognizable as not being #2. Likewise, some pieces of text might be ambiguously classified as #2 or #3, but would clearly not be #1. Recognizing category #3 makes it possible to prevent ambiguities between #1 and #2.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-09 09:02 -0700 |
| Message-ID | <ln612gghdn.fsf@kst-u.example.com> |
| In reply to | #72265 |
supercat@casperkitty.com writes:
> On Thursday, October 8, 2015 at 7:24:08 PM UTC-5, Keith Thompson wrote:
>> The standard doesn't say much about extensions, so the boundary
>> between extensions and non-extensions is vague. I suppose
>> if a compiler implements a feature that's relevant only for
>> constructs whose behavior is not defined by the standard, it can
>> avoid documenting it simply by not describing it as an extension.
>> For example, if a shift with a negative right operand always happens
>> to yield 42, that satisfies the requirements of the standard and
>> needn't be documented.
>
> My interpretation of the Standard would be that if a compiler says nothing
> about the effect of x>>(-1), then even if the the current version of the
> compiler would always yield 42, that would not constitute an extension and
> future versions would be under no obligation to keep doing the same thing.
Agreed.
> If, however, an implementation does document that for all x, x>>(-1) will
> always yield 42, then I would interpret such a statement as documenting an
> extension in the absence of language explicitly specifying otherwise (e.g.
> saying that such an expression is expected to yield 42 under typical
> conditions, but it's not possible to list all the factors that might cause
> it to do something else).
>
> Do you know anything in the Standard which would contradict such a reading?
I know of nothing in the standard that would either contradict
or support such a reading. The standard says a few things about
extensions, but it never defines the word. It requires extensions
to be documented; it doesn't say exactly what an "extension" is.
I'm not aware that this vagueness has ever caused an actual problem.
> Would you agree that it would create the possibility of an implementation
> requirements specification...
[BIG SNIP]
I'm not going to answer these questions in detail, partly because you
haven't answered mine.
But to summarize: The standard requires *some* things to be documented
by each implementation. Implementations are free to document other
things, beyond what the standard requires. The dividing line between
those two things is not 100% clear. Just as a matter of common sense,
we expect each implementation's documentation to be accurate. In some
cases, inaccurate documentation would violate the standard; in other
cases, it would not. As a practical matter, if an implementation
doesn't follow its own documentation that's a problem, and *it doesn't
really matter* whether that problem is a violation 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-09 12:43 -0700 |
| Message-ID | <9d7adf0f-869c-4284-a546-3f0f0e6bdfc7@googlegroups.com> |
| In reply to | #72269 |
On Friday, October 9, 2015 at 11:02:23 AM UTC-5, Keith Thompson wrote: > I'm not aware that this vagueness has ever caused an actual problem. In cases where there's a broad consensus of 90% of what something is meant to say, and people avoid acting in a way where the other 10% would matter, vagueness isn't a problem. I would suggest, however, that the level of language-lawyering by compiler writers has increased over the last few years, and I think it very likely that if vagueness isn't addressed, the level of language-lawyering will increase until such vagueness inevitably becomes a problem. > I'm not going to answer these questions in detail, partly because you > haven't answered mine. I was not intending to ignore your questions, but did not know how I could answer them without clarifying some other issues first. Based on subsequent discussions, I would feel more confident answering them now if you'd like to repost questions you're still interested in. > But to summarize: The standard requires *some* things to be documented > by each implementation. Implementations are free to document other > things, beyond what the standard requires. The dividing line between > those two things is not 100% clear. Just as a matter of common sense, > we expect each implementation's documentation to be accurate. In some > cases, inaccurate documentation would violate the standard; in other > cases, it would not. As a practical matter, if an implementation > doesn't follow its own documentation that's a problem, and *it doesn't > really matter* whether that problem is a violation of the standard. I would suggest that while it often wouldn't matter whether a disagreement between documentation and behavior constituted a violation of the Standard, in situations where the Standard would impose requirements if a behavior were as documented, failure to abide by such requirements should be viewed as a violation of the Standard.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web