Attaching a new diff which includes both sets of patches
mentioned in this thread. As a bonus, includes two new
patch files to silence warnings about "deprecated conversion
from string constant to 'char*'".
--patrick
blackbox.diff
Description: Binary data
On 8/18/13, patrick keshishian wrote:
> Swaping accounts for sending diff in-line and not have
> gmail fuck it up.
>
> On Sat, Aug 17, 2013 at 20:03:32 -0600, Theo de Raadt wrote:
>> > > > So basically, this takes a long long value, and casts it to a long.
>> > >
>> > > Yes, but that's not the ent
On 8/18/13, Matthew Dempsky wrote:
> On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian
> wrote:
>> + bt::timeval::timeval(const ::timeval &t)
>> +- : tv_sec(t.tv_sec), tv_usec(t.tv_usec)
>> +-{ }
>> ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; }
>
> What's the point of these changes?
The bt::t
On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian wrote:
> + bt::timeval::timeval(const ::timeval &t)
> +- : tv_sec(t.tv_sec), tv_usec(t.tv_usec)
> +-{ }
> ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; }
What's the point of these changes?
On 8/18/13, Christian Weisgerber wrote:
> patrick keshishian wrote:
>
>> unsquandering ... (hopefully)
>
> I think most of this is pointless and misleading. The timeout value
> that is passed around is NOT a time_t. It's a time offset in the
> range 0 .. 3600*1000 milliseconds. Putting it into
> I think most of this is pointless and misleading. The timeout value
> that is passed around is NOT a time_t. It's a time offset in the
> range 0 .. 3600*1000 milliseconds. Putting it into a time_t is an
> abuse of that type.
However, typecasting a time_t to an int is almost always an error.
patrick keshishian wrote:
> unsquandering ... (hopefully)
I think most of this is pointless and misleading. The timeout value
that is passed around is NOT a time_t. It's a time offset in the
range 0 .. 3600*1000 milliseconds. Putting it into a time_t is an
abuse of that type.
> +--- lib/Time
Swaping accounts for sending diff in-line and not have
gmail fuck it up.
On Sat, Aug 17, 2013 at 20:03:32 -0600, Theo de Raadt wrote:
> > > > So basically, this takes a long long value, and casts it to a long.
> > >
> > > Yes, but that's not the entire story.
> > >
> > > the function declaration
> > > So basically, this takes a long long value, and casts it to a long.
> >
> > Yes, but that's not the entire story.
> >
> > the function declaration is: long nextTimeout(int resolution)
> >
> > So it would truncate anyway. But look at it closer. It
> > takes the value of timeval.tv_sec (your
> > So basically, this takes a long long value, and casts it to a long.
>
> Yes, but that's not the entire story.
>
> the function declaration is: long nextTimeout(int resolution)
>
> So it would truncate anyway. But look at it closer. It
> takes the value of timeval.tv_sec (your time_t / long l
On 8/17/13, Theo de Raadt wrote:
>> I see naddy@ already commited a fix for this from NetBSD. Thank
>> you!
>>
>> My patch fwiw was to cast second arg to std::max() to long.
>>
>> $OpenBSD$
>> --- src/Toolbar.cc.orig Sat Aug 17 16:58:14 2013
>> +++ src/Toolbar.cc Sat Aug 17 17:08:12 2013
>>
> I see naddy@ already commited a fix for this from NetBSD. Thank
> you!
>
> My patch fwiw was to cast second arg to std::max() to long.
>
> $OpenBSD$
> --- src/Toolbar.cc.orig Sat Aug 17 16:58:14 2013
> +++ src/Toolbar.ccSat Aug 17 17:08:12 2013
> @@ -44,7 +44,7 @@ long nextTimeout(int
Hi,
I see naddy@ already commited a fix for this from NetBSD. Thank
you!
My patch fwiw was to cast second arg to std::max() to long.
$OpenBSD$
--- src/Toolbar.cc.orig Sat Aug 17 16:58:14 2013
+++ src/Toolbar.cc Sat Aug 17 17:08:12 2013
@@ -44,7 +44,7 @@ long nextTimeout(int resolution)
{
13 matches
Mail list logo
