Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: Is there a good use case for noexcept?

Reply
Thread Tools

Re: Is there a good use case for noexcept?

 
 
Stefan Ram
Guest
Posts: n/a
 
      04-24-2011
Alexander Terekhov <(E-Mail Removed)> writes in comp.lang.c++.moderated:
>DeMarcus wrote:
>[...]
>>The problem is that stack exhaustion (out-of-stack-memory) is also a
>>failure, so even the simple function std::swap may fail.

>Exactly! And the runtime behaviour should be the same as with
> int f() { // implicit nothrow/noexcept
> throw 0;
> }
>No?
>C'mon, a noexcept function shall call abort() (C++ terminate()) on
>throw / stack exhaustion.


A libraryable function should return control to its caller
whenever possible. And usually, an exhausted stack will be
relieved more by returning than by calling.

I also wonder whether you suggest that every (noexecept)
function should always check explicitly for stack exhaustion
and try to specify a behavior for this.

Is anyone here who uses »abort()« at all?

I assume nearly all the programs we write operate under the
»optimistic« assumption that there always is enough stack,
while at the same time try to avoid being too careless about
it, that is, trying to avoid deep recursion and so.

This might be not good enough for high-security
applications, where one would like to have some call like
»size_t autostorage()« that gives the amount of automatic
storage still available.

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-25-2011
On Apr 24, 4:07 pm, (E-Mail Removed)-berlin.de (Stefan Ram) wrote:
> Alexander Terekhov <(E-Mail Removed)> writes in comp.lang.c++.moderated:


> >DeMarcus wrote:
> >[...]
> >>The problem is that stack exhaustion (out-of-stack-memory)
> >>is also a failure, so even the simple function std::swap may
> >>fail.

> >Exactly! And the runtime behaviour should be the same as with
> > int f() { // implicit nothrow/noexcept
> > throw 0;
> > }
> >No?
> >C'mon, a noexcept function shall call abort() (C++
> >terminate()) on throw / stack exhaustion.


Stack exhaustion is undefined behavior in C++. Mainly because
C++ generates and executes native code, and in native code,
stack exhaustion is handled by the OS; there's nothing the
generated code can do to trap it, or even to detect it.

> A libraryable function should return control to its caller
> whenever possible. And usually, an exhausted stack will be
> relieved more by returning than by calling.


Usually, an exhausted stack will either result in a core
dump, or overwriting memory that isn't part of the stack. (The
latter can easily occur in multithreaded environments, if the
stack for each thread is allocated in the general free store.)

> I also wonder whether you suggest that every (noexecept)
> function should always check explicitly for stack exhaustion
> and try to specify a behavior for this.


It would be nice, if it were possible.

> Is anyone here who uses »abort()« at all?


Anyone developing critical applications. And probably a lot of
others.

> I assume nearly all the programs we write operate under the
> »optimistic« assumption that there always is enough stack,
> while at the same time try to avoid being too careless about
> it, that is, trying to avoid deep recursion and so.


Agreed. Along with a couple of other optimistic assumptions:
there will be enough memory, an int won't overflow, etc.
Ideally, we'd like 1) to be able to validate our assumptions up
front (usually possible for int overflowing, not so easy for the
other cases), and 2) have the program fail immediately if the
assumption fails.

> This might be not good enough for high-security
> applications, where one would like to have some call like
> »size_t autostorage()« that gives the amount of automatic
> storage still available.


One would like a lot of things. One doesn't always get them.

--
James Kanze
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      04-25-2011
Le 25/04/11 17:55, James Kanze a écrit :
>
> Stack exhaustion is undefined behavior in C++. Mainly because
> C++ generates and executes native code, and in native code,
> stack exhaustion is handled by the OS; there's nothing the
> generated code can do to trap it, or even to detect it.
>


Under windows this is just wrong. You can trap stack exhaustion using the

__try / __except

construct, and act accordingly, maybe jumping into a recovery context
with setjmp/longjmp

I would be surprised that under linux you couldn't do that too.

 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      04-25-2011
On Apr 25, 12:28*pm, Paavo Helde <(E-Mail Removed)> wrote:
> jacob navia <(E-Mail Removed)> wrote in news:ip48fl$p55$1
> @speranza.aioe.org:
>
>
>
> > Le 25/04/11 17:55, James Kanze a écrit :

>
> >> Stack exhaustion is undefined behavior in C++. *Mainly because
> >> C++ generates and executes native code, and in native code,
> >> stack exhaustion is handled by the OS; there's nothing the
> >> generated code can do to trap it, or even to detect it.

