[Qemu-devel] Re: Re: [PATCH] security_20040618

[Charlie Gordon]

> Based on comments received thus far, including yours, I am reviewing
> that section of code (as I mentioned above), and will be releasing a new
> revision of the patch in a day or two.  I admit, I am not a perfect
> programmer.  I am merely trying to help out by fixing the tiny problems
> that are often missed by programmers that have more important things to
> worry about.  I appreciate it when people show me where I am wrong, but
> could you please keep your criticism a bit more constructive?

Sorry if I sounded a bit harsh, I'm sure every contribution is appreciated,
and your submitting patches is more helpful than my criticizing them...

I merely wanted to emphasize how broken strncpy is and how much more useful
pstrcpy is.

My suggestion on qemu_strdup is imho constructive :-)  and about the only
reason this is not completely off topic ;-)

But as far as strnpy is concerned, I *want* to be destructive : this C
library function is a mess, it doesn't do what most C programmers
believe.  It causes bugs, or blatant inefficiencies due to the inept null
padding on large buffers.
It is so unlikely that the precise behaviour of that horrible thing be what
is needed in any C program...
There are quite a few problems around uses of this function even in gnu
software or the linux kernel.

There are other candidates for libc functions every programmer should reject
disgruntedly : sprintf, gets, strtok, mktemp, tmpnam,
tempnam... or any of the C library functions duly tagged in the man pages as
never to be used
Similarly, extreme care is needed in do/while loops...

Charlie the C teaser.
---------------------
one of my favorite Q/As : what is wrong with : enum BOOL { FALSE=0,
TRUE=1 }; ?