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 > terraat_private Aleph One / aleph1at_private http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:43:42 PDT