[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Buffer overflows
From:       "Simon 'corecode' Schubert" <corecode () fs ! ei ! tum ! de>
Date:       2007-08-31 12:48:57
Message-ID: 46D80E39.8060106 () fs ! ei ! tum ! de
[Download RAW message or body]

Wincent Colaiuta wrote:
> > As an example, do your safe API do null pointer checks. This is
> > because strcpy, strlen and the like don't, which is one of the reasons
> > why they are considered unsafe. But then, if you guarantee that you
> > are not passing a null pointer to one of these API, why take the hit
> > of the additional checks when you know that these are safe.
> Do you really think that comparing a pointer to NULL is going to be a 
> speed hit? I would imagine that on most architectures it boils down to 
> one or two machine code instructions.

The question rather is, why should you bother comparing to a NULL pointer?  To return \
an error (EINVAL?)?  I'd rather have either a) the caller check or b) the process \
segfault.  A segfault gives me a nice core file which I can use to hunt the bug.

I also don't see why not checking for NULL pointers is unsafe.  Okay, maybe there are \
platforms out there which do not crash on a NULL pointer derefence, but I doubt these \
are consumers of git.  All other platforms are safe by the implicit check of the MMU.

The worst thing is something like

if (ptr == NULL)
	abort();

which only adds code (and thus needs maintenance), but no value whatsoever.  Either \
the following code tolerates NULL pointers or it will crash and segfault, so why \
bother panicing before.

Of course I might be totally of track...

cheers
  simon
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]