On 09/08/2016 01:21 PM, Jeff Law wrote:
On 08/24/2016 10:40 AM, Martin Sebor wrote:
On 08/23/2016 05:00 PM, Joseph Myers wrote:
Some observations:
* Does -fprintf-return-value allow for the possibility of snprintf
failing
because of a memory allocation failure and so returning -1 when GCC
computed bounds on what it could return if successful?
No. I recall having seen Glibc fail with ENOMEM years ago when
formatting a floating point number to a very large precision but
I haven't seen any implementation fail. I haven't yet looked to
see if the Glibc failure can still happen. My reading of C and
POSIX is that snprintf is only allowed to fail due to an encoding
error, not because it runs out of memory, so such a failure would
seem like a bug.
At the same time, the cause of the failure doesn't really matter.
If the function could fail, unless GCC could determine the failure
at compile time and avoid the optimization, the transformation
wouldn't be guaranteed to be safe. It might be something to
consider and possibly accommodate in the implementation. It's
one of the reasons why I want to expose the optimization to
more code before enabling it.
I also haven't yet thought about how to deal with it but if it
is a possibility we want to allow for then maybe a target hook
for libc implementers to set to indicate whether sprintf can fail
and when would work. Libc implementations that can fail under
any conditions (whether allowed by the standard or not) would
need to disable (or not enable, depending on the default) the
optimization. I'm certainly open to other ideas.
So what are the implications for the optimization part of this patch?
By coincidence I've just posted an updated patch that handles this
situation by avoiding the optimization (and issuing a warning pointing
out that a directive produced more that 4,095 bytes worth of output).
Ditto for INT_MAX.
Martin
