[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Steffen Nurpmeso
Subject: Re: [Nmh-workers] strncpy(3), die, die, die.
Date: Tue, 25 Oct 2016 02:44:44 +0200
User-agent: s-nail v14.9.0-pre1-107-g14b5a3a

Paul Vixie <address@hidden> wrote:
 |Ralph Corderoy wrote:
 |> Perhaps a complainant could be told of the secret $NMHNOBARF to stop
 |> TRUNCCPY from aborting?  Though it would still complain for the first N
 |> goes?
 |i think the moment that the state of the program becomes undefined, you
 |should abort.
 |malloc and asprintf helpfully return a useless value (NULL) if they
 |can't fit your result into a new heap blob.
 |snprintf, strncpy, and strlcpy do not.

I disagree, for the former and the latter.

 |the right thing to create on overflow is an empty string. if the caller
 |doesn't check the return value, they're going to wonder where that empty
 |string came from. this would teach callers to check return values.
 |returning the front half of the source string is bad. and while
 |returning it non-\0-terminated is worse, neither is acceptable.

But in effect i think it was always an error to do such
programming, because in multibyte environments truncating a string
isn't at all easy.

I think the former and latter of the above have the problem that
they return useless information: the size that would be necessary
to store the result in a non-truncated form.  If that information
would be collected regulary using the above functions i would
think that this is really wasteful software that gives a s..t on
the necessity of, e.g., atomic plants etc.  I think it is this
kind of mental direction that brings us all down.

I think the problem of strncpy() is that it doesn't NUL terminate
in the one, or zero-pads in the other case, which are both things
that i don't want.  Therefore i think a function like the Linux
strscpy() is something than can be used in, e.g., all US-ASCII
/ Deutsch / any single-byte locale servers or other programs,
where truncating a log entry etc. is to be performed (cheaply).

Otherwise i would claim that usage of such a function is likely an
error, and should be replaced by dynamic string objects.
E.g., i still have four use cases of strscpy() in the MUA
i maintain, and they are all wrong.

 |i once received a thousands-of-lines-long patch to bind8 to make it use
 |snprintf and strlcpy. i rejected it, and replaced every caller whose
 |starting conditions were not obvious from simple inspection with an "if"
 |statement that crashed out of the current operation if the resulting
 |string would not fit my assumptions.
 |replacing overrun with truncation is not a big enough improvement to
 |justify touching the code at all.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]