I did a bit of investigation on the issue and came up with the following
patch. It uses the C99 macro SCNuMAX to get the appropriate scan
specifier for uintmax_t. How does that look?
Patch tested on debian sparc and debian i386 with kernel 2.4.2[56]
--- net-snmp-5.1.1.orig/agent/mibgroup/mibII/interfaces.c 2004-08-19
23:08:05.000000000 +0100
+++ net-snmp-5.1.1/agent/mibgroup/mibII/interfaces.c 2004-08-20
00:27:17.000000000 +0100
@@ -1512,14 +1512,19 @@
struct ifreq ifrq;
struct ifnet **ifnetaddr_ptr;
FILE *devin;
- unsigned long rec_pkt, rec_oct, rec_err, rec_drop;
- unsigned long snd_pkt, snd_oct, snd_err, snd_drop, coll;
+ uintmax_t rec_pkt, rec_oct, rec_err, rec_drop;
+ uintmax_t snd_pkt, snd_oct, snd_err, snd_drop, coll;
int i, fd;
conf_if_list *if_ptr;
const char *scan_line_2_2 =
- "%lu %lu %lu %lu %*lu %*lu %*lu %*lu %lu %lu %lu %lu %*lu %lu";
+ "%" SCNuMAX " %" SCNuMAX " %" SCNuMAX " %" SCNuMAX
+ " %*" SCNuMAX " %*" SCNuMAX " %*" SCNuMAX " %*" SCNuMAX
+ " %" SCNuMAX " %" SCNuMAX " %" SCNuMAX " %" SCNuMAX
+ " %*" SCNuMAX " %" SCNuMAX;
const char *scan_line_2_0 =
- "%lu %lu %*lu %*lu %*lu %lu %lu %*lu %*lu %lu";
+ "%" SCNuMAX " %" SCNuMAX " %*" SCNuMAX " %*" SCNuMAX
+ " %*" SCNuMAX " %" SCNuMAX " %" SCNuMAX " %*" SCNuMAX
+ " %*" SCNuMAX " %" SCNuMAX;
const char *scan_line_to_use;
struct timeval et; /* elapsed time */
Richard
On Tue, 2004-08-17 at 05:37, Robert Story wrote:
> On Wed, 04 Aug 2004 22:42:04 +0100 Richard wrote:
> RM> I'm using net-snmp on debian testing version 5.1.1-2 and have run into
> RM> the problem referenced below where 64 bit interface counters don't get
> RM> handled properly.
> RM>
> RM> http://sourceforge.net/mailarchive/message.php?msg_id=7090918
>
> [which contains this patch]
>
> --- net-snmp-5.0.9.org/agent/mibgroup/mibII/interfaces.c 2004-01-31
> 21:18:15.000000000 +0100
> +++ net-snmp-5.0.9/agent/mibgroup/mibII/interfaces.c 2004-01-31
> 01:02:54.000000000 +0100 @@ -1492,12 +1492,12 @@
> struct ifreq ifrq;
> struct ifnet **ifnetaddr_ptr;
> FILE *devin;
> - unsigned long rec_pkt, rec_oct, rec_err, rec_drop;
> - unsigned long snd_pkt, snd_oct, snd_err, snd_drop, coll;
> + unsigned long long rec_pkt, rec_oct, rec_err, rec_drop;
> + unsigned long long snd_pkt, snd_oct, snd_err, snd_drop, coll;
> int i, fd;
> conf_if_list *if_ptr;
> const char *scan_line_2_2 =
> - "%lu %lu %lu %lu %*lu %*lu %*lu %*lu %lu %lu %lu %lu %*lu %lu";
> + "%llu %llu %llu %llu %*llu %*llu %*llu %*llu %llu %llu %llu %llu
> %*llu %llu"; const char *scan_line_2_0 =
>
> RM> It doesn't seem that the patch mentioned in the message has been applied
> RM> and I'm wondering if this is an oversight or whether there are problems
> RM> with the patch. If there are problems with it I should have some time
> RM> early next week when I could have a go at making a proper fix.
>
> My only concern with the patch is whether or not it breaks any 32 bit
> platforms, and if it works for all the various 64 bit platforms. I don't
> believe that 'long long' is ANSI C, and that's traditionally our minimum
> standard.
>
> One alternative I've thought of would be to use 'uintmax_t' (defined in
> stdint.h) as the var type, which should work for 32 and 64 bit, but I'm not
> sure what would happen on a 32 bit system when scanf gets a 'llu' and a 32 bit
> variable. Haven't had time to investigate.
>
> Anyone else have any insights?
--
[EMAIL PROTECTED]
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
