Am 14.03.2014 20:33, schrieb Derek Martin:
> On Wed, Mar 12, 2014 at 07:36:24PM -0700, Claus Assmann wrote:
>> On Thu, Mar 13, 2014, Moritz Barsnick wrote:
>>
>>> "Release early, release often." ;-)
>>> (Less than six months this time, instead of three years.)
>>
>> Thanks to a buffer overflow...
>>
>> It would have been much better if that didn't happen.
>> Hmm, maybe it's finally time to get rid of strcat(), strcpy(), etc?
>
> Consider the following short program:
>
> #include <string.h>
> #include <stdio.h>
> int main(int argc, char **argv)
> {
> char a[3] = "abc";
> char b[] = "fooliciouslylongstringamabob";
> char c[] = "foo";
> int s,t,max;
>
> /* Compare the full string, i.e. whichever is larger */
> s = strlen(a);
> t = strlen(b);
> max = s >= t ? s : t;
> if (!strncmp(a, b, max)) printf("a (%s) and b (%s) are equal\n", a, b);
> else printf("a (%s) and b (%s) are not equal\n", a, b);
>
> /* Compare the minimum, so we don't overrun */
> s = strlen(c);
> t = strlen(b);
> max = s <= t ? s : t;
> if (!strncmp(c, b, max)) printf("c (%s) and b (%s) are equal\n", c, b);
> else printf("c (%s) and b (%s) are not equal\n", c, b);
>
> return 0;
> }
>
>
> This program makes use of only "safe" string functions, yet it has two
> problems, including a buffer overrun, due to a programming error in
> the initialization of a, and an incorrect result due to an incorrect
> attempt to skirt a fundamental problem with the way that strings work
> in C. It may or may not crash, depending on your architecture and how
> the bits of memory happen to be aligned on your machine.
I figured that the practical result depends on the compiler. clang on
FreeBSD 9.2 amd64 silently fixes up the b0rked initialization, gcc does
not. Neither complains, though, because the initialization is legal,
and the strncmp() inconsistency shown might be intentional, too. This
is an artificial example anyways and not so useful.
Every project will have to decide when and what way to go, and if you
want to change policies in mid-flight. (Or mid-crawl, for mutt.) In
many cases it might pay off to write a replacement for string.h, but
when you go that route, you might as well consider using a decent
programming language, rather than abusing C for application programming.
Which is cumbersome, error-prone, and a lot of typing.
I'm not advocating any particular language now -- although there are
obvious choices -- that ship better string support in either the
standard library, or the language itself.
> Any function that deals with memory manipulation (virtually all of
> them) can be dangerous if you use it wrong. If you look at the code
> where the "non-safe" functions are used, you'll see that in general
> care is taken to make sure there is an accounting of bounds.
Even if you have a managed environment with managed strings, you
interface with the system and can get it wrong, or you get integer
bounds wrong even if your strings are pampered up, there's always
opportunity for disaster.
