Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Future of C Date: Tue, 03 Apr 2018 11:23:30 -0700 Organization: None to speak of Lines: 38 Message-ID: References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <20180311161525.ac591de531b83d6b14b2cd43@gmail.com> <90236828-48d7-4ee5-9b86-4cedd0e29b5f@googlegroups.com> <3r7jne-t3h.ln1@gangtai.grep.be> <8e201938-ada4-42d9-8ae6-13b1047306e2@googlegroups.com> <69a08d82-b76a-4334-be63-20dc22f869bf@googlegroups.com> <0dcf08ee-d589-444c-8122-5310d95e80df@googlegroups.com> <9927e2ef-2082-46e2-a1c6-b89da14bae0d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="44da38e7affa7c709ac80b82b9bf6f42"; logging-data="5389"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ALs8Aei1kZjsy0OVHwEiE" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:yeqbl/10d2jZvGrf3k7WFQwW90Y= sha1:OKCA75qO42C9NwxXTnu7fPb7IvI= Xref: csiph.com comp.lang.c:128665 supercat@casperkitty.com writes: > On Monday, April 2, 2018 at 11:12:31 AM UTC-5, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> [...] >> > More to the point, while the C Standard seems to have a curious >> > aversion to doing so, it is possible for it to describe how quality >> > implementations *should* process a piece of code, without mandating >> > that all conforming implementations do so. I would regard stack >> > overflow in this category, in that there is a clear preferred behavior >> > [behave in the same fashion as if the stack hadn't overflowed] but >> > there is nothing a program could do that wouldn't be conforming, >> > except when running the One Program. >> >> The preferred behavior on stack overflow is to "behave in the same >> fashion as if the stack hadn't overflowed"? >> >> What?? > > In most cases where code could hit a translation limit, there Standard > would define how code should behave if it didn't hit that limit. The > Standard may not require that an implementation continue acting as > defined in the Standard once a translation limit is reached, but that > doesn't mean that it doesn't define a behavior. The "preferred behavior" you describe is essentially impossible, so I'm not sure what your point is. The standard acknowledges the existence of capacity limits (1p2) and says that they are outside its scope. Obviously exceeding a capacity limit is going to affect a program's behavior in some way. (Whether that's "undefined behavior" as the standard defines the term is another matter.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"