>
> > Under windows this is just wrong. You can trap stack exhaustion using

> the
>
> > __try / __except

>
> > construct, and act accordingly, maybe jumping into a recovery context
> > with setjmp/longjmp

>
> It is not so easy as you make it sound. For catching SEH exceptions in
> Windows more or less reliably one must specify the /EHa compiler option,
> otherwise these exceptions may leave C++ objects half-created or half-
> destroyed. Using the /EHa compiler option will decrease performance all
> over the place. Also longjmp does not play well with C++ objects, at the
> best one may count on memory leaks.
>
> To continue execution after a stack overflow one must restore the stack
> guard page. There are numerous rules about where this can be done(inside
> a C++ catch handler it is prohibited, for example) and even then it can
> fail. Seehttp://msdn.microsoft.com/en-us/library/89f73td2%28v=VS.100%
> 29.aspx for details.


I must agree with jacob navia that you can recover from an "out of
stack" error in most cases on desktop OSes, although I agree with you
that it is non-trivial, highly system dependent, and not guaranteed to
work aka "hacky". However, assuming that your stack frame is smaller
than the page guard size, it's quite doable. JVMs do it all the time
AFAIK. I'm pretty sure you're guaranteed a SIGSEGV in POSIX, which
IIRC is how JVMs do it on POSIX systems. All I know of win32 is what
you just wrote.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-25-2011
On 04/26/11 09:31 AM, Joshua Maurice wrote:
> On Apr 25, 12:28 pm, Paavo Helde<(E-Mail Removed)> wrote:
>> jacob navia<(E-Mail Removed)> wrote in news:ip48fl$p55$1
>> @speranza.aioe.org:
>>
>>
>>
>>> Le 25/04/11 17:55, James Kanze a écrit :

>>
>>>> Stack exhaustion is undefined behavior in C++. Mainly because
>>>> C++ generates and executes native code, and in native code,
>>>> stack exhaustion is handled by the OS; there's nothing the
>>>> generated code can do to trap it, or even to detect it.

>>
>>> Under windows this is just wrong. You can trap stack exhaustion using

>> the
>>
>>> __try / __except

>>
>>> construct, and act accordingly, maybe jumping into a recovery context
>>> with setjmp/longjmp

>>
>> It is not so easy as you make it sound. For catching SEH exceptions in
>> Windows more or less reliably one must specify the /EHa compiler option,
>> otherwise these exceptions may leave C++ objects half-created or half-
>> destroyed. Using the /EHa compiler option will decrease performance all
>> over the place. Also longjmp does not play well with C++ objects, at the
>> best one may count on memory leaks.
>>
>> To continue execution after a stack overflow one must restore the stack
>> guard page. There are numerous rules about where this can be done(inside
>> a C++ catch handler it is prohibited, for example) and even then it can
>> fail. Seehttp://msdn.microsoft.com/en-us/library/89f73td2%28v=VS.100%
>> 29.aspx for details.

>
> I must agree with jacob navia that you can recover from an "out of
> stack" error in most cases on desktop OSes, although I agree with you
> that it is non-trivial, highly system dependent, and not guaranteed to
> work aka "hacky".


In other words, something that can't be standardised! All of the
embedded OS I've used just kill or suspend the offending task/thread.

--
Ian Collins
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-25-2011
On Apr 25, 5:45 pm, jacob navia <(E-Mail Removed)> wrote:
> Le 25/04/11 17:55, James Kanze a écrit :
> > Stack exhaustion is undefined behavior in C++. Mainly because
> > C++ generates and executes native code, and in native code,
> > stack exhaustion is handled by the OS; there's nothing the
> > generated code can do to trap it, or even to detect it.


> Under windows this is just wrong. You can trap stack exhaustion using the


> __try / __except


> construct, and act accordingly, maybe jumping into a recovery context
> with setjmp/longjmp


Have you actually tried this in a multithreaded environment?
(It might work; as far as I can see, Windows does insist on
defining all of the thread's stacks itself. But in practice,
judging from what I've seen, catching stack overflow is
problematic at best.)

> I would be surprised that under linux you couldn't do that too.


If it does, then Linux isn't Posix compliant.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-25-2011
On Apr 25, 10:31 pm, Joshua Maurice <(E-Mail Removed)> wrote:
> On Apr 25, 12:28 pm, Paavo Helde <(E-Mail Removed)> wrote:


