AW: XORG_CHECK_MALLOC_ZERO: stop testing malloc, assume the worst

[tlaronde at kergis.com]

On Tue, Oct 29, 2024 at 09:13:57AM -0700, Alan Coopersmith wrote:
> On 10/29/24 04:29, Walter Harms wrote:
> > hello,
> > if i rember correctly there is a whole wrapper for malloc in libX11.
> 
> It's a pretty thin wrapper - just a #define which varies depending on the
> setting of XORG_CHECK_MALLOC_ZERO:
> 
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/libX11-1.8.10/include/X11/Xlibint.h?ref_type=tags#L449-467
> 
> > Beside that i would suggest something like
> > EXPECTED_GLIBC_BEHAVIER (default)
> > or you are on your own otherwise you start to fix a bunch of errors in these wrappers.
> > ppl that use LD_PRELOAD simply should know what they are doing.
> 
> glibc is only one of the libc implementations we need to deal with.
> It's only used on Linux, and even on Linux there's several other options.
> 
> > How often may malloc(0) occur ?
> 
> Enough that I've had to fix several compiler errors & warnings from it when
> enabling this option:
> 
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/266
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/267
> 
> >  glibc says it will return a valid pointer, i thing that reasonable and easy to check.
> 
> But neither the C standard nor POSIX require it, and this macro exists because
> not all libc implementations do return a valid pointer.
> 

Probably a stupid question: why not use the reverse i.e. returning NULL
when the size is zero in order for undue accesses to provoke a
segmentation fault? Because allocating 1 is getting a valid address
(if the malloc is playing tricks in order to allocate a not valid
pointer but not NULL---because it has some debugging functionalities
implemented, requesting a not zero size will defeat this but will
blur debugging)? (Is the answer: "because a huge portion of the code
relies on the pointer not being NULL" ?)

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C