Path: csiph.com!news.swapon.de!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: Fri, 30 Mar 2018 09:45:35 -0700 Organization: None to speak of Lines: 59 Message-ID: References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <20180310180016.eda9bc36e1a3b182bc2563a8@gmail.com> <20180311000302.8e7cd15242a818ab75eb2e98@gmail.com> <83527acf-abed-4f8f-878c-7d4db9cd5ac1@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: h2725194.stratoserver.net; posting-host="287c9fc6555f97a9d0df4975b865de04"; logging-data="16839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/i0qOrBkrHXENPjDHjxLz" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:RqXKvzxYKhNL/z9w+SpUjDtp6qc= sha1:9Ns6UFZtDI0jqwOb8opex7ggYw8= Xref: csiph.com comp.lang.c:128589 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> David Brown writes: >>>> Overruning the stack is undefined behaviour - [...] >>> >>> Considered in the sense the ISO C standard defines and uses the >>> term, overrunning a run-time stack is not undefined behavior. >> >> Would you care to elaborate on that? How is it not "behavior that >> is not defined" (N1570 4p2)? Correction: the phrase in 4p2 is "behavior that is undefined". > Simple: > > 1. Write a program that runs out of stack but is otherwise > strictly conforming. (It's easy to do this.) > > 2. Identify the statement or declaration whose behavior > is undefined under the semantic descriptions given > in the Standard. (That assertion should be supported > by specific references to relevant passages in the > Standard.) > > 3. If you can't identify any such statement or declaration, > the program has no undefined behavior as the Standard > uses the term, and running out of stack space doesn't > change that. > > Any claim that running out of stack space is undefined behavior > should be able to be supported by showing such a program and > pointing out the particular statement or declaration described in > step (2); if there is no such statement or declaration, there is > no undefined behavior. In the absence of any such identification, > we may reasonably conclude that running out of stack space does > not imply undefined behavior, in the sense the Standard uses the > term. If the behavior of a stack overflow is not "behavior that is undefined", then how is it defined? Or is there some third alternative other than "behavior that is undefined" and "behavior that is defined"? Undefined behavior may be indicated "by the omission of any explicit definition of behavior". The standard acknowledges but does not specify capacity limits in 1p2, saying that the standard does not specify "the size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor". The standard omits any explicit definition of the behavior of a program that has exceeded a capacity limit. -- 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"