On 8/5/24, Paul Eggert wrote:
If snprintf (buf, sizeof buf, ...) returns an integer I such that (0 <=
I < sizeof buf) then the snprintf worked, the contents of buf[0] through
buf[I] are valid, and buf[I] == '\0'. Otherwise snprintf didn't work and
buf's contents are indeterminate.
In practic
On Mon, 2024-08-05 at 14:26 -0700, Paul Eggert wrote:
> Good memory!
Just old :p :)
> GNU Make should either (a) not worry about porting to SunOS 4, (b)
> rewrite ar_member_touch to not use snprintf, or (c) import Gnulib's
> snprintf module which unfortunately is pretty heavyweight. I vote for
> From: Martin Dorey
> CC: "bug-make@gnu.org"
> Date: Mon, 5 Aug 2024 23:13:47 +
>
> "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no
> longer identical to _snprintf. The snprintf behavior is now C99 standard
> conformant. The difference is that if you run out
On 2024-08-05 16:13, Martin Dorey wrote:
"Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no longer
identical to _snprintf. The snprintf behavior is now C99 standard conformant. The
difference is that if you run out of buffer, snprintf null-terminates the end of the
b
>> all systems providing correct
>> sprintf() return values these days? ISTR that some C runtime
>> implementations didn't correctly return the formatted length.
> 7th Edition Unix sprintf returned char *
Perhaps the buffer is always big enough here. If not, though, then the more
recent diffe
On 2024-08-05 12:22, Paul Smith wrote:
On Mon, 2024-08-05 at 01:59 -0700, Paul Eggert wrote:
The first three patches are minor cleanups.
Is it the case that we can rely on all systems providing correct
sprintf() return values these days? ISTR that some C runtime
implementations didn't correct
On Mon, 2024-08-05 at 01:59 -0700, Paul Eggert wrote:
> The first three patches are minor cleanups.
Is it the case that we can rely on all systems providing correct
sprintf() return values these days? ISTR that some C runtime
implementations didn't correctly return the formatted length.
But mayb
While looking at GNU Make recently, I noticed an unlikely pointer
overflow, and also a couple of undesirable buffer truncations in the W32
code. Proposed patches attached. The first three patches are minor
cleanups. Patch 0004 fixes the pointer overflow, and patch 0005 fixes
the truncations.
