d3dx9_36/tests: Fix printing a NULL string

André Hentschel suggested:
> Should stop the crash on Solaris and maybe others
> -    trace("parent_data = (%p) -> %s\n", parent_data, (char *)parent_data);
> +    trace("parent_data (%p) -> %s\n", parent_data, parent_data ? (char *)parent_data : "(null)");

This is sooo backwards.  You don't want to try and find all places where (null) may be printed.
I remember seeing (null) in logs here and there, so you're telling us that turning on
Wine logs in Solaris can randomly crash Wine because it crashes on printf("%s", NULL)?

I'm very surprised. I thought Solaris was one of the first machines - decades ago - where I observed "(null)" for NULL.
(Or is that really glibc only?)

Regards,
 Jörg Höhle

[David Laight]

On Tue, Aug 30, 2011 at 12:44:05PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> Wine logs in Solaris can randomly crash Wine because it crashes on printf("%s", NULL)?
>
> I'm very surprised. I thought Solaris was one of the first machines - decades ago - where I observed "(null)" for NULL.
> (Or is that really glibc only?)

Probably glibc, solaris was one of the first unix (I saw) to fault
on accesses to address zero and certainly the current solaris libc
will fault.

	David

-- 
David Laight: david(a)l8s.co.uk

[Francois Gouget]

On Tue, 30 Aug 2011, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> André Hentschel suggested:
> > Should stop the crash on Solaris and maybe others
> > -    trace("parent_data = (%p) -> %s\n", parent_data, (char *)parent_data);
> > +    trace("parent_data (%p) -> %s\n", parent_data, parent_data ? (char *)parent_data : "(null)");
>
> This is sooo backwards.  You don't want to try and find all places where (null) may be printed.
> I remember seeing (null) in logs here and there, so you're telling us that turning on
> Wine logs in Solaris can randomly crash Wine because it crashes on printf("%s", NULL)?
>
> I'm very surprised. I thought Solaris was one of the first machines - decades ago - where I observed "(null)" for NULL.
> (Or is that really glibc only?)

It appears this was quite extensively debated on the OpenSolaris mailing 
lists:
http://osdir.com/ml/os.solaris.opensolaris.devel/2006-07/msg00026.html

That's just to say that no, Solaris (unlike SunOS 4) never allowed a 
NULL pointer argument to '%s' (not that we should reenact the debate 
here). One of the recommendations in that thread is to define something 
like this where needed:

#define SAFESTR(s)  ((s) ? (s) : "(null)")


The Single UNIX Specification does not say what should happen in this 
case. To me that means we should not depend on '%s' accepting NULL 
pointers. 
http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html



-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux

Bruno Haible was so kind to provide the following test run results:

glibc          SIGSEGV
MacOS X 10.5   (null)
FreeBSD 6.4    (null)
OpenBSD 4.9    (null)
AIX 7.1        empty
HP-UX 11.31    empty
IRIX 6.5       (null)
OSF/1 5.1      (null)
Solaris 10     SIGSEGV
Cygwin         (null)
mingw          (null)

for printf("%s", NULL)

Looks like the next Coccinelle job will be to flag potential NULL pointers
used in %s in logs, not the tests...

[Michael Stefaniuc]

Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> Bruno Haible was so kind to provide the following test run results:
>
> glibc          SIGSEGV
> MacOS X 10.5   (null)
> FreeBSD 6.4    (null)
> OpenBSD 4.9    (null)
> AIX 7.1        empty
> HP-UX 11.31    empty
> IRIX 6.5       (null)
> OSF/1 5.1      (null)
> Solaris 10     SIGSEGV
> Cygwin         (null)
> mingw          (null)
>
> for printf("%s", NULL)
>
> Looks like the next Coccinelle job will be to flag potential NULL pointers
> used in %s in logs, not the tests...
> Not easily done with coccinelle as it doesn't looks into strings; those
> are just string literal constants for it. Those could be processed in a
> embedded python rule but the whole logic would need to be implemented there.

bye
	michael

[Henri Verbeet]

On 31 August 2011 17:18,  <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
> Looks like the next Coccinelle job will be to flag potential NULL pointers
> used in %s in logs, not the tests...

If it's something we get from the application, it should be using the
debugstr_*() functions. Wouldn't be a bad thing to check though.

[David Laight]

On Wed, Aug 31, 2011 at 05:18:57PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> Bruno Haible was so kind to provide the following test run results:
>
> glibc          SIGSEGV
> MacOS X 10.5   (null)
> FreeBSD 6.4    (null)
> OpenBSD 4.9    (null)
> AIX 7.1        empty
> HP-UX 11.31    empty
> IRIX 6.5       (null)
> OSF/1 5.1      (null)
> Solaris 10     SIGSEGV
> Cygwin         (null)
> mingw          (null)
>
> for printf("%s", NULL)

Some of the systems will have address zero valid and just read from
that address. Some will generate a non zero length string.
IIRC some very old OS (think vax and pdp11) arranged for address
zero to contain zero (possibly as part of the program header) so
that 'if (x && *x)' could be shortened to 'if (*x)'.
Allowing address zero be mapped (eg by mmap()) is a bad idea
as a kernel 'call through NULL ptr' can be used to escalate
privs.

	David

-- 
David Laight: david(a)l8s.co.uk