Re: strcpy versus strncpy

Aleph One (aleph1@DFW.NET)
Mon, 02 Mar 1998 22:46:32 -0600

On Tue, 3 Mar 1998, Morten Welinder wrote:

> 1. Different parts of a program can assign different meanings as
> a file name to the same string because they truncate at different
> lengths. (Since a program might pass on a file name to a sub-
> process, such different lengths need not be in the same program.)

I would consider this a bug in your program, just like using strcpy to
copy a large of a string into a smaller buffer. You should not be
truncating at different lengths. That why things like MAXPATHLEN and
MAXNAMLEN are defined.

> 2. Certain operations, such as prepending "./" or $PWD to a file
> name, can change the semantics of the name. Since prepending
> $PWD would typically be done to make a file name robust, this
> might come as a nasty surprise to some programs.

Again, I would consider this a bug in your program. If you are going to
canonicalize the file name, you must do it everywhere. You will only get
nasty surprises if you expect none.

> 3. What you think is plenty, others may call insufficient.
> Automatically generated file/function/variable/whatever names
> tend to be long. Why should a program fail to work with those.

This is too generic of a statement. Certain things have well defined
limits. Filename, pathnames, etc. There is no need to use dynamic memory
for them. If you do decide to use dynamicly allocated memory you must
allocate the possible maximum.

Certainly a good programmer will attempt write code to dynamicly adapt to
the environment it is run in but remember that, in the end, the computer's
resources are finite. The biggest problem of programs coded in the manner
you describe is that they crash and burn badly when they hit some resource
limit that they don't expect. They do not know how to fall back
gracefully.

For a good example on a resource attack go back to the archives and recall
how Wietse Venema found you could make qmail exhaust all the memory on a
computer remotely.

> This is, of course, my humble opinion,
>
> Morten
> terra@gnu.org

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01