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: C wish list Date: Wed, 20 Mar 2019 13:52:44 -0700 Organization: None to speak of Lines: 41 Message-ID: References: <6b987b94-3a9a-42d8-8542-eefb94a7e3d3@googlegroups.com> <449c19d2-2189-4741-bcd1-420102cf0db4@googlegroups.com> <6052be2f-5f0e-446f-ad61-487a668d9abb@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a26d008c97410be935366452bc5d340d"; logging-data="25491"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8Y1PA0AFBQn0ty+fEehhG" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:qpEbRq8XPc8q0mSgYWMs5UuCRes= sha1:WeojUUczgmD487IZi07L/cDxT+I= Xref: csiph.com comp.lang.c:142129 Howard Chu writes: > On Wednesday, March 20, 2019 at 5:47:58 PM UTC, James Kuyper wrote: >> On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote: [...] >> > OK, for this particular example, assuming a 32 bit CPU and a >> > typical address space split of lower 2GB for user space and upper >> > 2GB for kernel space, and a stack that grows downward from top of >> > user space - referencing past the bounds of this array may >> > overwrite the contents of the stack, and if the reference goes past >> > the bounds of the stack, it will trigger a SIGSEGV. >> > >> > Again, for this particular example, since it's being invoked from >> > main() with no parameters, the actual contents of the stack >> > wouldn't be much more than a single return address to the C runtime >> > startup library. >> >> OK - now how is that an improvement over saying "the behavior is undefined"? > > The improvement is that a compiler can't just silently delete the code. Silently deleting code is not behavior. Compilers routinely "delete" code (more accurately: don't generate code) for statements that can never be executed, such as statements following a return statement. > Note that overwriting the stack return address is a commonly used > mechanism for implementing co-routines. The behavior is completely > safe and deterministic in those use cases. > > It may be simpler to rephrase this wish as: compilers must not > silently delete code that triggers undefined behaviors; optimizers > must not assume undefined behaviors cannot occur. I believe it would be far more difficult to specify that (without seriously inhibiting optimization) than you think it would be. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */