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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers