Mail Archives: cygwin/2000/08/07/16:15:52
On Mon, Aug 07, 2000 at 08:25:52AM -0500, Doug Wyatt wrote:
>From: "Doug Wyatt" <dwyatt AT sunflower DOT com>
>To: cygwin AT sourceware DOT cygnus DOT com
>Date: Mon, 7 Aug 2000 08:25:52 -0500
>Subject: possible bug in snprintf() ?
>Reply-to: dwyatt AT sunflower DOT com
>Priority: normal
>
>Hi,
>
>I've run across differences in the behavior of snprintf() on
>Cygwin 1.1.4, with respect to RH6.2 or HP-UX (using either gcc
>or the HP ANSI cc). On the HP, the return value is -1 when the
>string exceeds 'size', while on Linux and Cygwin the return
>value is always the length of the string that is or would have
>been written (minus the NUL). That one doesn't really concern
>Cygwin.
>
> snprintf( char *target, size_t size, const char *format, ... )
>
>The difference about which I have a question is that on Linux
>and HP-UX, when the string exceeds 'size' then (size - 1) chars
>plus a NUL are written, but on Cygwin 'size' chars are written
>and a NUL is placed into target[size] - probably ill-advised
>if 'target' is only allocated 'size' bytes.
>
>Is the newlib version wrong? It appears to be in light of this
>excerpt from the RH6.2 snprintf man entry, also:
>
> Return value
> "
> "
> snprintf and vsnprintf do not write more than size bytes
> (including the trailing '\0'), and return -1 if the output was
> truncated due to this limit. (Thus until glibc 2.0.6. Since
> glibc 2.1 these functions follow the C99 standard and return the
> number of characters (excluding the trailing '\0') which would
> have been written to the final string if enough space had been
> available.)
>
>The problem arises in a configure file which wants (size - 1)
>bytes in 'target'.
>
>Is the newlib behavior a variant or a bug?
It sounds like a bug to me.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -