This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)


On 08/24/2016 12:54 PM, Florian Weimer wrote:
On 08/24/2016 06:40 PM, 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.

It can still happen, and not just for floating point.

#include <stdio.h>

int
main()
{
   printf("%0999999d\n", 5);
}

valgrind reports:

    total heap usage: 1 allocs, 1 frees, 1,000,031 bytes allocated

Thanks for the information (even though that's not the news I was
hoping for).  Is there a way to determine from the format string
whether the allocation will happen?  Does it just happen with
output beyond some length, for example?

Martin


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