Message-ID: <87BC54A997CCD01198930020AFF6011C040FD4@IS~RKKPRGOP02>
From: "Holejsovsky, Pavel" <PHolejs AT rkk DOT cz>
To: sandmann AT clio DOT rice DOT edu
Cc: djgpp AT delorie DOT com
Subject: RE: Possible misbehavior of write
Date: Thu, 19 Jun 1997 14:24:57 +0200
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Thursday, June 19, 1997 12:39 AM, Charles Sandmann
[SMTP:sandmann AT clio DOT rice DOT edu] wrote:
> > POSIX is pretty vague about EFAULT because, as it claims, "not all
> > systems can reliably detect it."
> 
> We could do several things to improve our detection:
> 
> 1) provide a function to check pointers to be in the valid address
range.  
>    This would have to check the limits of each allocated memory zone.
...
  
> 2) establish a signal handler when entering the function to longjmp
back
>    to an exit point and set the fault code.  This will catch all the
>    bad adresses which would cause a fault (but not necessarily
illegally
>    addressed spanned memory), but may leave the funtion in a half-done

>    state.  This could probably be done as a nice function setup fairly
>    easily.
> 
> So - is it worth it?

All these things would be very nice to have during development stage,
but it would slow down the final executable and also make it bigger. I
think that idea of debug/release libraries/builds used heavily in
commercial compilers would be appropriate here. Debug libc build would
contain pointer checking, memory leaks checking, advanced argument
checking etc. If some of these checks fails, then it is appropriate to
abort program with some message, stack dump etc. instead of returning to
caller with error status - otherwise it could cause that executable
would work 'well' (no crashes) as debug build but will crash as release
build.

What do you think about it?

Pavel