Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Objective C
Date: Tue, 08 Dec 2015 10:40:01 -0800
Organization: None to speak of
Lines: 46
Message-ID: <lna8pkokce.fsf@kst-u.example.com>
References: <e5eccc3a-f834-45ad-9839-9e02a6d39a93@googlegroups.com> <n2b23d$2n1$1@dont-email.me> <d692da84-f162-4273-9cbd-a9a543c35869@googlegroups.com> <n2c2ut$o6n$1@dont-email.me> <fff2ac89-757c-4d72-8307-9f48cd8327a6@googlegroups.com> <n2ero5$e51$1@dont-email.me> <1837148f-594b-4ffa-a0f3-bdce65277f5f@googlegroups.com> <n2fhmo$vpi$1@dont-email.me> <0g2o4bpcd5ofn5a1rab2vftn0sivi8ssk9@4ax.com> <kfnpoz48hpl.fsf@x-alumni2.alumni.caltech.edu> <8nj05bha7qo58upepjqipdds0fgjkl8umb@4ax.com> <m4k05bdossoe7criehdedlhgfpv1lml9rp@4ax.com> <ln7flb8u7t.fsf@kst-u.example.com> <n2qvdu$gqi$1@dont-email.me> <56510709.8000908@verizon.net> <n2rs8j$mpf$1@dont-email.me> <5651E4F7.3060208@verizon.net> <n2ttfv$6l9$1@dont-email.me> <kfn610s45z3.fsf@x-alumni2.alumni.caltech.edu> <e39b4cf1-fff2-414a-819c-0adadc58267b@googlegroups.com> <kfn4mfsyji3.fsf@x-alumni2.alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="5846"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+67WBFDUBF5Ls8IJwQ+rE3"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:EXQI2A1cpr/UPvKGxrjSjpIXEKs= sha1:Q+TAvDiMCbIRpvMwghLr/8Ptk48=
Xref: csiph.com comp.lang.c:78193

Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
>> On Monday, November 23, 2015 at 6:05:39 PM UTC-6, Tim Rentsch wrote:
>>> Fourth:  As regards the statement in J.2, it is IMO misleading,
>>> or at the very least an oversimplification.  Despite that, I
>>> wouldn't suggest you write a defect report (and see below for why
>>> not).
>>
>> There exist implementations where an uninitialized automatic
>> variable may behave in a fashion inconsistent with its type even
>> when that type would otherwise have no trap representations.
>> [...]
>
> If there are such implementations then they are not conforming.
> There really isn't much else to say about them.

How so?

N1570 6.3.2.1p2:

    Except when it is the operand of [...], an lvalue that does
    not have array type is converted to the value stored in the
    designated object (and is no longer an lvalue); this is called
    *lvalue conversion*.  [...]  If the lvalue designates an object
    of automatic storage duration that could have been declared with
    the register storage class (never had its address taken), and
    that object is uninitialized (not declared with an initializer
    and no assignment to it has been performed prior to use),
    the behavior is undefined.

So this:

    #include <stdio.h>
    int main(void) {
        unsigned char c;
        printf("%u\n", (unsigned)c);
    }

has undefined behavior, even though unsigned char has no trap
representations.

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