Re: Minor issue/discussion: Behaviour of printf-family depends on optimization-flags [I.e. "(null)" - replacement]

[Eric Blake <eblake at redhat dot com>]

On 12/18/2015 05:48 AM, Markus Eisenmann wrote:

> In my opinion, a functional behaviour (as time-invariant black-box) should not differ,

Well-defined functional behavior must be time-invariant.  But undefined
behavior differs due to compiler options all the time.  This is no
different.  Expecting sane behavior from undefined input is a bug in
your program, not in newlib.  And at least this one is marked by a
configure-time option to newlib.

> Personally, I suggest to drop the #ifndef / #endif lines, with adopting the comment slightly.

No, because it would bloat the size of executables for those users who
specifically asked for newlib to be as compact as possible.

> Okay, the behaviour on passing a NULL string isn't defined,

and that's why we made it a configure-time decision - depending on how
you want to use newlib determines the behavior you get.

> Furthermore, the result of a function (expect stack-usage, timing/performance) should 
> be always as expected (or documented),

By definition, undefined behavior does NOT have to be documented.  But
yes, it wouldn't hurt to patch the documentation to mention that "as an
extension, if newlib was not optimized for size, then '"%p", NULL'
results in "(null)" rather than a crash".

It sounds like you think that changing the compiler options on YOUR .c
program will change the behavior offered by the libc.a that you link
against; that's not the case.  You choose at the time you compile newlib
into libc.a what behavior you want, and then that behavior will be a
constant for all uses of that libc.a, regardless of what further
compiler options you use on your .c file.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature