Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: C++ standard library and exceptions

Reply
Thread Tools

Re: C++ standard library and exceptions

 
 
André Gillibert
Guest
Posts: n/a
 
      12-12-2011
"io_x" <(E-Mail Removed)> wrote:
> +comp.lang.c
> "ittium" <(E-Mail Removed)> ha scritto nel messaggio
> news:(E-Mail Removed)...
> > On 08-12-2011 PM 06:38, Goran wrote:
> >> On Dec 8, 12:05 pm, ittium<(E-Mail Removed)> wrote:
> >>> On 12/8/2011 2:32 PM, Goran wrote:
> >>>

>
> i actualy think:
> all exceptions in C or C++ library, or whatsover library,
> but division by 0, has to be turned off
>
> all beahavour of seg fault or "abort()" in C or C++ library
> or in each library, has to be minimized to 0
>
> for this i say all function has to return a possible
> error code
> all function in C has no error code are badly thinked
>
> this is valid too for API library OS too
>
>
>


Followup-To: comp.lang.c++

Do you mean that the behavior of segfault should be defined as throwing
a standard C++ exception?

Well-defined programs cannot have any segfault... Any program having a
segfault is in inconsistent state. Important data may have been
damaged, and there is no guarantee of any sort of recovery.

For the sake of security and data integrity, a good system detecting
such an error, should kill/abort/terminate the program immediately.

--
André Gillibert
 
Reply With Quote
 
 
 
 
Wolfgang.Draxinger
Guest
Posts: n/a
 
      12-15-2011
On Tue, 13 Dec 2011 09:17:45 +0100
"io_x" <(E-Mail Removed)> wrote:

> yes but it is better function return error code than seg fault the
> program e.g


The problem is, that a segfault may corrupt the very error detection
logic. A segfault in a process means, that there is no way the
execution of the program can continue without being sure, something
will break eventually somewhere else.

The only sane reaction to a segfault is a process' equivalent to
biological apoptosis http://en.wikipedia.org/wiki/Apoptosis

If you want to gracefully react to a segfault, upon program start fork
the process and install a handler for the case if it terminates with
segfault error condition. You could even go as far as attaching to the
process as debugger and extract the state of the process to give some
sensible error report.

If you were really crazy -- and I mean in the sense of a lunatic, Joker
like madness -- you could even try to implement a system the restores
the process state in the last sane state recorded before commencing the
action that ultimately led to the segfault (however it's very likely
the process will segfault again).

A process segfaulting always means, that there is something
fundamentally broken in the programming itself, which cannot be fixed
by dealing with a error condition, but only by fixing the errornous
code itself.


Wolfgang

 
Reply With Quote
 
 
 
 
Joshua Maurice
Guest
Posts: n/a
 
      12-15-2011
On Dec 15, 3:14*am, "Wolfgang.Draxinger"
<(E-Mail Removed)-muenchen.de> wrote:
> On Tue, 13 Dec 2011 09:17:45 +0100
>
> "io_x" <(E-Mail Removed)> wrote:
> > yes but it is better function return error code than seg fault the
> > program e.g

>
> The problem is, that a segfault may corrupt the very error detection
> logic. A segfault in a process means, that there is no way the
> execution of the program can continue without being sure, something
> will break eventually somewhere else.
>
> The only sane reaction to a segfault is a process' equivalent to
> biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis
>
> If you want to gracefully react to a segfault, upon program start fork
> the process and install a handler for the case if it terminates with
> segfault error condition. You could even go as far as attaching to the
> process as debugger and extract the state of the process to give some
> sensible error report.
>
> If you were really crazy -- and I mean in the sense of a lunatic, Joker
> like madness -- you could even try to implement a system the restores
> the process state in the last sane state recorded before commencing the
> action that ultimately led to the segfault (however it's very likely
> the process will segfault again).
>
> A process segfaulting always means, that there is something
> fundamentally broken in the programming itself, which cannot be fixed
> by dealing with a error condition, but only by fixing the errornous
> code itself.


Again, as explained else-thread, several very popular and very
successful programs disagree with you. Examples include Sun's/Oracle's
JVM.
 
Reply With Quote
 
hanukas
Guest
Posts: n/a
 
      12-18-2011
