Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "...the value becomes,indeterminate each time the declaration is reached" Date: Tue, 19 Feb 2019 16:42:46 -0800 Organization: None to speak of Lines: 42 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d1fa7b0c0924688e5a92c0c6607ad596"; logging-data="2965"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180sCVoQSvQvq5fK8ufcCrF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:U1/TMN+rypwFfYQJhEb7suCMM88= sha1:4yV8S/8qk1MQ/qJKzIwjGgXcgn8= Xref: csiph.com comp.lang.c:141153 Bart writes: > On 19/02/2019 23:48, Keith Thompson wrote: >> (BTW, a quick experiment showed x "retaining" its previous value >> across iterations, with gcc and clang, -O0, -O1, -O2, and -O3. I'd be >> interested in the results of such an experiment on the implementations >> you use.) > > When I do such tests then they are usually considered meaningless. For > example, every test I might do would show that twos complement > arithmetic is being used, and that signed overflow exhibits predictable > behaviour. But that's something that can't be assumed. > > Same with assuming that variable 'x' retains its value. I can spend 30 > minutes modifying a compiler such that its value is reset every time its > declaration is encountered, so disproving your point. And if I can do > it, then anyone can. I didn't assume any such thing. I speculated that x is likely to "retain its value" in most implementations, and demonstrated that my speculation happens to be correct for a limited number of implementations. Modifying a compiler wouldn't disprove anything I wrote. In fact, in text that you snipped, I explicitly acknowledged that some compilers might reset the value of x. (The phrase "retains its value" isn't strictly accurate from the point of view of the abstract machine.) If I had said that it's reasonable to write code that depends on the assumption that x retains its value, you might have a point. But I didn't say that. > (Why would I do that? So that when first encountered, x doesn't have an > indeterminate value. And it might be easier to reset it each time than > just once.) It's easier to initialize x than to modify a compiler. If you want x to have a determinate value, just give it one. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */