Mailing List Archive

voting...
Voting +0 Sorry, I wasn't paying full attention. Re-reading:

http://www.hyperreal.com/httpd/voting.html#patchvote

I see that +0 is only a valid offer for 'actions', patches
specifically being covered by a different ruling on what
votes really mean. So I get to choose +1 if I've:

1.read the patch header to see what problem it addresses
2.successfully patched it into CURRENT
3.observed no bad side-effects resulting from the patch.

or I can choose -1:

-1 is a veto on the patch. All vetos must come with an
explanation of why the veto is appropriate. A veto with no
explanation is void.

Well, let me see.

1) I read the header and it's adding a functional
enhancement, not correcting a bug. Hadn't noticed that
either, first time round. It calls sprintf and writes out
a 'long' using a %d, instead of a %ld. Does this matter?
2) Yeah, it patches clean.
3) Nothing explodes when I use the patch. (How do
I test if printing a long using %d is giving
erronious output?!)

Sooo, I guess it's gunna have to be -1. Merely on account of it
being a functional enhancement and not a straight bug fix. Sorry.

Inidentally, theres nothing to stop you running your own set of
patches (functional enhancements, whatever) on top of 0.8.14. I
know many of us are doing this already.

Ho hum.

Ay.
Re: voting... [ In reply to ]
>
>
> Voting +0 Sorry, I wasn't paying full attention. Re-reading:
>
> http://www.hyperreal.com/httpd/voting.html#patchvote
>
> I see that +0 is only a valid offer for 'actions', patches
> specifically being covered by a different ruling on what
> votes really mean. So I get to choose +1 if I've:
>
> 1.read the patch header to see what problem it addresses
> 2.successfully patched it into CURRENT
> 3.observed no bad side-effects resulting from the patch.
>
> or I can choose -1:
>
> -1 is a veto on the patch. All vetos must come with an
> explanation of why the veto is appropriate. A veto with no
> explanation is void.
>
> Well, let me see.
>
> 1) I read the header and it's adding a functional
> enhancement, not correcting a bug. Hadn't noticed that
> either, first time round. It calls sprintf and writes out
> a 'long' using a %d, instead of a %ld. Does this matter?

It's wrong, so it matters. I don't think that the fact it adds a functional
enhancement matters.

> 2) Yeah, it patches clean.
> 3) Nothing explodes when I use the patch. (How do
> I test if printing a long using %d is giving
> erronious output?!)

It's only a problem when sizeof(long) != sizeof(int). You can test by assigning
a value greater than INT_MAX (not possible when sizeof(long) == sizeof(int)).

>
> Sooo, I guess it's gunna have to be -1. Merely on account of it
> being a functional enhancement and not a straight bug fix. Sorry.

I assume you are talking about 01a?

>
> Inidentally, theres nothing to stop you running your own set of
> patches (functional enhancements, whatever) on top of 0.8.14. I
> know many of us are doing this already.
>
> Ho hum.
>
> Ay.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk (preferred)
A.L. Digital Ltd, benl@fear.demon.co.uk (backup)
London, England.

[.Note for the paranoid: "fear" as in "Fear and Loathing
in Las Vegas", "demon" as in Demon Internet Services, a
commercial Internet access provider.]
Re: voting... [ In reply to ]
> It's wrong, so it matters. I don't think that the fact it adds a functional
> enhancement matters.

We're pulling patches that don't specifically fix something.
eg, the two I submitted originally got pulled cuz they added something
new, rather than fixed something that was broken. While we're working
towards a stable release for Apache 1.0 I understand that the idea is
to be strict and just fix stuf that's obviously broken.

You're right though, the idea of a %T in the LogFormat is innocuous
enough.

> > Sooo, I guess it's gunna have to be -1. Merely on account of it
> > being a functional enhancement and not a straight bug fix. Sorry.
>
> I assume you are talking about 01a?

Yes, I'm voting -1 on patch 01a.

> Ben Laurie Phone: +44 (181) 994 6435

