[PATCH] Fix execl sentinels

Rich Felker dalias at aerifal.cx
Tue Jul 2 15:02:01 UTC 2013

On Tue, Jul 02, 2013 at 10:32:38AM +0200, Bernd Petrovitsch wrote:
> Hi!
> On Mon, 2013-07-01 at 19:42 +0200, walter harms wrote:
> [...]
> > i like this one:
> > "It is usual for alll null pointers to have a representation in which all bits are zero,
> > but this is not required."
> The bit pattern of a so-called "null pointer" is usually defined by the
> CPU/architecture and has nothing to do with the literal "0" in the C
> source code.

Indeed, they are completely separate issues. Null pointer constants
always come from a value of 0. The representation issue normally only
affects using memset to zero pointers in structs or arrays.

> Isn't that actually an ABI definition, on how pointers and "int"s (and
> "long int"s) are passed on the stack on a given architecture?

Indeed, and the aproach of 'handling' the sentinel issue by defining
NULL as 0L would fail to mask the undefined behavior if you actually
had an ABI that used something other than all-zero-bits to represent
null pointers. However it's still a perfectly valid, conforming
definition; it just loses the property of making buggy applications
work as intended.

By the way, another reason (albeit that probably doesn't apply to
busybox) for fixing sentinel issues in applications is that they would
turn into real bugs on a hypothetical C implementation that uses
typed, bounded pointers. Such pointers might occupy 2-4 machine words
(and thus stack slots or registers when being passed) to convey
information to allow runtime trapping of the vast majority of
undefined behavior due to incorrect pointer usage. This would be a
modern real-world example of an implementation where null pointers are
not necessarily all-zero-bits.


More information about the busybox mailing list