[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snprintf and strlcpy
From: |
Bruno Haible |
Subject: |
Re: snprintf and strlcpy |
Date: |
Sat, 20 Sep 2008 13:33:39 +0200 |
User-agent: |
KMail/1.5.4 |
Marc Espie wrote:
> Even in GNU-style, even with careful coding, stuff like snprintf and strlcpy
> is useful.
>
> Sooner or later, you make a mistake. Granted, people find it eventually,
> but in the mean time, you have a security hole.
I disagree with this: I never use snprintf, because I know it would truncate
the resulting string - i.e. lead to bugs deep inside the program. Instead I
mostly use xasprintf(), which is like sprintf with automatic malloc() (the 'a')
and out-of-memory checking (the 'x'). With this, I have no security hole and
no truncation bug.
Probably the difference between our approaches is more in testing.
You find it acceptable to have bugs that are caused by string truncation, and
trust that the end users will report these bugs and that the buffer size will
then be increased by the developers.
I find it acceptable to have occasional memory corruption bugs during
development,
and trust that "valgrind" will report these bugs when I run "make check" with
valgrind enabled, before the release.
valgrind does report memory overruns. But it does not report truncation in
snprintf. Well, you could also override snprintf to report the truncation with
a message on stderr. Are people doing that?
Bruno
Re: libintl.h warnings with -Wundef, Ralf Wildenhues, 2008/09/20