Ay.
Re: voting... [ In reply to ]
> > Well, let me see.
> >
> > 1) I read the header and it's adding a functional
> > enhancement, not correcting a bug. Hadn't noticed that
> > either, first time round. It calls sprintf and writes out
> > a 'long' using a %d, instead of a %ld. Does this matter?
>
> It's wrong, so it matters. I don't think that the fact it adds a functional
> enhancement matters.

Honest question...

Doesn't it matter that it only writes out 6 digits of the long?

sprintf (itstr, "%ld.%.6d", t.tv_sec, t.tv_usec);
Re: voting... [ In reply to ]
>
> Well, let me see.
>
> 1) I read the header and it's adding a functional
> enhancement, not correcting a bug. Hadn't noticed that
> either, first time round. It calls sprintf and writes out
> a 'long' using a %d, instead of a %ld. Does this matter?

It should.. but I've noticed alot of those going on by in previous patches
This should be noted, and before we release 1.0 should be brought up as a
major cleanup patch. Right now we're trying to fix things.
> 2) Yeah, it patches clean.
> 3) Nothing explodes when I use the patch. (How do
> I test if printing a long using %d is giving
> erronious output?!)
>
> Sooo, I guess it's gunna have to be -1. Merely on account of it
> being a functional enhancement and not a straight bug fix. Sorry.

I don't agree with this. I don't see it as an addional feature. It's
something that was left out and is needed.

I'll record a -1 on 01a then. Is this correct?

<Aram>
--
Aram W. Mirzadeh http://www.qosina.com/~awm/
MIS Manager To err is human, to really screw up you need a computer.
Qosina Corporation http://www.qosina.com/
Email: awm@qosina.com awm@liii.com
Re: voting... [ In reply to ]
>
>
> > > Well, let me see.
> > >
> > > 1) I read the header and it's adding a functional
> > > enhancement, not correcting a bug. Hadn't noticed that
> > > either, first time round. It calls sprintf and writes out
> > > a 'long' using a %d, instead of a %ld. Does this matter?
> >
> > It's wrong, so it matters. I don't think that the fact it adds a functional
> > enhancement matters.
>
> Honest question...
>
> Doesn't it matter that it only writes out 6 digits of the long?
>
> sprintf (itstr, "%ld.%.6d", t.tv_sec, t.tv_usec);

%.6d means print at least 6 digits. This is what you want to do coz
t.tv_usec is microseconds (and never goes above 999999).

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk (preferred)
A.L. Digital Ltd, benl@fear.demon.co.uk (backup)
London, England.

[.Note for the paranoid: "fear" as in "Fear and Loathing
in Las Vegas", "demon" as in Demon Internet Services, a
commercial Internet access provider.]
Re: voting... [ In reply to ]
> > > > Well, let me see.
> > > >
> > > > 1) I read the header and it's adding a functional
> > > > enhancement, not correcting a bug. Hadn't noticed that
> > > > either, first time round. It calls sprintf and
> > > > writes out a 'long' using a %d, instead of a %ld.
> > > > Does this matter?
> > >
> > > It's wrong, so it matters. I don't think that the fact it adds a
> > > functional enhancement matters.
> >
> > Honest question...
> >
> > Doesn't it matter that it only writes out 6 digits of the long?
> >
> > sprintf (itstr, "%ld.%.6d", t.tv_sec, t.tv_usec);
>
> %.6d means print at least 6 digits. This is what you want to do coz
> t.tv_usec is microseconds (and never goes above 999999).
>
> Cheers,
>
> Ben.

Understood... What is it that is *wrong* with the sprintf() that
both you and Andrew pointed out?
Re: voting... [ In reply to ]
Randy, by way of Ben, by way of, oh, I forget...:
> > > sprintf (itstr, "%ld.%.6d", t.tv_sec, t.tv_usec);

> Understood... What is it that is *wrong* with the sprintf() that
> both you and Andrew pointed out?

Just that t.tv_usec is a 'long' so the sprintf string might more properly
be:

sprintf (itstr, "%ld.%.6ld", t.tv_sec, t.tv_usec);

Ay.