Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: lvalue types Date: Mon, 16 Apr 2018 19:42:10 -0700 Organization: None to speak of Lines: 44 Message-ID: References: <2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> <5fe67088-8e80-478e-a622-02d16b64166a@googlegroups.com> <65e621e1-9bc2-4558-a36d-9712e792494f@googlegroups.com> <117929cb-d6aa-45bc-a5d4-8566bb8c6d58@googlegroups.com> <33a55bca-4174-4e74-9444-8f7f2014b1ad@googlegroups.com> <390abe70-908f-4f19-b6f8-84ec38d3ea90@googlegroups.com> <64746e6c-0c23-47a6-a5d4-d15a33db4aed@googlegroups.com> <83589df8-fa61-4ffb-8fef-09ab50c8fcf4@googlegroups.com> <646ca446-53a3-4006-a476-6f52caacd8c9@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="dcaeb3e1ef05ac06fdd3cc3805c02cf2"; logging-data="26260"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18eoBFDnWN9ngRQnWkYisAM" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Pwy0mUb9WxCx9ulHh84WKUQT92U= sha1:HG5BAuwevjoj3HVv9L0OA+1Iai4= Xref: csiph.com comp.lang.c:129299 Richard Damon writes: > On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: >> That is *generally* true, but there are some notable exceptions such as >> 6.5p7. That paragraph primarily affects programs whose meaning would >> otherwise be unambiguously implied by implementations' specified storage >> formats. > > An you don't seem to understand that what this paragraph says (as > supported by the footnote) that this limitation defines what the > Standard enforces on an implementation. NOTHING in this statement says > that an implementation can't define other conditions or methods of > accesses and how they behave. > > Yes, this does say that, absent promises by the implementation, that a > naive expectation of what seems 'natural' for a processor will behave > the way you want if you don't follow those rules. Every implementation > that I know of allows for ways to tell the compiler "I'm playing tricks > here, please act 'dumb' and do just what I am saying". > > Yes, this says you DO need to read and understand the documentation (and > if still not sure ASK the implementer) to do this sort of trick. Except that *if* I'm reading 6.5p7 correctly (as it's written, as opposed to as it was almost certainly intended), then the behavior of `obj.m = 42;` is explicitly undefined, because it accesses the struct object `obj` by the value `obj.m`, which has type int. I have no doubt that the intent was for `obj.m = 42;` to be well defined, modifying the value of obj.m and therefore the value of obj. The modification of obj is not (intended to be) undefined behavior that every implementation happens to sensibly implement in the same way. It's behavior that is intended to be well defined, with no wiggle room, but the standard failed to specify it correctly. (Assume if you like that "obj" is a struct whose only member is "m", of type int, that obj has no padding bytes, and that int has no padding bits or trap representations.) (Yes, Tim, I'm still planning to respond to your earlier posts.) -- 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"