undefined references since newlib-3.2.0

[Keith Packard]

Josef Wolf <jw@raven.inka.de> writes:

> I don't really understand this. The classical way to return error from
> functions returning a pointer is to return NULL. One has to make sure not to
> leak, of course. Which return values would be needed beyond NULL?

The issue is that you need to reflect the allocation error all the way
up to the initial libc entry point, and you need to use a defined error
return value at that point, preferably one which indicates that the
library had an internal allocation failure.

Here are some affected libc functions which don't return a pointer and
which have no error indication of any kind:

        atof
        atoff

These are defined to just return strtod/strtof, so they continue to
inherit whatever those functions do. Which is now:

These have errnos defined, but those do not include ENOMEM:

        strtod
        strtof
        strtold
        wcstod
        wcstold
        strtodg

These now return infinity and set errno to ERANGE on allocation
failure. (not ideal, but the options are limited)

Here are some which do return a pointer, but do not document any errors:

        ecvt
        fcvt
        gcvt
        ecvtbuf
        fcvtbuf
        gcvtbuf

These now can return NULL on allocation failure. They do not set errno.

And here's a list of functions which I feel reasonable applications
should not expect an allocation error from:

        sprintf
        snprintf
        sscanf
        
These return EOF on allocation failure.

I wasn't too concerned with the exact semantics as there are no good
answers when libc uses malloc in these functions, so once I had
eliminated the internal aborts, I moved on to adding the ryu conversion
code to tinystdio to eliminate allocation in that path entirely.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20200613/86f5ea7d/attachment.sig>