Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #128633

Re: Future of C

Newsgroups comp.lang.c
Date 2018-04-02 01:42 -0700
References (17 earlier) <p88srs$17c$1@dont-email.me> <kfna7uunp2c.fsf@x-alumni2.alumni.caltech.edu> <ln7epxwm5h.fsf@kst-u.example.com> <kfnh8oxlkfn.fsf@x-alumni2.alumni.caltech.edu> <lnin9dtsuo.fsf@kst-u.example.com>
Message-ID <d96f52ff-e2dd-40b8-b260-31359f5417e5@googlegroups.com> (permalink)
Subject Re: Future of C
From Malcolm McLean <malcolm.arthur.mclean@gmail.com>

Show all headers | View raw


On Friday, March 30, 2018 at 5:45:44 PM UTC+1, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>> David Brown <david.brown@hesbynett.no> 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.
> 
Something can be undefined in C standard terms if the C standard
says that it is undefined. It is undefined in normal parlance if the 
C standard does not provide a definition for the behaviour. Stack
overflow is obviously in the latter category. 

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 21:02 -0700
  Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-27 09:39 +0200
    Re: Future of C supercat@casperkitty.com - 2018-03-27 07:37 -0700
      Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 11:19 -0700
  Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-27 00:42 -0700
  Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-27 08:52 -0700
    Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-30 07:14 -0700
      Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-30 17:23 +0200
        Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-31 02:41 -0700
      Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-30 09:45 -0700
        Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-02 01:42 -0700
          Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 04:53 -0700
          Re: Future of C supercat@casperkitty.com - 2018-04-02 06:02 -0700
            Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 06:57 -0700
            Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-02 09:12 -0700
              Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-02 13:30 -0700
                Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-03 00:59 -0700
              Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-02 22:33 +0200
                Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 01:40 -0700
                Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-03 12:47 +0200
              Re: Future of C supercat@casperkitty.com - 2018-04-03 09:51 -0700
                Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 11:23 -0700
                Re: Future of C supercat@casperkitty.com - 2018-04-03 11:37 -0700
                Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 11:46 -0700
                Re: Future of C supercat@casperkitty.com - 2018-04-03 12:26 -0700
                Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-04 01:17 -0700
                Re: Future of C supercat@casperkitty.com - 2018-04-04 09:45 -0700
          Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-02 09:10 -0700
            Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 09:33 -0700
            Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 01:35 -0700
              Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-03 12:50 +0200
                Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 04:01 -0700
              Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 09:12 -0700
        Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 16:17 -0700
          Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-04 17:26 -0700
            Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 07:30 -0700
              Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-09 08:52 -0700
                Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-11 08:21 -0700
                Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-11 09:28 -0700
          Re: Future of C supercat@casperkitty.com - 2018-04-05 11:00 -0700

csiph-web