On Sunday 07 October 2007 13:15, Durk Talsma wrote:
Gentlemen,
Is there any reason not to use snprintf instead of sprintf? In order to
investigate possible memory corruption errors, I changed a few in SimGear,
and just found there are about another 250 of these in FlightGear. Unless
there's
* Durk Talsma -- Saturday 13 October 2007:
Well, since I got exactly zero responses to my question, I assume
that nobody objected. I committed a first stab of replacements in
SimGear (plib branch only; will do SimGear / OSG later).
Yeah, that's how one sneaks in controversial code! Just
* Melchior FRANZ -- Saturday 13 October 2007:
To my knowledge this is only needed for strncpy()/strncat(), but
not for snprintf(). The manpage seems a bit unclear about it,
but the code example is very clear.
Heh, no. The description is very clear, too: The functions
snprintf() and
On Saturday 13 October 2007 10:41, Melchior FRANZ wrote:
But there's one thing: one of my IMHO correct uses of snprintf()
was changed by someone to add a \0 byte at the last position of
the possible maximum length, which I found a bit annoying.
To my knowledge this is only needed for
Hi Melchior,
clear? There is no statement, if there is a \0 appended. And in fact, it
does not add a trailing \0 if the len parameter yields to a truncating
of the output. Of course the snprintf is not insecure, but the next
usage of the returned string. Therefore changing the sprintf to
Hi Durk,
Durk Talsma schrieb am 13.10.2007 11:44:
Just curious: Do you have an example of that? I did a grep for '\0'on the
source tree, but didn't come up with anything resembling such a use of
snprintf.
Maybe you need to grep for = 0.
But I think it should be easier to trace into snprintf
* Maik Justus -- Saturday 13 October 2007:
clear? There is no statement, if there is a \0 appended.
Whoops, you are right. I take everything back. OK, one has
to make sure the string is really terminated. Sorry.
m.
-
This
* Durk Talsma -- Saturday 13 October 2007:
But maybe I'm misunderstanding. :-)
Yes, you were misunderstanding. But this doesn't matter
anymore. I was double wrong: not only is a string *not*
guaranteed to be terminated, it's also *not* unclear in
the manpage. I just had to read it yet another
On 10/13/07, Durk Talsma [EMAIL PROTECTED] wrote:
Okay thanks. Looking at the man page again, I found that my safeguarding
code
is also not yet foolproof. According to the man page: If the return value
is
= max, truncation has occurred. My safeguarding code only checks for
max
though. Not
On 10/13/2007 11:14 AM, Curtis Olson wrote:
One thing to be a little careful about when coding is that it's easy to be
tempted to check for the same error condition in multiple places or at
multiple levels of the function call stack. That's not always optimal and
can lead to inconsistencies
* John Denker -- Saturday 13 October 2007:
why make a small improvement (snprintf) instead of a big
improvement (boost::format)?
Because the small improvement doesn't come with a new, painful
dependency, and sprintf() buffer overruns haven't exactly been
a big problem for fgfs in the past.
Gentlemen,
Is there any reason not to use snprintf instead of sprintf? In order to
investigate possible memory corruption errors, I changed a few in SimGear,
and just found there are about another 250 of these in FlightGear. Unless
there's a compelling reason, I'd like to change those as well,
12 matches
Mail list logo
