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:47:20 -0700 Organization: None to speak of Lines: 46 Message-ID: References: <6b987b94-3a9a-42d8-8542-eefb94a7e3d3@googlegroups.com> <449c19d2-2189-4741-bcd1-420102cf0db4@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/nFmtg0b7aAA0HxLUvdhp6" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:vAkmoxy77RYkfo65gmZrA5oiWMU= sha1:L5EOBxuufvJ0y+egk5qThpxA7Oo= Xref: csiph.com comp.lang.c:142128 Bart writes: > On 20/03/2019 17:47, 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"? >> > > It will rule out nasal daemons for a start. No more than they're already ruled out. > Alternatively, an implementation can ensure that such an out-of-bounds > access will behave predictably and safely. Sure, but nobody here is proposing that *all* C implementations should be required to implement run-time bounds checking. > What the OP has it mind might simply be for things like integer overflow > to be well-defined and guaranteed to behave exactly as it already does > on 99.99% of machines. No, that's not what the OP said. Upthread, Howard Chu wrote: On that topic, it would be nice to see a compiler mode that makes all undefined behaviors implementation defined ... If you just want to make signed integer overflow well defined (presumably with two's-complement wraparound behavior), that's a much more reasonable proposal. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */