Re: [Nmh-workers] strncpy(3), die, die, die.

[Paul Vixie]

Ralph Corderoy wrote:
> Hi Ken,
> 
>>> If this is what I think it is ... you know, I think this truncation
>>> is benign.
> 
> What if benign truncations were trunccpy(), instead of the strncpy dance
> where the reader is unsure if it's benign or not, and then abortcpy()
> could be the strncpy() replacement that aborts on truncation, with all
> the previously mentioned get-a-rounds?  Obviously, abortcpy is bad and
> should be sought and destroyed over time, but meanwhile it puts strncpy
> into one of two camps, with the remaining strncpy standing out as still
> needing analysis.

as long as every trunccpy() result is checked, so that if truncation
does occur there is a different code path following the call, i could
live with this approach. but i would prefer that the string be emptied
so that no semi-useful output was present -- as a way to encourage
programmers to be thoughtful about those alternate code paths.

i don't do a lot of C any more, but when i do, i use asprintf() for this
kind of thing. heaps are not as small or as fragile on the AMD64 as they
were on the PDP11. i'd rather have a memory leak, for which there are
tools to help me track it down, then truncation or overflow.

in fact, i wish there were a standard aasprintf() (that used alloca())
since that's the usual domain of my asprintf() outputs. but to make this
right, C would need a better type system, so that i couldn't return a
stack-allocated object or any pointers to same. that way lies madness,
so i am not seriously proposing it.

-- 
P Vixie