On Thu, 07 Jun 2012 01:04:52 -, paul vixie said:
> or we could just say, link against some library that provides a
> reasonable snprintf that follows posix?
Give me a moment here, I'm still trying to wrap my brain around the
concepts that:
a) There are people managing to get work done on a s
Paul Vixie wrote:
> or we could just say, link against some library that provides a
> reasonable snprintf that follows posix?
Perhaps http://www.etalabs.net/musl/
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.o
On 6/6/2012 11:40 PM, Tom Lane wrote:
> ... [ some experimenting later ... ] What it appears to be doing is
> filling the buffer to the specified length and then returning -1
> anyway. Given your argument that there is no reason for it to fail, I
> suppose the quickest hack is to assume that -1 mea
On 6 June 2012 at 12:39, Ken Hornstein wrote:
> >The exit status of for, example, "sortm -version" or "scan -version"
> >is not zero. Shouldn't it be. It was in a very old version of nmh,
> >nmh-1.2-20070115cvs.
>
> AFAICT ... it's always been that way. We didn't have -version back in
> MH-6.8
>[ some experimenting later ... ] What it appears to be doing is filling
>the buffer to the specified length and then returning -1 anyway. Given
>your argument that there is no reason for it to fail, I suppose the
>quickest hack is to assume that -1 means the same as "buffer filled".
Be careful,
Ken Hornstein writes:
>> I haven't had time to check, but I suspect -1 is what it's giving.
>> I disagree with your reading of the standard though: -1 means failure,
>> and in a failure case there is not any specification about what went
>> into the buffer.
> I agree with that ... but why is it f
>I haven't had time to check, but I suspect -1 is what it's giving.
>I disagree with your reading of the standard though: -1 means failure,
>and in a failure case there is not any specification about what went
>into the buffer.
I agree with that ... but why is it failing? If the only reason it's
On 6/6/2012 9:26 PM, Tom Lane wrote:
> ...
> Hmm, should I be worried about the fact that I'm running a pretty
> recent BIND on this box? I've never seen anything that looked like
> snprintf related misbehavior ... regards, tom lane
i'm not sure what BIND9 does. but the later BIND4's and all BIND
paul vixie writes:
> On 6/6/2012 8:00 PM, Ken Hornstein wrote:
>> Our push recently (and by recently, I mean for 1.5) has been to set
>> POSIX as a minimum. We're not completely unreasonable about it,
>> but there are limits; we make that call on a case-by-case basis.
> ken, speak for yourself.
On 6/6/2012 8:00 PM, Ken Hornstein wrote:
> Our push recently (and by recently, I mean for 1.5) has been to set
> POSIX as a minimum. We're not completely unreasonable about it,
> but there are limits; we make that call on a case-by-case basis.
ken, speak for yourself. i am completely unreasonab
Ken Hornstein writes:
> I suspect if you check the return value of snprintf() in this case
> you'll find it's been set to -1. And in my reading of the standard
> it seems clear that it's supposed to write as many bytes as will
> fit in the buffer.
I haven't had time to check, but I suspect -1 is
>Well, this is an ancient HPUX box, and it most certainly isn't using
>glibc. I think that portable software shouldn't be assuming very much
>about what snprintf does when the string doesn't fit; it's only in
>rather recent editions of POSIX that that's nailed down, and even there
>it seems to be
Ken Hornstein writes:
>> So my conjecture is that on your systmes if
>> snprintf() cannot fit a value in the width specified then it simply
>> refuses to put anything in there. My reading of the specification
>> is that this is the correct behavior.
> Whoops, I meant to say this is INCORRECT beh
> >> It's been this way for 13 years, at least. Another few months
> >> won't hurt with something so minor. So I think it should be
> >> post-1.5.
> >
> > Sounds to me like that's the consensus. David, you want to do the
> > honors when you get a chance?
>
> Also, please ensure this gets a visi
>I'm all for post-1.5, unless it's going to be years from now.
>Is there a roadmap as to what comes out next?
Well ... no. I can't speak for anyone else, but I've just been making it
up as I go along. I have some vague plans in my head. Specifically what
I was thinking was for 1.6 was:
- Bette
On 2012-06-06, at 10:25 AM, Ken Hornstein wrote:
>> It's been this way for 13 years, at least. Another few
>> months won't hurt with something so minor. So I think it
>> should be post-1.5.
>
> Sounds to me like that's the consensus. David, you want to do the honors
> when you get a chance?
>> Okay, I'm convinced. The question them becomes ... is it a bug fix
>> that qualifies to get in for 1.5? Or should it be post-1.5?
>
>It's been this way for 13 years, at least. Another few
>months won't hurt with something so minor. So I think it
>should be post-1.5.
Sounds to me like that's
>So my conjecture is that on your systmes if
>snprintf() cannot fit a value in the width specified then it simply
>refuses to put anything in there. My reading of the specification
>is that this is the correct behavior.
Whoops, I meant to say this is INCORRECT behavior. But the more I look
at it
On Wed, 06 Jun 2012 13:04:04 -0400, Ken Hornstein wrote:
> >I agree that it should be 0.
>
> Okay, I'm convinced. The question them becomes ... is it a bug fix
> that qualifies to get in for 1.5? Or should it be post-1.5?
I'm all for post-1.5, unless it's going to be years from now.
Is there
Ken wrote:
> Okay, I'm convinced. The question them becomes ... is it a bug fix
> that qualifies to get in for 1.5? Or should it be post-1.5?
It's been this way for 13 years, at least. Another few
months won't hurt with something so minor. So I think it
should be post-1.5.
David
___
>(I forget the provenance of this thing, but it's likely a modified
>version of what exmh supplies.)
AFAICT exmh doesn't supply that, but I guess it doesn't matter.
>In addition to the -form argument, exmh
>sticks in a -width argument. That's always behaved as expected with nmh
>1.0.4, but somet
>I agree that it should be 0.
Okay, I'm convinced. The question them becomes ... is it a bug fix
that qualifies to get in for 1.5? Or should it be post-1.5?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/li
On 2012-06-06, at 9:39 AM, Ken Hornstein wrote:
> AFAICT ... it's always been that way. We didn't have -version back in
> MH-6.8.5, but at least as far as our sources go back (1999) -version has
> always exited with an exit code of 1.
>
> Should it? I dunno ... what do people think?
The curre
ken wrote:
> >The exit status of for, example, "sortm -version" or "scan -version"
> >is not zero. Shouldn't it be. It was in a very old version of nmh,
> >nmh-1.2-20070115cvs.
>
> AFAICT ... it's always been that way. We didn't have -version back in
> MH-6.8.5, but at least as far as our
>The exit status of for, example, "sortm -version" or "scan -version"
>is not zero. Shouldn't it be. It was in a very old version of nmh,
>nmh-1.2-20070115cvs.
AFAICT ... it's always been that way. We didn't have -version back in
MH-6.8.5, but at least as far as our sources go back (1999) -versio
Norm wrote:
> The exit status of for, example, "sortm -version" or
> "scan -version" is not zero. Shouldn't it be. It was in
> a very old version of nmh, nmh-1.2-20070115cvs.
I agree that it should be 0. I don't know why it's 1, but
that is consistent across all 48, give or take, nmh
programs.
I use scan with this scan form:
%5(msg)%<(cur)+%| %>%<{replied}-%|%<{encrypted}E%| %>%>\
%(date2local{date})\
%02(mon{date})/%02(mday{date}) %02(hour{date}):%02(min{date})\
%<{date} %|*%> \
%<(mymbox{from})=>%23(decode(friendly{to}))%|%25(decode(friendly{from}))%> \
%(decode{subject}) (%(putnum(s
Ken Hornstein writes:
>--- =_aa0
>Content-Type: text/plain; charset="us-ascii"
>Content-ID: <68350.1338484958.2@zoolander.internal>
>
>(My apologies if you get multiple copies of this; I tried to be too
>smart for my own good).
>
>Greetings all,
>
>I am pleased to announce that the thi
28 matches
Mail list logo
