Den 22-09-2011 23:19, Dave Shield skrev:
> But the variable that it's dividing is a float anyway, so does that matter?
> If it does, then perhaps it would be clearer to use '100.0' rather than '100.'
Ups, sorry, too much focus on code, ignoring the declarations.
/Niels
--
Niels Baggesen - @hom
er 22, 2011 2:39 PM
To: Niels Baggesen; Steve Friedl
Cc: Net-SNMP coders
Subject: Re: RFV: Disk calculation overflow
On 22 September 2011 22:21, Steve Friedl wrote:
> No, the variable it's dividing is long long - the missing dot was an
> error in posting the patch (though I did all the
On 22 September 2011 22:21, Steve Friedl wrote:
> No, the variable it's dividing is long long - the missing dot was an error
> in posting the patch (though I did all the testing with the right way).
Errr... no.
>From the 5.7.1.rc3 tarball:
static int _percent( unsigned long long value, unsigned
Sent: Thursday, September 22, 2011 2:20 PM
To: Niels Baggesen
Cc: Net-SNMP coders
Subject: Re: RFV: Disk calculation overflow
On 22 September 2011 22:05, Niels Baggesen
wrote:
> Den 22-09-2011 11:15, Dave Shield skrev:
>>
>> I've therefore applied a version of Steve&#
On 22 September 2011 22:05, Niels Baggesen wrote:
> Den 22-09-2011 11:15, Dave Shield skrev:
>>
>> I've therefore applied a version of Steve's patch (using local
>> float variables rather than casts) to the 5.6, 5.7 and master
>> code lines.
>
> It seems that you lost the period that made the 100
Den 22-09-2011 11:15, Dave Shield skrev:
> I've therefore applied a version of Steve's patch (using local
> float variables rather than casts) to the 5.6, 5.7 and master
> code lines.
It seems that you lost the period that made the 100 into a float :-(
/Niels
--
Niels Baggesen - @home - Århus -
> On Thu, 22 Sep 2011 10:15:22 +0100, Dave Shield
> said:
DS> I've slightly lost track of the number of votes for particular
DS> versions of this fix, but it seems clear that there is general
DS> consensus that this worth applying.
That particular version had 3, with your applying it a
On 21 September 2011 18:51, Wes Hardaker wrote:
> SF> Submitted; #3409692
>
> +1. Though I worry about compilers that don't properly convert some
> things to float when doing division, etc. If it were me I'd add a bunch
> of paranoid casts.
I've slightly lost track of the number of votes for p
> On Wed, 14 Sep 2011 17:11:26 -0700, "Steve Friedl"
> said:
SF> Submitted; #3409692
+1. Though I worry about compilers that don't properly convert some
things to float when doing division, etc. If it were me I'd add a bunch
of paranoid casts.
--
Wes Hardaker
Please mail all replies
> [is waiting for a patch]
Submitted; #3409692
Steve
-Original Message-
From: Wes Hardaker [mailto:harda...@users.sourceforge.net]
Sent: Wednesday, September 14, 2011 4:23 PM
To: Steve Friedl
Cc: 'Bart Van Assche'; 'Dave Shield'; 'Net-SNMP coders'
S
> On Fri, 2 Sep 2011 10:48:55 -0700, "Steve Friedl"
> said:
SF> There are other floats in that MIB, and I'd imagine that any compiler that
SF> could handle "unsigned long long" could deal with a float.
That's the really true part: with other floats already in the file, I
agree it's prob
> On Fri, 2 Sep 2011 18:53:57 +0200, Bart Van Assche
> said:
>> 1 is an arbitrary cut-off - it could be tweaked either way if
>> necessary,
>> but seemed a reasonable starting point.
>>
BVA> +1
Also +1.
--
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.
'd imagine that any compiler that
could handle "unsigned long long" could deal with a float.
Steve
From: Bart Van Assche [mailto:bvanass...@acm.org]
Sent: Friday, September 02, 2011 9:54 AM
To: Dave Shield
Cc: Net-SNMP coders
Subject: Re: RFV: Disk calculation overflow
On Fri
On Fri, Sep 2, 2011 at 11:42 AM, Dave Shield wrote:
> On 2 September 2011 06:56, Bart Van Assche wrote:
> > The loss of precision for small values of "value" and "total" can be
> > avoided by using the new formula only if these values are large.
>
>
> Something like:
>
> --- a/agent/mibgroup/ucd-
On 2 September 2011 06:56, Bart Van Assche wrote:
> The loss of precision for small values of "value" and "total" can be
> avoided by using the new formula only if these values are large.
Something like:
--- a/agent/mibgroup/ucd-snmp/disk_hw.c
+++ b/agent/mibgroup/ucd-snmp/disk_hw.c
@@ -248,7 +
On Thu, Sep 1, 2011 at 6:18 PM, Wes Hardaker
wrote:
>> On Thu, 1 Sep 2011 16:35:39 +0100, Dave Shield
>> said:
>
> DS> - return (int)( value * 100 / total );
> DS> + return (int)( value / (total/100) );
> DS> }
>
> DS> I'd like to see this included in 5.7.1
> DS> Votes please
>
On Thu, 2011-09-01 at 16:35 +0100, Dave Shield wrote:
> The hardware-based implementation of the UCD disk table
> (ucd-snmp/disk_hw) in v5.6 and above can suffer from
> arithmetic overflow when calculating percentage usage
> on large disks.
>The following simple patch should address this proble
> On Thu, 1 Sep 2011 16:35:39 +0100, Dave Shield
> said:
DS> -return (int)( value * 100 / total );
DS> +return (int)( value / (total/100) );
DS> }
DS> I'd like to see this included in 5.7.1
DS> Votes please
+1. Though it's subject to rounding errors that way. Either way y
Dave Shield wrote:
> The hardware-based implementation of the UCD disk table
> (ucd-snmp/disk_hw) in v5.6 and above can suffer from
> arithmetic overflow when calculating percentage usage
> on large disks.
>The following simple patch should address this problem:
+1
+Thomas
-
19 matches
Mail list logo