On Dec 16, 1:50*am, Joshua Maurice <(E-Mail Removed)> wrote:
> On Dec 15, 3:14*am, "Wolfgang.Draxinger"
>
>
>
>
>
>
>
>
>
> <(E-Mail Removed)-muenchen.de> wrote:
> > On Tue, 13 Dec 2011 09:17:45 +0100

>
> > "io_x" <(E-Mail Removed)> wrote:
> > > yes but it is better function return error code than seg fault the
> > > program e.g

>
> > The problem is, that a segfault may corrupt the very error detection
> > logic. A segfault in a process means, that there is no way the
> > execution of the program can continue without being sure, something
> > will break eventually somewhere else.

>
> > The only sane reaction to a segfault is a process' equivalent to
> > biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis

>
> > If you want to gracefully react to a segfault, upon program start fork
> > the process and install a handler for the case if it terminates with
> > segfault error condition. You could even go as far as attaching to the
> > process as debugger and extract the state of the process to give some
> > sensible error report.

>
> > If you were really crazy -- and I mean in the sense of a lunatic, Joker
> > like madness -- you could even try to implement a system the restores
> > the process state in the last sane state recorded before commencing the
> > action that ultimately led to the segfault (however it's very likely
> > the process will segfault again).

>
> > A process segfaulting always means, that there is something
> > fundamentally broken in the programming itself, which cannot be fixed
> > by dealing with a error condition, but only by fixing the errornous
> > code itself.

>
> Again, as explained else-thread, several very popular and very
> successful programs disagree with you. Examples include Sun's/Oracle's
> JVM.


JVM.. uh huh.. okay
 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      12-19-2011
On Dec 18, 7:02*pm, "io_x" <(E-Mail Removed)> wrote:
> "Joshua Maurice" <(E-Mail Removed)> ha scritto nel messaggionews:(E-Mail Removed)...
> On Dec 15, 3:14 am, "Wolfgang.Draxinger"
>
>
>
>
>
>
>
>
>
> <(E-Mail Removed)-muenchen.de> wrote:
> > On Tue, 13 Dec 2011 09:17:45 +0100

>
> > "io_x" <(E-Mail Removed)> wrote:
> > > yes but it is better function return error code than seg fault the
> > > program e.g

>
> > The problem is, that a segfault may corrupt the very error detection
> > logic. A segfault in a process means, that there is no way the
> > execution of the program can continue without being sure, something
> > will break eventually somewhere else.

>
> > The only sane reaction to a segfault is a process' equivalent to
> > biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis

>
> > If you want to gracefully react to a segfault, upon program start fork
> > the process and install a handler for the case if it terminates with
> > segfault error condition. You could even go as far as attaching to the
> > process as debugger and extract the state of the process to give some
> > sensible error report.

>
> > If you were really crazy -- and I mean in the sense of a lunatic, Joker
> > like madness -- you could even try to implement a system the restores
> > the process state in the last sane state recorded before commencing the
> > action that ultimately led to the segfault (however it's very likely
> > the process will segfault again).

>
> > A process segfaulting always means, that there is something
> > fundamentally broken in the programming itself, which cannot be fixed
> > by dealing with a error condition, but only by fixing the errornous
> > code itself.

>
> Again, as explained else-thread, several very popular and very
> successful programs disagree with you. Examples include Sun's/Oracle's
> JVM.
>
> #if these programs do that, without to detect-correct the error in the
> #new versions of programs
> #they make wrong
> #because wrong write in the memory can produce indefinite result...
> #
> #but i say only it is better some detection first of write in memory
> #that can be wrong memory for the program
> #so could be no wrong write but there is a detection of the error


Null pointer dereferences are undefined behavior by the C++ standard.
Linux, for example, defines the behavior.

Your proposed solution of checking the pointer for null before
accessing carries a cost in the "not thrown" code path - the "test if
0 and branch" instruction(s). The solution that Sun's/Oracle's JVM
uses, that of using segfaults, carries no overhead in the "not thrown"
code path.
 
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++ standard library and exceptions ittium C++ 17 12-19-2011 11:52 AM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM
Re: Possible additions to the standard library? (WAS: Aboutstandard library improvement) Daniel Bickett Python 0 02-04-2005 11:22 AM
Re: Possible additions to the standard library? (WAS: Aboutstandard library improvement) Fredrik Lundh Python 0 02-04-2005 07:34 AM



Advertisments