Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C pointer semantics with dynamically allocated struct Date: Tue, 06 Oct 2015 17:16:52 -0700 Organization: None to speak of Lines: 80 Message-ID: References: <874mi9s415.fsf@bsb.me.uk> <9122d591-296e-4acf-a5c3-baf448f6b87c@googlegroups.com> <87si5tqloh.fsf@bsb.me.uk> <87h9m9qd67.fsf@bsb.me.uk> <39591d0f-05c8-4aaa-99e9-283fade3d012@googlegroups.com> <878u7jpwwv.fsf@bsb.me.uk> <878u7jo9xi.fsf@bsb.me.uk> <1cb437ed-216b-439b-b892-60d5c8decf33@googlegroups.com> <3fc6919f-4b41-4eaf-8c4a-ca00ca97fce3@googlegroups.com> <49f58313-f3f1-41d9-9201-0d532f6c0c05@googlegroups.com> <33e4862a-6fc4-4c99-9f8b-74cd388dfbef@googlegroups.com> <995425d1-0f9f-4086-b02c-9a48910336b4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="3369"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/78CEzpPNHWDdxi04xO6yG" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:sL9L4W9uCSLM20Y6x2139o9YP1w= sha1:raWeM08Zui5WFLQyz/fYJNc1eKo= Xref: csiph.com comp.lang.c:72103 supercat@casperkitty.com writes: > On Tuesday, October 6, 2015 at 10:46:15 AM UTC-5, Keith Thompson wrote: >> Yes. But that's still not a prohibition; the standard merely refrains >> from defining the behavior. The way the standard phrases it is that "An >> object shall have its stored value accessed only by an lvalue expression >> that has one of the following types", followed by a list of types (N1570 >> 6.5p7). The "shall" outside a constraint means that the behavior is >> undefined -- i.e., the standard imposes no requirements. [...] >> You make some interesting points, but if your goal is to suggest changes >> to the standard, I suggest using the standard's terminology as much as >> possible. > > To what extent is "Thou shalt do X whenever one does Y" not a prohibition > on doing Y without X?"? It would be really helpful if you'd refer to what the standard actually says rather than paraphrasing it. 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. Undefined behavior can also be an opportunity for language extensions. And as a practical matter, this program: #include int main(void) { float f = 1.0; printf("0x%x\n", *(unsigned*)&f); } just printed 0x3f800000 on my system. (I get a warning about strict-aliasing rules with the right compile-time options, but the behavior is unchanged.) > Such language grants compiler writers full freedom > to interpret the statement as a prohibition, and unless a compiler writer > specifically promises to uphold the rest of the Standard even when code > violates that prohibition, there's no way programmers can know what > guarantees a compiler would or would not make in such case. Yes, the standard permits compilers to prohibit pointer-based type-punning; a conforming compiler could refuse to translate my program But in practice, the standard doesn't actually prohibit it itself (N1570 4p1 notwithstanding), and a conforming compiler could behave in exactly the way you want it to. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"