Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: lvalue types
Date: Tue, 17 Apr 2018 08:48:25 -0700
Organization: None to speak of
Lines: 34
Message-ID: <lnzi21ltpy.fsf@kst-u.example.com>
References: <2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> <ln4llzgsus.fsf@kst-u.example.com> <kfn7eqtsfgk.fsf@x-alumni2.alumni.caltech.edu> <lnefl0g9gs.fsf@kst-u.example.com> <kfnh8pwqgwn.fsf@x-alumni2.alumni.caltech.edu> <5fe67088-8e80-478e-a622-02d16b64166a@googlegroups.com> <kfn7epmijc1.fsf@x-alumni2.alumni.caltech.edu> <65e621e1-9bc2-4558-a36d-9712e792494f@googlegroups.com> <kfnvacxbo6r.fsf@x-alumni2.alumni.caltech.edu> <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> <a4ad0855-8098-4bb3-b499-ca1ca457df99@googlegroups.com> <83589df8-fa61-4ffb-8fef-09ab50c8fcf4@googlegroups.com> <b9ba615a-a637-4c93-bd44-3f42d2578b2c@googlegroups.com> <646ca446-53a3-4006-a476-6f52caacd8c9@googlegroups.com> <uqcBC.238$o43.209@fx33.iad> <c2d54052-e0c6-4eef-b7c6-ff9839664bc7@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="dcaeb3e1ef05ac06fdd3cc3805c02cf2"; logging-data="14495"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xhifF3XsSOW6QVwCcpbvP"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:c3WXEvywxbtn+oeUmuuKhI+G87A= sha1:HGEH0sX/we2DJzGNwuGrvZ70r48=
Xref: csiph.com comp.lang.c:129351

supercat@casperkitty.com writes:
> On Monday, April 16, 2018 at 8:51:31 PM UTC-5, Richard Damon wrote:
>> 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.
>
> The paragraph, as written, makes any program that uses structures containing
> non-character members and doesn't jump through absurd hoops to do is not
> strictly conforming, even if it would otherwise (in the absence of that
> paragraph) be strictly conforming and there would be no ambiguity as to its
> meaning.

Strict conformance is not the point.  The point is that, as written
(assuming my reading of the literal wording is correct), it causes
such programs to have undefined behavior, a much stronger statement.

This:
    printf("%zu\n", sizeof (int));
cannot appear in a strictly conforming program, but its behavior is well
defined (and its output implementation-defined).

-- 
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"