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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-09 14:21 -0700 |
| Message-ID | <lntwpzeo0n.fsf@kst-u.example.com> |
| In reply to | #72308 |
supercat@casperkitty.com writes:
> 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.
[Copying from my earlier post:]
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.
[end of copy]
> 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.
I would suggest that an implementation violating its own documentation
is a problem, and it doesn't bleeping matter whether it's a violation of
the C standard or not.
--
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 15:14 -0700 |
| Message-ID | <6817e4d3-28d7-4e3d-8ea7-4bc2f178728c@googlegroups.com> |
| In reply to | #72335 |
On Friday, October 9, 2015 at 4:21:53 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?
It does.
> Do you agree that this means that the evaluation of that argument
> has undefined behavior?
Except on implementations which define what will happen in such cases.
> Do you agree that "undefined behavior" means only that the C standard
> does not define the behavior?
It means that the C Standard will say nothing whatsoever about the behavior
of a program which invokes Undefined Behavior.
> Do you agree that an implementation is free to define the behavior
> if it chooses to do so?
Naturally.
> 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 documents e.g. that __SIX will be a pre-defined
macro containing the digit 6. What, if anything, would the Standard say
about the behavior of the following program on that implementation?
int main(void)
{
unsigned char x = __SIX;
return -((-15)/2);
}
If the implementation did not document anything about the meaning of __SIX
the program would engage in Undefined Behavior, and a compiler would be
allowed to do anything it wanted with it. If the use of __SIX is deemed
to invoke Undefined Behavior even when an implementation defines it, then
the Standard would say nothing about whether the (-15)/2 should yield -7
or -8 (or do something else entirely) but I don't think that's very helpful.
I think it would be far more helpful to say that the defined meaning for
__SIX would be considered an "extension", and that the a conforming compiler
which includes that extension would be required to evaluate (-15)/2 as
yielding -7. If a compiler documenting the __SIX extension evaluated
(-15)/2 as yielding -8, I would consider that a violation of the C99
Standard even if the compilation unit containing the expression also
contained the __SIX extension.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-13 18:37 -0700 |
| Message-ID | <lnpp0i9qmp.fsf@kst-u.example.com> |
| In reply to | #72339 |
supercat@casperkitty.com writes:
> On Friday, October 9, 2015 at 4:21:53 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?
>
> It does.
>
>> Do you agree that this means that the evaluation of that argument
>> has undefined behavior?
>
> Except on implementations which define what will happen in such cases.
>
>> Do you agree that "undefined behavior" means only that the C standard
>> does not define the behavior?
>
> It means that the C Standard will say nothing whatsoever about the behavior
> of a program which invokes Undefined Behavior.
I see a contradiction between your second and third answers.
The phrase "undefined behavior" means only that the C standard itself
does not define the behavior.
Take signed integer overflow as an example:
int too_big = INT_MAX + 1;
An implementation might choose to define the behavior. The standard
does not. That means it is "undefined behavior" in the sense in which
the Standard defines and uses that phrase. It doesn't mean "behavior
that is not defined *by anything*; it means "behavior that is not
defined by the C standard".
>> Do you agree that an implementation is free to define the behavior
>> if it chooses to do so?
>
> Naturally.
>
>> 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 documents e.g. that __SIX will be a pre-defined
> macro containing the digit 6. What, if anything, would the Standard say
> about the behavior of the following program on that implementation?
>
> int main(void)
> {
> unsigned char x = __SIX;
> return -((-15)/2);
> }
The standard says nothing about its behavior. The standard *plus
the implementation's documentation" says that it initializes x to
6 and returns 7 from main.
> If the implementation did not document anything about the meaning of __SIX
> the program would engage in Undefined Behavior, and a compiler would be
> allowed to do anything it wanted with it. If the use of __SIX is deemed
> to invoke Undefined Behavior even when an implementation defines it, then
> the Standard would say nothing about whether the (-15)/2 should yield -7
> or -8 (or do something else entirely) but I don't think that's very helpful.
That's right, the standard says nothing about it, and the standard by
itself is not useful in determining the behavior of the program. The
standard plus the implementation's documentation specifies the behavior.
> I think it would be far more helpful to say that the defined meaning for
> __SIX would be considered an "extension", and that the a conforming compiler
> which includes that extension would be required to evaluate (-15)/2 as
> yielding -7. If a compiler documenting the __SIX extension evaluated
> (-15)/2 as yielding -8, I would consider that a violation of the C99
> Standard even if the compilation unit containing the expression also
> contained the __SIX extension.
The standard restricts the behavior of extensions. It doesn't
permit them to change the behavior of any strictly conforming
program (a program that uses the identifier __SIX is not strictly
conforming, so that's fine). It requires them to be documented,
which implicitly requires that documentation to be accurate.
As I've said before, the distinction between an "extension" and a
compiler-specific feature that is not an "extension" is not clear,
at least not to me.
In this particular case, I don't think it matters in any practical
sense whether predefining __SIX as 6 is an "extension" or not.
If it is, the standard requires it to be documented, and that
documentation has to be accurate. If it's not (and an implementer
is not required to treat it as an "extension"), then the implementer
still has an obligation to the users to make it work; that obligation
just isn't imposed or enforced by the C 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 | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-10-07 20:56 -0500 |
| Message-ID | <mv4icc$kgl$1@dont-email.me> |
| In reply to | #72159 |
On 10/7/2015 5:32 PM, supercat@casperkitty.com wrote: > 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? > The C++ standard. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 19:41 -0700 |
| Message-ID | <lnoagahyk8.fsf@kst-u.example.com> |
| In reply to | #72169 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 10/7/2015 5:32 PM, supercat@casperkitty.com wrote:
[...]
>> 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?
>
> The C++ standard.
I don't think that's correct.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-07 23:15 -0400 |
| Message-ID | <mv4mvv$2g8$1@dont-email.me> |
| In reply to | #72169 |
On 10/07/2015 09:56 PM, Martin Shobe wrote: > On 10/7/2015 5:32 PM, supercat@casperkitty.com wrote: >> 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? >> > > The C++ standard. The C standard says: "If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime constraint is violated, the behavior is undefined." (4p2) The C++ standard has no such rule. Instead, it says: "The set of _diagnosable rules_ consists of all syntactic and semantic rules in this International Standard except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior.”" (1.4p1) The phrase "diagnosable rules" is in italics, indicating that this clause is the official definition of that term. "-- If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message. -- If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program." (1.4p2) I think that most uses of "shall" or "shall not" would probably count as rules - but according to C++, unless such rules explicitly say "no diagnostic required" or "undefined behavior", then such rules are diagnosable, and therefore must be diagnosed, which would not be the case in C. However, supercat specified that he was referring to the runtime behavior, whereas diagnostics are issued at compile time. The C standard only mandates rejection of a program that contains a #error directive that survives conditional compilation. In contrast, the C++ standard never mandates rejection of a program, not even if it contains a #error directive. If an implementation does choose to translate an ill-formed program, and if someone decides to execute the translated program, then the behavior is undefined, just as it is in C. Therefore, in terms of run-time behavior, the effect of a "shall" in C is essentially the same as it is in C++: if violated, the behavior is undefined. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-14 10:05 +0000 |
| Message-ID | <561e26c6.1820671@news.xs4all.nl> |
| In reply to | #72147 |
Keith Thompson <kst-u@mib.org> wrote: > But there's also a difference between knowing that something will work > 99% of the time and knowing it will work 0% of the time, because the > compiler is required to reject it. The latter is a prohibition; the > former (again, in spite of the Standard's use of the word) is not. > > The only point I'm making here is about your use of the word > "prohibition". You're thinking of the word "prohibition" as used in a law. Think, instead, of that word used in a warranty. You're not going to jail if you do anything prohibited under the warranty, such as putting an electronic apparatus in your microwave - you just void the warranty, and can't complain that it ruins both machines. Similarly, if you do anything prohibited by the C Standard, nobody will come to your door and smack you over the head with a copy of Knuth; but you will void the warranty on that program, and can't complain to the Committee if the result formats your hard drive. And there's another similarity: your microwave salesman may guarantee more than the manufacturer does. For example, he could sell you a doohicky which, he guarantees, allows you to hard-boil an egg in the microwave. If it turns out that it doesn't and you get eggshell all over the innards of the thing, one of which shorts the magnetron, you still _can't_ complain to the manufacturer, who hadn't guaranteed any such thing; but you _can_ now complain to the vendor. And if the author of a specific implementation guarantees that certain constructs which have undefined behaviour under the Standard do, in fact, have defined behaviour using their implementation and certain compilation flags, you can safely use that construct - but _only_ under that implementation, and if it breaks, you can still only complain to the implementor, not to the Committee. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 11:23 +0100 |
| Message-ID | <mvlab2$eq4$1@dont-email.me> |
| In reply to | #72811 |
On 14/10/15 11:05, Richard Bos wrote: <snip> > Similarly, if you do anything prohibited by the C Standard, nobody will > come to your door and smack you over the head with a copy of Knuth; Since the C Standard does not actually guarantee this, it is still wise to be cautious. Knuth may have few chapters, but it has many pages, and (my copy at least) is in hard-cover and three volumes[1]. Knuth *hurts*, even when it is encountered at quite modest velocities. <snip> [1] I haven't yet acquired Volume IVa. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-14 08:24 -0700 |
| Message-ID | <lneggxa2x0.fsf@kst-u.example.com> |
| In reply to | #72815 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 14/10/15 11:05, Richard Bos wrote:
> <snip>
>
>> Similarly, if you do anything prohibited by the C Standard, nobody will
>> come to your door and smack you over the head with a copy of Knuth;
>
> Since the C Standard does not actually guarantee this, it is still wise
> to be cautious. Knuth may have few chapters, but it has many pages, and
> (my copy at least) is in hard-cover and three volumes[1]. Knuth *hurts*,
> even when it is encountered at quite modest velocities.
>
> <snip>
>
> [1] I haven't yet acquired Volume IVa.
Knuth can hurt even when you just read 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-16 11:12 +0000 |
| Message-ID | <5620db89.5362265@news.xs4all.nl> |
| In reply to | #72845 |
Keith Thompson <kst-u@mib.org> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > > On 14/10/15 11:05, Richard Bos wrote: > > > >> Similarly, if you do anything prohibited by the C Standard, nobody will > >> come to your door and smack you over the head with a copy of Knuth; > > > > Since the C Standard does not actually guarantee this, it is still wise > > to be cautious. Knuth may have few chapters, but it has many pages, and > > (my copy at least) is in hard-cover and three volumes[1]. Knuth *hurts*, > > even when it is encountered at quite modest velocities. > > > > <snip> > > > > [1] I haven't yet acquired Volume IVa. > > Knuth can hurt even when you just read it. True, but he can only help. (He has helped me on occasion.) I don't think being hit with Knuth will ever be helpful. Richard
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-10-16 21:55 +0100 |
| Message-ID | <87k2qmfs8n.fsf@gmail.com> |
| In reply to | #72845 |
Keith Thompson <kst-u@mib.org> writes: >> >> [1] I haven't yet acquired Volume IVa. > > Knuth can hurt even when you just read it. YOU CAN'T HANDLE THE KNUTH!
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-10-16 22:08 -0500 |
| Message-ID | <mvsdpl$h10$2@dont-email.me> |
| In reply to | #73075 |
Gareth Owen wrote: > Keith Thompson <kst-u@mib.org> writes: > >>> >>> [1] I haven't yet acquired Volume IVa. >> >> Knuth can hurt even when you just read it. > > YOU CAN'T HANDLE THE KNUTH! > Knuth's "Profile picture" in the UTA mess for a long time included a pair of glasses with a missing earpeice. I found that priceless. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-14 11:44 -0400 |
| Message-ID | <mvlt5j$lbs$1@dont-email.me> |
| In reply to | #72811 |
On 10/14/2015 06:05 AM, Richard Bos wrote: > Keith Thompson <kst-u@mib.org> wrote: > >> But there's also a difference between knowing that something will work >> 99% of the time and knowing it will work 0% of the time, because the >> compiler is required to reject it. The latter is a prohibition; the >> former (again, in spite of the Standard's use of the word) is not. >> >> The only point I'm making here is about your use of the word >> "prohibition". > > You're thinking of the word "prohibition" as used in a law. Think, > instead, of that word used in a warranty. You're not going to jail if > you do anything prohibited under the warranty, such as putting an > electronic apparatus in your microwave - you just void the warranty, and > can't complain that it ruins both machines. I suppose it depends upon the warranty, but I believe the usual wording is that such behavior voids the warranty, not that the behavior is actually prohibited. I just checked three randomly selected warranties that were available online, not one contained any version of the word "prohibit". -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-14 11:12 -0700 |
| Message-ID | <1d38b4cf-db5c-480c-b01d-e33b3c8710c9@googlegroups.com> |
| In reply to | #72850 |
On Wednesday, October 14, 2015 at 10:44:57 AM UTC-5, James Kuyper wrote: > I suppose it depends upon the warranty, but I believe the usual wording > is that such behavior voids the warranty, not that the behavior is > actually prohibited. I just checked three randomly selected warranties > that were available online, not one contained any version of the word > "prohibit". In general if the standard for X prohibits some action Y, that makes it 100% completely impossible for an X to perform action Y, because anything doing Y would, *by definition*, not be an X. I think what makes the C "Standards" different is that they are not at all clear about what kind of entity they are actually defining, and what criteria may be used to distinguish entities of that type from entities which are not of that type.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-07 10:34 +0000 |
| Message-ID | <5614f48d.674734@news.xs4all.nl> |
| In reply to | #72103 |
Keith Thompson <kst-u@mib.org> wrote: > I just checked N1570, and you do have a point. Section 4 paragraph > 1 says: > > In this International Standard, "shall" is to be interpreted as > a requirement on an implementation or on a program; conversely, > "shall not" is to be interpreted as a prohibition. > > And the "shall ... only" wording I quoted above is equivalent to > "shall not ... unless", so yes, the standard does refer to it as a > "prohibition". > > On the other hand, paragraph 2 says: > > If a "shall" or "shall not" requirement that appears outside of > a constraint or runtime-constraint is violated, the behavior is > undefined. Undefined behavior is otherwise indicated in this > International Standard by the words "undefined behavior" or by > the omission of any explicit definition of behavior. There is > no difference in emphasis among these three; they all describe > "behavior that is undefined". > > And the definition of "undefined behavior" clearly says that no > particular action is required. It's an odd kind of "prohibition" > that isn't enforced. The prohibition is on the program; the allowance not to enforce it is to the implementation. It's like giving a referee the option not to book a player for what is technically a minor foul, if the ref considers that the game would benefit from not being interrupted and the foul wasn't severe enough, while at the same time allowing him to send someone off if he breaks someone's leg regardless of intent. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-07 07:23 -0400 |
| Message-ID | <mv2v7j$p7a$1@dont-email.me> |
| In reply to | #72126 |
On 10/07/2015 06:34 AM, Richard Bos wrote: > Keith Thompson <kst-u@mib.org> wrote: ... >> And the definition of "undefined behavior" clearly says that no >> particular action is required. It's an odd kind of "prohibition" >> that isn't enforced. > > The prohibition is on the program; the allowance not to enforce it is to > the implementation. But the program is not prohibited. You're perfectly free to write it, and to try to get an implementation to translate and execute it - and that attempt might succeed. A true prohibition would at the very least, forbid a conforming implementation from accepting the program - and the C standard does that only for #error directives. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-07 09:53 -0700 |
| Message-ID | <db1b31ac-c42a-460e-bd37-7be8f1424e2f@googlegroups.com> |
| In reply to | #72128 |
On Wednesday, October 7, 2015 at 6:23:46 AM UTC-5, James Kuyper wrote:
> But the program is not prohibited. You're perfectly free to write it,
> and to try to get an implementation to translate and execute it - and
> that attempt might succeed.
In order for a program to be usable, there must be some set of requirements
that it is known to meet. For the vast majority of applications, one of
these requirements is that the program must refrain from performing certain
actions no matter what input it receives. A program that cannot be
guaranteed to refrain from performing perform those actions, even in
response to invalid input, will thus not be usable.
A problem with labeling a runtime behavior as "prohibited" is that it leads
to ambiguities about what behavioral guarantees made by an implementation do
or do not remain effect when code performs the "prohibited" action. If
no guarantees remain in effect, then such an action cannot be performed
by a useful program in any domain where applications are required to refrain
from doing certain things [which is to say, most application domains].
I would suggest that when K & R wrote _The C Programming Language_, the art
of writing protocol specifications was still in its infancy; as a result,
many parts of the specification were written in ways which have led to
needless confusion over the years.
I would further suggest that a compiled language should be specified much
like a protocol, with the compiler (server) providing services to the
programmer (client), specifically the transformation of source files into
code that may (for some implementations) be executed directly or (for other
implementations) placed into files that can be processed by other tools to
yield executable programs.
Good protocol documents should very rarely say that something is "undefined
behavior", and should refrain from outright prohibiting any action which,
in the absence of the prohibition, might in some cases serve a useful purpose
which cannot be met by any legitimate alternative. Rather than merely saying
that an action triggers "undefined behavior", it is much more useful for a
protocol which will be used by a range of clients and servers to specify
standardized means by which a client can discover whether a server makes
any promises with regard to that action (and if so, what they are). In
many cases, a protocol document will specify that certain actions are likely
to have as-yet-undetermined meanings attached to them by future versions of
the protocol, and servers must thus refrain from promising that those actions
will have any particular meaning that might conflict with a future protocol
version.
I would suggest that the C Language Specification could be made much more
useful for compiler writers and programmers alike if it were rewritten
somewhat more like a protocol document, even if such a change did not
impose any new requirements upon compiler writers beyond adding to their
documentation to make more explicit what behaviors the compilers promise
and what behaviors they explicitly do not promise; utility could be easily
boosted even more if the Standard were to also define a means by which
many such promises could be processed in machine-readable form, such that
given a program that includes e.g.
// TCSB == Testably Constrained or Specified Behaviors
__TCSB_REQUIRE(__TCSB_TWOCOMP_NARROWING_CONVERSIONS)
at file scope, a compiler would be required to either perform all narrowing
integer conversions according to the rules of two's-complement reduction or
report, in some implementation-defined fashion, that the compiler was not
able to meet the program's requirements.
Presently, there are two levels of conformance defined for C programs. A
strictly-conforming program is one that would meet all requirements if
run on any standards-compliant C platform, no matter how obscure. Even
something as seemingly innocent as
unsigned char c=0; c--; c++;
would not be strictly compliant because it would be legitimate for a C
platform to e.g. have both UCHAR_MAX and INT_MAX equal to 65535 [e.g. if
its "int" type has 16 value bits, one sign bit, and 15 padding bits].
Strict conformance is for many kinds of programs a totally impractical
standard to meet.
On the flip side, a program is "conformant" if the Standard would allow a
compiler to process it in a fashion meeting its requirements, and at least
one compiler does so. If one were to write a shell script that passed
a specified file to a standards-compliant compiler with the macro "__x"
predefined to
int main(void) {return 23;}
then such a shell script would be a standards-compliant compiler, and
a file containing two underbar characters, an x, and a newline would be a
"conforming" C program. While most C programs are "conforming", that says
nothing useful about what systems would be able to process them usefully.
I would like to see a third level of conformance, which would allow a
program to assert that it needs various features and behavioral guarantees,
provided that:
1. Every conforming compiler that could theoretically exist would be
required to either compile the program and yield behavior meeting
requirements or else indicate that the program needs some particular
feature or guarantee the compiler does not support.
2. It must be possible for a compiler to support all the features and
guarantees the program requires (e.g. if a program simultaneously
required that arithmetic overflows cause a trap that will prevent
further program execution and also required that arithmetic overflows
perform two's-complement mod reduction, a compiler could be configured
to support one or the other, but it would be impossible for a compiler
to support both).
Such a program could then be described as strictly conforming to the
extended version of C containing the listed features, and could (by
definition) be guaranteed to run correctly on any compiler whose feature
set contained all the features required by the program. Being able to
define conformance in such a fashion would be vastly more useful than
merely having one category which is uselessly strict and another which
is uselessly broad.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-14 10:13 +0000 |
| Message-ID | <561e2a86.2780765@news.xs4all.nl> |
| In reply to | #72128 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 10/07/2015 06:34 AM, Richard Bos wrote: > > Keith Thompson <kst-u@mib.org> wrote: > ... > >> And the definition of "undefined behavior" clearly says that no > >> particular action is required. It's an odd kind of "prohibition" > >> that isn't enforced. > > > > The prohibition is on the program; the allowance not to enforce it is to > > the implementation. > > But the program is not prohibited. You're perfectly free to write it, > and to try to get an implementation to translate and execute it - and > that attempt might succeed. You're also perfectly free to run your car without coolant, and even to try and get General Motors to replace it for you when it inevitably blows up - good luck with that. Again, it's a prohibition under warranty, not under the penal code. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-14 11:36 -0400 |
| Message-ID | <mvlsmm$jo8$1@dont-email.me> |
| In reply to | #72813 |
On 10/14/2015 06:13 AM, Richard Bos wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > >> On 10/07/2015 06:34 AM, Richard Bos wrote: ... >>> The prohibition is on the program; the allowance not to enforce it is to >>> the implementation. >> >> But the program is not prohibited. You're perfectly free to write it, >> and to try to get an implementation to translate and execute it - and >> that attempt might succeed. > > You're also perfectly free to run your car without coolant, and even to > try and get General Motors to replace it for you when it inevitably > blows up - good luck with that. > Again, it's a prohibition under warranty, not under the penal code. It voids the warranty, and reality penalizes people who choose that options, but the warranty doesn't prohibit it, which makes it a very good analogy to how everything in the C standard is handled. The only thing the C standard actually prohibits is successful translation of a translation unit containing a #error directive that survives conditional inclusion. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-04 13:35 +0100 |
| Message-ID | <87wpv2n74q.fsf@bsb.me.uk> |
| In reply to | #71767 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Saturday, October 3, 2015 at 6:37:53 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > But another >> > post in this thread, by Keith I believe, said there is no hard-and-fast >> > requirement in C that union members overlay actual memory, and that >> > it's possible each member has its own allocated space, even though it's >> > in a union. >> >> That's odd. I don't recall that being said and I'd be very surprised if >> he did say it. C hides the details of where things are behind pointers, >> but all pointers to a union's different members must compare equal when >> converted to void *. > > It was in C90 he was talking about. I may have misunderstood what he's > saying here. To me it conveys that each member could be in its own > space since a read of one member does not guarantee access to the data > written mo a prior member's write: > > https://groups.google.com/d/msg/comp.lang.c/qt1b1yZesws/iYAps--ADQAJ > > "So C90, did not explicitly require the result of an access to > a union member to have anything to do with the value stored to > a different member; the behavior is implementation defined, so > in principle it could do just about anything. But I *think* > the intent was similar, perhaps identical, with C11 making the > wording clearer." What an odd reading of that paragraph. Anyway, C90 does not permit non-overlapping union members. Pointers to all union members must compare equal (when suitably converted). >> > If true, it would seem to be undefined behavior, and not unspecified. >> Even it it were true, why would that make the behaviour undefined? > > Perhaps this is me again using the term 'undefined behavior' to mean > what it means in English, and not what it means in the C standard... That's going to cause some problems in a group like this. I would urge you to use another English phrase. Even so your remark makes no sense. The result is "not fully defined in the English sense" is all cases. There is nothing about your incorrect interpretation of Keith's remark that specifically makes it so. In you sense of the word, C90 makes the type of access being discussed "not fully defined" regardless of whether the members overlap or not. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 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