snprintf broken in Borland?

[Old Wolf]

In the documentation with BDS2006, snprintf is specified as
not 0-terminating the string, if it matches or exceeds the
buffer size. (I tested this too, and the function does indeed
behave this way).

This is at odds with the C standard, which defines snprintf
as always terminating the buffer.

Is this going to be fixed at some point, or do I need to put
hacks in all the standard code that I want to compile with
Borland?

[David Dean [CodeGear]]

Post by Old Wolf
In the documentation with BDS2006, snprintf is specified as
not 0-terminating the string, if it matches or exceeds the
buffer size. (I tested this too, and the function does indeed
behave this way).
This is at odds with the C standard, which defines snprintf
as always terminating the buffer.

Please enter this into QC.

[Remy Lebeau (TeamB)]

Post by Old Wolf
Is this going to be fixed at some point, or do I need to put
hacks in all the standard code that I want to compile with
Borland?

Borland implemented snprintf() back in BCB4 before it was standardized in
C99. I doubt they can change it without breaking existing code. Besides,
Borland is not the only party who implemented snprintf() that way. As of a
few years ago, anyway, MinGW and VC++ also implemented snprintf() the same
way. I don't know if they have been updated yet.

There are third-party implementations of snprintf() that conform to the C99
rules, for example:

http://www.ijs.si/software/snprintf/


Gambit

[Chris Uzdavinis (TeamB)]

Post by Old Wolf
In the documentation with BDS2006, snprintf is specified as
not 0-terminating the string, if it matches or exceeds the
buffer size. (I tested this too, and the function does indeed
behave this way).
This is at odds with the C standard, which defines snprintf
as always terminating the buffer.
Is this going to be fixed at some point, or do I need to put
hacks in all the standard code that I want to compile with
Borland?

C++ is defined in terms of C89, not C99. The "old" specification for
snprintf was to write all the bytes into the buffer, then fill all
remaining bytes with nulls. (If there was no remaining space, then
the buffer went without a trailing null.) The surprise to many is
that when the buffer is larger than the text being written, the whole
buffer is filled with nulls, which can be slow if clearing out the
tail of the buffer isn't necessary.

For what it's worth, g++ operates exactly the same way.

[Old Wolf]

Post by Chris Uzdavinis (TeamB)

Post by Old Wolf
In the documentation with BDS2006, snprintf is specified as
not 0-terminating the string, if it matches or exceeds the
buffer size. (I tested this too, and the function does indeed
behave this way).
This is at odds with the C standard, which defines snprintf
as always terminating the buffer.
Is this going to be fixed at some point, or do I need to put
hacks in all the standard code that I want to compile with
Borland?

C++ is defined in terms of C89, not C99.

I'm talking about C. Of course, as you say, Borland does not
claim C99 compliance for its C compiler, so it's entitled to
continue with its current implementation of snprintf.

Post by Chris Uzdavinis (TeamB)
The "old" specification for snprintf was to write all the
bytes into the buffer, then fill all remaining bytes with
nulls.
For what it's worth, g++ operates exactly the same way.

I just tested with g++ 3.4.1, and it behaves according
to the C99 snprintf.