The following snippet of code produced a stack overflow.  Is this an
artifact of the standard or of the implementation?

 try { while ( new char[42] ); }
 catch( const std::bad_alloc& ) { }

Evidently we require some memory to build a bad_alloc.  The standard
says that bad_alloc() won't throw.  Can this be insured?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"John D. Hickin" <hickin@CAM.ORG> writes:

>The following snippet of code produced a stack overflow.  Is this an
>artifact of the standard or of the implementation?

The answer to that question is in fact independent of the code snippet.

 |   1.3  Implementation compliance                      [intro.compliance]
 |
 | 2 Every conforming C++ implementation shall, WITHIN ITS RESOURCE LIMITS,
 |   accept and correctly execute well-formed C++ programs, [...]
 |   at least one diagnostic message when  presented  with  any  ill-formed
 |   program  that contains a violation of any diagnosable semantic rule or
 |   of any syntax rule.

If a program overflows the resource limits of the implementation, then
all bets are off.  And the draft standard does not expand on the
meaning of the phrase "within its resource limits", so it is unspecified
when that might occur.

So it's a quality-of-implementation issue.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:

>  |   1.3  Implementation compliance                      [intro.compliance]
>  |
>  | 2 Every conforming C++ implementation shall, WITHIN ITS RESOURCE LIMITS,
>  |   accept and correctly execute well-formed C++ programs,

[...]

> If a program overflows the resource limits of the implementation, then
> all bets are off.  And the draft standard does not expand on the
> meaning of the phrase "within its resource limits", so it is unspecified
> when that might occur.
>
> So it's a quality-of-implementation issue.

Doesn't heap space count as a ressource ?

Then, can a call to malloc cause a core dump ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"John D. Hickin" <hickin@CAM.ORG> writes:

|>  The following snippet of code produced a stack overflow.  Is this an
|>  artifact of the standard or of the implementation?
|>
|>   try { while ( new char[42] ); }
|>   catch( const std::bad_alloc& ) { }
|>
|>  Evidently we require some memory to build a bad_alloc.  The standard
|>  says that bad_alloc() won't throw.  Can this be insured?

Well, stack overflow is always an artifact of the implementation.  I
must say that I am intreged, however, by an implementation that can
overflow the stack without any function calls:-).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard wrote:

[SNIP]

> >
> > So it's a quality-of-implementation issue.
>
> Doesn't heap space count as a ressource ?
>
> Then, can a call to malloc cause a core dump ?

[SNIP]

    Along the same line, using MSVC++ 5.0 under MSWNT 4, it is possible
to allocate memory using new (there seems to be no support for
new(nothrow) as yet...), and hit an exception when actually trying to
use said memory!

    There definitely should be a standard conformance test suite
available when the standard is finaly voted into being (by the way, what
WAS the result of the last vote?)!

        Hubert Holin
        holin@mathp7.jussieu.fr
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

 >Fergus Henderson wrote:
 >
 >> If a program overflows the resource limits of the implementation, then
 >> all bets are off.  And the draft standard does not expand on the
 >> meaning of the phrase "within its resource limits", so it is unspecified
 >> when that might occur.
 >>
 >> So it's a quality-of-implementation issue.
 >
 >Doesn't heap space count as a ressource ?

Sure, probably anything can count as a resource if the implementation wants.

 >Then, can a call to malloc cause a core dump ?

Yes.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Fergus Henderson wrote:
|>
|>  >  |   1.3  Implementation compliance                      [intro.compliance]
|>  >  |
|>  >  | 2 Every conforming C++ implementation shall, WITHIN ITS RESOURCE LIMITS,
|>  >  |   accept and correctly execute well-formed C++ programs,
|>
|>  [...]
|>
|>  > If a program overflows the resource limits of the implementation, then
|>  > all bets are off.  And the draft standard does not expand on the
|>  > meaning of the phrase "within its resource limits", so it is unspecified
|>  > when that might occur.
|>  >
|>  > So it's a quality-of-implementation issue.

Yes.

|>  Doesn't heap space count as a ressource ?
|>
|>  Then, can a call to malloc cause a core dump ?

Good question.  I'm not sure of a call to malloc, but using the memory
returned by malloc (or operator new) results in undefined behavior on a
number of Unixes, including Linux (and possibly some other OS's as
well).  As far as I can tell, this was introduced as a "feature" in
SysVR4; most serious vendors have since repaired the error.

FWIW: nothing in the above is ironic.  This behavior was specified, and
coded intentionally.  The error was in the definition of what the system
should do.  Also, this behavior is useful in certain circumstances.  The
error is not in providing the behavior, but in making it the default
(and in some cases, the only) behavior.

Finally, I don't know if such an implementation is conforming.  There
was some discussion of this in comp.std.c some time back -- the
consensus of that newsgroup seemed to be that it shouldn't be
conforming, but they are not the C standards committee.  I don't know if
a request for interpretation was submitted, and if it was, what the C
committee said.  IMHO: it is not conforming.  (It is certainly not
conforming to the spirit of the standard.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John D. Hickin wrote:
>
> The following snippet of code produced a stack overflow.  Is this an
> artifact of the standard or of the implementation?
>
>         try { while ( new char[42] ); }
>         catch( const std::bad_alloc& ) { }
>
> Evidently we require some memory to build a bad_alloc.  The standard
> says that bad_alloc() won't throw.  Can this be insured?

The implementation. Looks like a bug to me. The only implementation I've used
extensively (Borland) reserves 128 bytes for creating exceptions in, so can
usually throw bad_alloc even when memory is exhausted. My guess is that this
particular implementation tried to call "new std::bad_alloc", and hence went
into infinite recursion.

--

Ciao,
Paul

(Please remove the extra "crud" from the return address,
which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> wrote in article
<3434B88A.41C67EA6@pratique.fr>...
> Doesn't heap space count as a ressource ?
>
> Then, can a call to malloc cause a core dump ?

I consider malloc() causing a core dump because the heap is empty an
unacceptable quality of implementation.

However I fully expect the "stack" (whatever that happens to mean) to be a
finite resource, and that any function call might cause a core dump because
there is no room to push the return address.  Systems which trade off stack
size vs. heap size as the program runs are occasionally justified.

It seems like it would be nice to have a tool which promised a certain
amount of remaining stack space, but such a tool would be difficult to use
effectively.

Systems where malloc() successfully returns a pointer without reserving the
necessary swap space are unspeakably evil, but since they exist we're
forced to speak the unspeakable.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hubert HOLIN <hh@ArtQuest.fr> wrote in article
<343518A0.E26D3069@ArtQuest.fr>...

>     Along the same line, using MSVC++ 5.0 under MSWNT 4, it is possible
> to allocate memory using new (there seems to be no support for
> new(nothrow) as yet...), and hit an exception when actually trying to
> use said memory!

The default behavior for operator new in MSVC++ 5.0 is to return 0 when it
fails (nothrow semantics).  You can install a hander to throw bad_alloc if
that is what you prefer (documented, I haven't tested this).  You can
certainly run into trouble if you dereference a null result.  Given a new
which throws bad_alloc, it should be easy to write your own new(nothrow).

I've used systems where malloc could 'succeed' even though not all of the
memory was usable.  The tests I use to detect such systems (allocate larger
and larger blocks, and touch all of the elements) haven't (so far) shown
the problem on MSVC++ 5.0/NT 4.  If you've got a test that does show the
problem, I'd like to see it.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]