lib1537.c : check ptr against NULL before dereferencing it

[kokke]

I did this

Hi guys,

I am testing a homemade static analysis tool on a few code bases.
I checked out your master-branch and ran my tool and fell over this curiosity, which I think is indicative of a bug.

From tests/libtest/lib1537.c : 49-51

49  ptr = curl_escape((char *)a, asize);
50  printf("%s\n", ptr);
           ^^^^^^^^^^^  'ptr' gets dereferenced here, before the NULL-check
51  if(!ptr) {
52    res = TEST_ERR_MAJOR_BAD;
53    goto test_cleanup;
54  }

[gvanem]

What is wrong with printing a (null)?

[kokke]

@gvanem AFAIK not all implementations of printf output (null) given printf("%s", 0).

As far as I am aware, it is undefined behavior (not even just implementation-defined). See e.g. https://trust-in-soft.com/blog/2019/07/09/printing-a-null-pointer-with-s-is-undefined-behavior/

EDIT:

From https://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html

If you accidentally pass a null pointer as the argument for a ‘%s’ conversion, the GNU C Library prints it as ‘(null)’. We think this is more useful than crashing. But it’s not good practice to pass a null argument intentionally.

That was my rationale. Some implementations of printf would crash during test instead of giving a nice error-message 🤷‍♂️

[bagder]

But

1. we don't use those implementations
2. we can even test this: ./runtests.pl -t 1537

[kokke]

Then it seem the issue is non-problematic for you. Thanks for quick response :)

[jay]

1. we don't use those implementations

https://stackoverflow.com/questions/11589342/what-is-the-behavior-of-printing-null-with-printfs-s-specifier

try it

[bagder]

@jay what do you mean? Are you suggesting we build without using our own implementation at times?

[kokke]

@bagder is right that many printf implementations work around this problem (because it commonly occurs in code) but it is technically undefined behavior.

If you dont care much about UB in test code, that is understandable as well.

[bagder]

If we use our printf() implementation where we deal with this perfectly fine (to my knowledge). How can that be UB?

[kokke]

@bagder do you use your own printf implementation and not the built-in from cstdlib? If so there is no UB and the issue should be closed. The standard specifies UB for the printf-implementation from the standard library.

My tool thinks all calls to printf invoke the standard-implementation. That is often a sound assumption; but apologies for wasting time and energy if that is not the case here :)

[jay]

@jay what do you mean? Are you suggesting we build without using our own implementation at times?

I forgot about that, withdrawn!