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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
