«

"io_x" <> wrote:
> +comp.lang.c
> "ittium" <> ha scritto nel messaggio
> news:...
> > On 08-12-2011 PM 06:38, Goran wrote:
> >> On Dec 8, 12:05 pm, ittium<itt...@gmail.com> 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

On Tue, 13 Dec 2011 09:17:45 +0100
"io_x" <> 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

On Dec 15, 3:14*am, "Wolfgang.Draxinger"
<Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> On Tue, 13 Dec 2011 09:17:45 +0100
>
> "io_x" <a...@b.c.invalid> 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.

On Dec 16, 1:50*am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Dec 15, 3:14*am, "Wolfgang.Draxinger"
>
>
>
>
>
>
>
>
>
> <Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> > On Tue, 13 Dec 2011 09:17:45 +0100
>
> > "io_x" <a...@b.c.invalid> 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

On Dec 18, 7:02*pm, "io_x" <a...@b.c.invalid> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> ha scritto nel messaggionews:b39eedd8-3f12-470c-9a9c-...
> On Dec 15, 3:14 am, "Wolfgang.Draxinger"
>
>
>
>
>
>
>
>
>
> <Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> > On Tue, 13 Dec 2011 09:17:45 +0100
>
> > "io_x" <a...@b.c.invalid> 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.