strlen deprecated ?!?

[Pete Becker]

The irony is killing me. Microsoft lecturing others about buffer overruns.

Besides, that still doesn't make it deprecated.

Nor does it make it undesirable. When I use fixed size buffers I design
my code so that overruns won't occur. I suppose if you have a bunch of
badly designed code you might want to use these things to retrofit some
additional checking, but that will usually be the wrong approach.

 

[Guest]

I don't understand this. How is an access violation a security risk?

I am not a security expert; but what I know is that, an access violation
would cause a core dump (the contents of the application's memory) that
might contain sensitive information like the previously entered passwords of
the previously logged-in users.

Ali

 

[Pete Becker]

I am not a security expert; but what I know is that, an access violation
would cause a core dump (the contents of the application's memory) that
might contain sensitive information like the previously entered passwords of
the previously logged-in users.

That's so twentieth century -- the idea that "security" refers to
keeping private data away from prying eyes. The modern, twenty-first
century idea of "security" is that it encompasses preventing anything
that an outside cracker might want to do through your browser, and that
includes denial-of-service attacks, i.e. causing an application to
crash. The fact that your application isn't accessible from the internet
is irrelevant: if it isn't "secure" it ain't right. So don't bother
formulating a robust design, just heed those warnings: strcat is the enemy!

 

[Attila Feher]

As always, the newer and superior C++ facilities should be used
instead of the old ones, however if you had to deal with a char *,
strlen() would be available (e.g. by using a C library).

It is not not deprecated in the standard (which is what matters here),
but is not also deprecated in VC++ that the OP mentioned.

And yet, if the pointer buffer does not contain the terminating zero
character:
Please say Hi! for me to the buffer overflow you meet on the way.

Making an strnlen function takes about 30 seconds if you do it slowly.

 

[Richard Herring]

And yet, if the pointer buffer does not contain the terminating zero
character:
Please say Hi! for me to the buffer overflow you meet on the way.

But if I don't own the buffer I'm given a pointer into, how am I
supposed to guess its size?

Making an strnlen function takes about 30 seconds if you do it slowly.

How long did you allow for testing? This kind of function is an ideal
candidate for out-by-1 errors - and if it's out by 1 the wrong way, you
will have both buffer overruns and a false confidence that they can't
occur.

 

[Ivan Vecerina]

And yet, if the pointer buffer does not contain the terminating zero
character:
Please say Hi! for me to the buffer overflow you meet on the way.

But most C string manipulation functions will zero-terminate
the string automatically.
I'd find it more constructive to replace strncpy (may not zero-end)
with strlcpy (always keep zero-termination) than to replace strlen
with strnlen.
(This said, neither approach will help with strings that embed NULL).

Making an strnlen function takes about 30 seconds if you do it slowly.

How is this relevant to the correct approach?
For some heap-allocated string implementations,
strnlen is just not practical...

Cheers,
Ivan