This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vfprintf typing problem


On 04/01/2012 10:20 PM, David Miller wrote:

> The printf parser interface has no mechanism to signal errors,
> therfore I've taken the policy to skip constructs in the
> format string which have overflows.

That sounds awkward.  How about if we add a mechanism to
signal errors, as follows?  Reserve (size_t) -1 as a value that
says there was overflow in the format.  Then,
parse_printf_format can return (size_t) -1 if a string
specifies an impossibly large value before '$'.
We can mention this as part of the parse_printf_format API.

To implement this, we can have a function called 'read_size'
that acts like read_int, except it returns size_t rather than
'int', and it returns (size_t) -1 on overflow.

All the functions that currently invoke read_int, can be modified
to invoke read_size instead.  If the result exceeds INT_MAX, then
vfprintf can fail with errno == EOVERFLOW.  This idea assumes that
INT_MAX < (size_t) -1, but that's true on all hosts that glibc
is ported to.

We can then remove read_int.

Sorry if I seem to keep making more suggestions, but we do seem
to keep finding more related bugs as we unravel this....

> +		__set_errno (ERANGE);

This should be EOVERFLOW, no?  Similarly for the other
uses of ERANGE.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]