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

Hi, Ken wrote: > > 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? > >

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

>> It's nice, but it might do the formatting work twice, > >This is not the sort of micro-optimization that anyone should be worried about. Yeah, I mean ... have you looked at the networking code? I'm sure if you're using the encryption that data is copied at least four times. Part of me just

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

> On Oct 29, 2016, at 3:58 PM, Ralph Corderoy wrote: > >> i use asprintf() for this kind of thing. > > It's nice, but it might do the formatting work twice, This is not the sort of micro-optimization that anyone should be worried about.

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

Hi. Damn it's late... Ralph Corderoy wrote: |> Therefore i think a function like the Linux strscpy() | |That was a new one to me. I found it, https://manned.org/strscpy.9 |It's defined in the Linux kernel. | |ssize_t strscpy(char * dest, const char * src,

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

Ralph Corderoy wrote: > They don't need to be checked because they're only used in those cases > where truncation, but still NUL-terminated, is valid. Kind of like when > `%.42s' is used in a lexer error message in case the token is runaway, > or 'cut -c 42'. Ken's saying that some of them are

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

Hi Paul, > > What if benign truncations were trunccpy(), instead of the strncpy > > dance where the reader is unsure if it's benign or not > > as long as every trunccpy() result is checked, so that if truncation > does occur there is a different code path following the call They don't need to be

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

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()

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

>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

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

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

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

Hi Ken, > >strncpy(sm_reply.text, str, sizeof(sm_reply.text)); > >sm_reply.text[sizeof(sm_reply.text) - 1] = '\0'; > > If this is what I think it is ... you know, I think this truncation is > benign. Could be. I just picked one at random to show a typical call-site pattern. -- Cheers,

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

>strncpy(sm_reply.text, str, sizeof(sm_reply.text)); >sm_reply.text[sizeof(sm_reply.text) - 1] = '\0'; If this is what I think it is ... you know, I think this truncation is benign. There are a number of cases where we are getting a error message from, say, an SMTP server and display it

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

Hi Paul, > > 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? > > replacing overrun with truncation is not a big enough improvement to > justify touching the code at all. I'm targetting the

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

Hi Steffen, > Therefore i think a function like the Linux strscpy() That was a new one to me. I found it, https://manned.org/strscpy.9 It's defined in the Linux kernel. ssize_t strscpy(char * dest, const char * src, size_t count); Does nothing if count is zero. Otherwise, it's dest's

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

Steffen Nurpmeso wrote: > Paul Vixie wrote: > |... > > 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

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

Paul Vixie 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

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

> On Oct 24, 2016, at 2:56 PM, Ken Hornstein wrote: > > I think just calling abort() is lousy behavior in general. Versus writing broken code? Handing back unpredictable behaviour to the end-user is a complete abdication of responsibility.

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

>> My concern there is our release cycles have been long > >What needs to get done before 1.7 gets sent off to make its fortune? >Is that soon enough that this could hold off? Um, good question. Some things for 1.7 have not quite been resolved. >> and I'd hate to have code that barfs on emails

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

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

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

Todd C. Miller wrote: > On Mon, 24 Oct 2016 16:40:36 -0400, valdis.kletni...@vt.edu wrote: > >> In other words - if the source string doesn't fit, it will create >> a non-NULL-terminated destination string for you. Repeat that, >> slowly, until it sinks in. > > It says nothing of the sort,

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

Hi Ken, > Although ... crud, I take your point that a small change is a lot > easier than a big change. Yes, as soon as a free() is needed then there's tracking the paths that exit the function, where the pointer gets copied to, etc. GC anyone? :-) > My concern there is our release cycles have

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

>Agreed. But crapping out breaks the silence so that area can be worked >on. I think just calling abort() is lousy behavior in general. But maybe there's a middle ground; a lot of these cases are just because we didn't want to allocate a dynamic buffer. Maybe we should start using asprintf() a

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

Hi David, I hope this strncpy thread doesn't run on for ever and anon. It's delaying my brace-style email. > > I dunno, I think we'd need to think carefully if a particular use of > > strncpy() really warrants an abort vs a truncate. I mean, just > > crapping out on a really long line that

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

On Mon, 24 Oct 2016 22:10:46 +0100, Ralph Corderoy wrote: > Yes, asprintf(3) is very handy. Unfortunately, it's not standardised; C > nor POSIX. And rolling your own version around vsnprintf(3) can mean > doing the formatting twice; the first time to get the length. You've > then a malloc'd

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

Hi Todd, > Paul Vixie wrote: > > Copy or die, as the default behavior. malloc! Or death! > Both snprintf() and strlcpy() make it fairly easy to detect whe the > buffer was too small, which is more than I can say for strncpy(). It > is up to the programmer to actually check the return value.

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

On Mon, 24 Oct 2016 16:40:36 -0400, valdis.kletni...@vt.edu wrote: > In other words - if the source string doesn't fit, it will create > a non-NULL-terminated destination string for you. Repeat that, > slowly, until it sinks in. It says nothing of the sort, please re-read the manual. The

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

On Mon, 24 Oct 2016 19:59:10 -, P Vixie wrote: > I don't know what gcc or clang command line option to use to require this. If you declare the function with gcc's warn_unused_result attribute the compiler will warn when you don't check the result. For example: size_t strlcpy(char *dst,

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

On Mon, 24 Oct 2016 13:08:22 -0600, "Anthony J. Bentley" said: > P Vixie writes: > > Strlcpy is completely bogus. > > What's silent about strlcpy? Just check the return value against the size > of the buffer. He didn't say it was silent. He said it was bogus. >From the manpage:

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

On October 24, 2016 9:08:22 PM GMT+02:00, "Anthony J. Bentley" wrote: >P Vixie writes: >> Strlcpy is completely bogus. > >What's silent about strlcpy? Just check the return value against the >size >of the buffer. I don't know what gcc or clang command line option to use

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

P Vixie writes: > > > On October 24, 2016 6:37:16 PM GMT+02:00, Ken Hornstein wrot > e: > > >I dunno, I think we'd need to think carefully if a particular use of > >strncpy() really warrants an abort vs a truncate. I mean, just > >crapping > >out on a really long line that

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

On overflow, the string should be zero filled, or abort() should be called. Leaving a half useful result creates no incentive to check the return value. On October 24, 2016 9:11:09 PM GMT+02:00, "Todd C. Miller" wrote: >On Mon, 24 Oct 2016 18:59:36 -, P Vixie

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

On October 24, 2016 6:37:16 PM GMT+02:00, Ken Hornstein wrote: >I dunno, I think we'd need to think carefully if a particular use of >strncpy() really warrants an abort vs a truncate. I mean, just >crapping >out on a really long line that other MUAs handle just fine seems

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

Ken wrote: > I dunno, I think we'd need to think carefully if a particular use of > strncpy() really warrants an abort vs a truncate. I mean, just crapping > out on a really long line that other MUAs handle just fine seems rather > unfriendly to me. What do others think? I'm not a fan of

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

Hi Ken, > You know, somehow I had missed all of these years that strncpy() pads > out the rest of the buffer, which is certainly not ideal! Yes, I keep forgetting it and rediscovering. :-) > I can only say that on my Linux systems, I don't have strlcpy() or > -lbsd. Here it's provided by

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

>This leaves s NUL terminated, but possibly silently truncated. Also, if >addr is a lot shorter than BUFSIZ, 8KiB here, then strncpy NULs out all >the rest of the 8KiB past the end of the string's terminator NUL. I'd >think that's not needed by most of the callers, though it's difficult to >know