Path: csiph.com!news.swapon.de!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: you think rust may outthrone c? Date: Sat, 22 Jul 2023 15:43:56 -0700 Organization: A noiseless patient Spider Lines: 54 Message-ID: <86pm4jtvmb.fsf@linuxsc.com> References: <87sf9niqb6.fsf@bsb.me.uk> <5fbef78e-14f8-43c4-afaf-17fa5bad12bdn@googlegroups.com> <874jm2tbkt.fsf@nosuchdomain.example.com> <87lefeukpy.fsf@bsb.me.uk> <87edl6uf9y.fsf@bsb.me.uk> <87r0p4tyx4.fsf@bsb.me.uk> <87mszrsx6z.fsf@bsb.me.uk> <87wmyvr9kg.fsf@bsb.me.uk> <87fs5jseuv.fsf@nosuchdomain.example.com> <87cz0nqti7.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="978ba9513973d7ae87a57600d2a2537b"; logging-data="4170358"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18NOQ1gLHZDfQ/po3NLOaBD/YF78Vg8p0w=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:fTDEiXpC/7ysfoaY3ER/knVkCSE= sha1:mBqskLk1PWQqvKUfd2+mxgN0bOQ= Xref: csiph.com comp.lang.c:171124 Ben Bacarisse writes: > Keith Thompson writes: > >> Ben Bacarisse writes: >> [...] >> >>> 6.2.6.1 p5 says (in part) >>> >>> "Certain object representations need not represent a value of >>> the object type. If such a representation is read by an lvalue >>> expression that does not have character type, the behavior is >>> undefined." >> >> Yes, but that's not why reading an uninitialized int object has >> undefined behavior. >> >> If we know that, for example, CHAR_BIT==8, sizeof(int)==4, >> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can >> rigorously infer that int has no padding bits, and no trap >> representations. >> >>> Elsewhere we can find wording to say that uninitialised local >>> variables and newly allocated storage contain indeterminate >>> representations. This includes the possibility of non-value >>> representations. >> >> Yes, but even if the memory happens to contain a valid >> representation for type int, the representation is still >> indeterminate. Indeterminacy is not defined by the bits making up >> the representation. > > I know that indeterminacy is not defined by the bits, but I could > not find any normative text that could lead one to conclude that > accessing such an object is undefined from the indeterminacy > itself. Where is it? > >> An indeterminate value is by definition "either an unspecified >> value or a trap representation". Annex J lists "The value of an >> object with automatic storage duration is used while it is >> indeterminate" as an example of undefined behavior. > > Annex J is not normative text. And if we take Annex J as accurately > conveying the intent, then the actual case being discussed (an > allocated object with indeterminate representation) is, in fact, not > undefined behaviour! Is that what was intended? The discussion is confused because the C standard itself has been confused. The statement in Annex J is misleading (I wouldn't go so far as to say wrong, but it should be viewed more as a rule of thumb than being completely accurate). More complete explanation to be posted (I hope soon) in comp.std.c.