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.

[Nmh-workers] 1.7 release date

A couple of comments have come up about when to release 1.7. Given all the thrashing of string/buffer manipulation code that has taken place over the last week and a bit, I don't think we can even think about baking this code now for at least a couple of months. We have just hammered on the

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] Having configure Check for cc's -pedantic -ansi.

Ralph wrote: > I found the build on Mac OS X failed. build_nmh prompted `[n]' for TLS, > which I accepted with Enter. That stopped --with-tls getting to > ./configure; good. But configure defaults to yes, I think, Yes, it did. I just committed a change to do this: By default

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] Having configure Check for cc's -pedantic -ansi.

Ralph wrote: > Hi David, > > Worked well on a machine where I hadn't built it before, but was likely > to have some of the optional development packages installed. Yeah, the script doesn't check those dependencies in advance. The build doesn't take very long on modern machines so I think that's

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

Re: [Nmh-workers] Minor gripe about send man page

Ken Hornstein writes: >>But it isn't clear, at least to me, which of those things send does >>and which post does. As I said, this is a minor gripe. > >Man, Norm, it's been that way for approximately forever ... you're just >noticing now? :-) Until I had to write a postproc the

Re: [Nmh-workers] Having configure Check for cc's -pedantic -ansi.

Hi David, > Worked well on a machine where I hadn't built it before, but was > likely to have some of the optional development packages installed. The second time `sh build_nmh' is run the `git clone' fails because ./nmh exists and isn't empty. The user doesn't know that immediately though

Re: [Nmh-workers] Minor gripe about send man page

Hi Ken, > But to answer [Norm's] question ... the division of labor is kind of > like the division between show(1) and mhl(1); send(1) takes a message > and maybe does some minor processing on it (or splits it up), and then > passes the file off to post(8) to actually send it (post takes a >