[...]
> I must agree with jacob navia that you can recover from an "out of
> stack" error in most cases on desktop OSes, although I agree with you
> that it is non-trivial, highly system dependent, and not guaranteed to
> work aka "hacky". However, assuming that your stack frame is smaller
> than the page guard size, it's quite doable. JVMs do it all the time
> AFAIK. I'm pretty sure you're guaranteed a SIGSEGV in POSIX, which
> IIRC is how JVMs do it on POSIX systems.


You are definitely not guaranteed a SIGSEGV in POSIX. Under
POSIX, you can put the stack pretty much anywhere you want. And
JVM's use their own stack, not the system stack, so they can do
whatever checks are necessary.

--
James Kanze
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-26-2011
Le 25/04/11 23:58, James Kanze a écrit :
> On Apr 25, 5:45 pm, jacob navia<(E-Mail Removed)> wrote:
>> Le 25/04/11 17:55, James Kanze a écrit :
>>> Stack exhaustion is undefined behavior in C++. Mainly because
>>> C++ generates and executes native code, and in native code,
>>> stack exhaustion is handled by the OS; there's nothing the
>>> generated code can do to trap it, or even to detect it.

>
>> Under windows this is just wrong. You can trap stack exhaustion using the

>
>> __try / __except

>
>> construct, and act accordingly, maybe jumping into a recovery context
>> with setjmp/longjmp

>
> Have you actually tried this in a multithreaded environment?
> (It might work; as far as I can see, Windows does insist on
> defining all of the thread's stacks itself. But in practice,
> judging from what I've seen, catching stack overflow is
> problematic at best.)
>


Based on what you have seen.

>> I would be surprised that under linux you couldn't do that too.

>
> If it does, then Linux isn't Posix compliant.


Obviously here you mean:

"If linux would support the windows API it wouldn't be Posix compliant"

in your efforts of misunderstanding what I said...

I repeat:

I would be surprised that under linux you can't catch stack overflow

Happy now?
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-26-2011
On 04/26/11 09:43 PM, jacob navia wrote:
> Le 25/04/11 23:58, James Kanze a écrit :
>> On Apr 25, 5:45 pm, jacob navia<(E-Mail Removed)> wrote:
>>> Le 25/04/11 17:55, James Kanze a écrit :
>>>> Stack exhaustion is undefined behavior in C++. Mainly because
>>>> C++ generates and executes native code, and in native code,
>>>> stack exhaustion is handled by the OS; there's nothing the
>>>> generated code can do to trap it, or even to detect it.

>>
>>> Under windows this is just wrong. You can trap stack exhaustion using the

>>
>>> __try / __except

>>
>>> construct, and act accordingly, maybe jumping into a recovery context
>>> with setjmp/longjmp

>>
>> Have you actually tried this in a multithreaded environment?
>> (It might work; as far as I can see, Windows does insist on
>> defining all of the thread's stacks itself. But in practice,
>> judging from what I've seen, catching stack overflow is
>> problematic at best.)
>>

>
> Based on what you have seen.
>
>>> I would be surprised that under linux you couldn't do that too.

>>
>> If it does, then Linux isn't Posix compliant.

>
> Obviously here you mean:
>
> "If linux would support the windows API it wouldn't be Posix compliant"
>
> in your efforts of misunderstanding what I said...
>
> I repeat:
>
> I would be surprised that under linux you can't catch stack overflow


I think the point James was making is with Posix threads, you can place
the thread's stack anywhere, so there's no (reasonable) way to detect an
overflow.

--
Ian Collins
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-26-2011
Le 26/04/11 11:48, Ian Collins a écrit :
>
> I think the point James was making is with Posix threads, you can place
> the thread's stack anywhere, so there's no (reasonable) way to detect an
> overflow.
>


OK, then you just put a page of 4K addresses with no access behind your
stacks. When stack is exhausted you arrive at that page and you get a
segmentation violation that you can catch.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C++ Gurus - Is C++ a good choice for public API(s)??? Are there cleanways to solve known problems there? arijit79@gmail.com C++ 11 06-14-2009 02:54 PM
Are there ANY good forums out there anymore??? Eric Danstron ASP General 1 09-22-2005 01:37 PM
how to case select with case-insensitive string ? Tee ASP .Net 3 06-23-2004 07:40 PM
Possible to turn on/off cookieless sessions dynamically on a case by case basis at run-time? Steve Franks ASP .Net 2 06-10-2004 02:04 PM
Is there good software out there to id and remove trojan progams?? WyleCoyote@cactus.com Computer Security 2 10-10-2003 07:43 PM



Advertisments