Re: Fix patch for SF bug 2833

2018-03-22 Thread Eric S. Raymond 
Bart Van Assche :
> I think that variable.magic is only needed if the old MIB registration API is
> used (register_mib() etc.). That API was deprecated more than ten years ago.
> I think that we should tell users to move away from that API rather than
> helping them with fixing the shortcomings of that API.

2833 should probably be maeked WONTFIX abd closed with that exolamation, then.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Bart Van Assche 

On 03/22/18 10:37, Eric S. Raymond wrote:

Bart Van Assche :

This patch changes a data structure in a public header file and hence breaks
the ABI. This is something we could do for Net-SNMP 5.8 since there has not
yet been any 5.8 release but it's something we can't do for older Net-SNMP
versions.


I withdraw the suggestion.

Procedurally, do you have an official queue of patches deferred to the next
major release, or a repository branch for them? Putting the patch there
would be a reasonable way to close 2833.


Is changing the size of variable.magic the best solution for bug #2833? 
I think that variable.magic is only needed if the old MIB registration 
API is used (register_mib() etc.). That API was deprecated more than ten 
years ago. I think that we should tell users to move away from that API 
rather than helping them with fixing the shortcomings of that API. From

include/net-snmp/net-snmp-config.h.in:

/* * NETSNMP_MARK_BEGIN_LEGACY_DEFINITIONS */
/*
 * existing definitions prior to Net-SNMP 5.4
 *
 * do not add anything new here
 *
 */

#ifndef NETSNMP_NO_LEGACY_DEFINITIONS
[ ... ]
#endif

An example of how to use the new API is available at 
http://net-snmp.sourceforge.net/wiki/index.php/TUT:mib2c_scalar.


Bart.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Bart Van Assche 

On 03/22/18 15:56, Keith Mendoza wrote:

Looking into using clang on Windows might be worth the effort to get
net-snmp code caught up to C99. Google Chrome now uses clang to
compile in Windows:
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html


We do not only need a compiler on Windows but also the Windows API 
header files, e.g. for building the winExtDLL module. Microsoft owns the 
copyright on the Windows API header files. Does clang for Windows 
include Windows header files? I think MinGW comes with a clean-room 
rewrite of the Windows header files to avoid copyright issues. See also

http://mingw.org/history.

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Keith Mendoza 
Looking into using clang on Windows might be worth the effort to get
net-snmp code caught up to C99. Google Chrome now uses clang to
compile in Windows:
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

Thanks,
Keith

-Original Message-
Subject: RE: C99 (was: Re: Fix patch for SF bug 2833)
Date: Thu, 22 Mar 2018 18:27:47 + (UTC)
From: Steve Friedl <st...@unixwiz.net>
To: e...@thyrsus.com, 'Bill Fenner' <fen...@gmail.com>
CC: 'Net-SNMP Coders' <net-snmp-coders@lists.sourceforge.net>


net-snmp is expected to build on Windows, which gpsd does not; it's not
clear how much this impacts compiler choice.

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com]
Sent: Thursday, March 22, 2018 10:32 AM
To: Bill Fenner <fen...@gmail.com>
Cc: Net-SNMP Coders <net-snmp-coders@lists.sourceforge.net>
Subject: C99 (was: Re: Fix patch for SF bug 2833)

Bill Fenner <fen...@gmail.com>:
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
>
> > On the other hand, I question whether the extra overhead is a real
> > issue in 2018.
>
>
> I have the same question, but know that I have no useful opinion here
> - my "embedded system" ships with 4 gigs minimum, but the project has
> more use cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99
constructs.

*This* is an issue about which I know something important that does not seem
to have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or portability
anywhere, I get a complaint right quick.  I've fielded dozens of these.
Maybe the weirdest one was due to actual signed chars on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from ancient
big iron in my codebase. Thought about my options, decided to move to
assuming C99 and SuSv2. I shipped a point release on this premise expecting
at least some minor pushback from some odd legacy environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one of the
time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero is
obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the
host API than snmpd does, so the test has been more stringent. GPSD has to
get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even
further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

RE: C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Steve Friedl 
net-snmp is expected to build on Windows, which gpsd does not; it's not
clear how much this impacts compiler choice.

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com] 
Sent: Thursday, March 22, 2018 10:32 AM
To: Bill Fenner <fen...@gmail.com>
Cc: Net-SNMP Coders <net-snmp-coders@lists.sourceforge.net>
Subject: C99 (was: Re: Fix patch for SF bug 2833)

Bill Fenner <fen...@gmail.com>:
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> 
> > On the other hand, I question whether the extra overhead is a real 
> > issue in 2018.
> 
> 
> I have the same question, but know that I have no useful opinion here 
> - my "embedded system" ships with 4 gigs minimum, but the project has 
> more use cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99
constructs.

*This* is an issue about which I know something important that does not seem
to have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or portability
anywhere, I get a complaint right quick.  I've fielded dozens of these.
Maybe the weirdest one was due to actual signed chars on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from ancient
big iron in my codebase. Thought about my options, decided to move to
assuming C99 and SuSv2. I shipped a point release on this premise expecting
at least some minor pushback from some odd legacy environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one of the
time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero is
obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the
host API than snmpd does, so the test has been more stringent. GPSD has to
get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even
further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Eric S. Raymond 
Bart Van Assche :
> This patch changes a data structure in a public header file and hence breaks
> the ABI. This is something we could do for Net-SNMP 5.8 since there has not
> yet been any 5.8 release but it's something we can't do for older Net-SNMP
> versions.

I withdraw the suggestion.

Procedurally, do you have an official queue of patches deferred to the next
major release, or a repository branch for them? Putting the patch there
would be a reasonable way to close 2833.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

C99 (was: Re: Fix patch for SF bug 2833)

2018-03-22 Thread Eric S. Raymond 
Bill Fenner :
> On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond  wrote:
> 
> > On the other hand, I question whether the extra overhead is a real
> > issue in 2018.
> 
> 
> I have the same question, but know that I have no useful opinion here - my
> "embedded system" ships with 4 gigs minimum, but the project has more use
> cases than mine.

Bart's objection about changing the public ABI is a showstopper and I
wihdraw the suggestion.

On the other hand...

>For example, the project did decide to back off from introducing c99 
>constructs.

*This* is an issue about which I know something important that does not seem to
have percolated into general knowledge yet.

I lead the GPSD project, a daemon for handling GPSes and other geolocation
sources.  It's deployed *everywhere* - smartphones, driverless cars, marine
navigation systems, main battle tanks, drones and UAVs, first-responder comm
gear, you name it.

If GPSD makes an assumption that breaks any Unix build chain or
portability anywhere, I get a complaint right quick.  I've fielded
dozens of these. Maybe the weirdest one was due to actual signed chars
on a 360 mainframe.

There came a point at which I got tired of seeing legacy ifdefs from
ancient big iron in my codebase. Thought about my options, decided to
move to assuming C99 and SuSv2. I shipped a point release on this
premise expecting at least some minor pushback from some odd legacy
environment.

I heard not a peep, and never have since.  And this was in 2009.

If that's not enough, since 2015 I have led the NTPsec project.  Based on
GPSD experience we made the same decision to assume a C99/SuSv2 base.
With no problems whatsoever except that on old versions of MacOS one
of the time primitives is broken.

That's how I learned that the standards people won.  Our traditional
twitchiness about tossing out any portability shim back to the year zero
is obsolete.

And bear in mind that GPSD/NTPsec probably exercises a wider swathe of
the host API than snmpd does, so the test has been more stringent. GPSD has
to get deep into odd corners of the tty driver and kernel PPS; NTPsec
gets even further into system clock handling.

I can say with confidence that assuming C99 is *very* safe in 2018.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Bart Van Assche 

On 03/21/18 19:43, Eric S. Raymond wrote:

From 54e79ba66327bdb54f97f457d76531f657ec546d Mon Sep 17 00:00:00 2001

From: "Eric S. Raymond" 
Date: Wed, 21 Mar 2018 22:22:29 -0400
Subject: [PATCH] include/net-snmp/agent/{snmp_vars.h,var_struct.h}: address SF
  bug 2833.


Are you familiar with "git send-email"? Using that command may be more 
convenient that copy/pasting patches into an e-mail.



diff --git a/include/net-snmp/agent/snmp_vars.h 
b/include/net-snmp/agent/snmp_vars.h
index bd27eeb..b2f2f8f 100644
--- a/include/net-snmp/agent/snmp_vars.h
+++ b/include/net-snmp/agent/snmp_vars.h
@@ -101,7 +101,7 @@ PERFORMANCE OF THIS SOFTWARE.
  #define INST  0x  /* used to fill out the instance field of the 
variables table */
  
  struct variable {

-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
  chartype;   /* type of variable */
  /*
   * See important comment in snmp_vars.c relating to acl


This patch changes a data structure in a public header file and hence 
breaks the ABI. This is something we could do for Net-SNMP 5.8 since 
there has not yet been any 5.8 release but it's something we can't do 
for older Net-SNMP versions.


Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Bill Fenner 
On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond  wrote:

> On the other hand, I question whether the extra overhead is a real
> issue in 2018.


I have the same question, but know that I have no useful opinion here - my
"embedded system" ships with 4 gigs minimum, but the project has more use
cases than mine.  For example, the project did decide to back off from
introducing c99 constructs.

  Bill
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Eric S. Raymond 
Bill Fenner :
> I don't think the patch is the issue.  There are two questions to be
> addressed first:
> 
> 1. For the embedded environment, is it acceptable to use an extra several
> bytes for this (or is there a way to rearrange the struct so that padding
> reduces the extra cost)?

A couple of instances I looked at could be repacked to avoid the 1 char of slop
using techniques I described in

http://www.catb.org/esr/structure-packing/

On the other hand, I question whether the extra overhead is a real
issue in 2018.  I have old-school reflexes about this myself, but
even embedded systems are shipping with a lot more RAM than they used to.
Unless variable instances are being spawned by the tens of thousands 
it's hard to imagine this being a real problem.  And how likely is
that on a resource-constrained system?

I actually did think about repacking the struct (see: old-school reflexes)
but decided not to in order to avoid compromising the readability by
separating the two elements that seem to be in all variants.  Also to make
the patch itself easy to understand.

> 2. Is it reasonable to have more than 255 variables in a single
> registration, or should the reporter just split up his registration into
> multiple groups, each with less than 255 variables?

That I have no opinion on.  My domain knowledge of SNMP and its usage is
very limited.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Fix patch for SF bug 2833

2018-03-22 Thread Bill Fenner 
I don't think the patch is the issue.  There are two questions to be
addressed first:

1. For the embedded environment, is it acceptable to use an extra several
bytes for this (or is there a way to rearrange the struct so that padding
reduces the extra cost)?
2. Is it reasonable to have more than 255 variables in a single
registration, or should the reporter just split up his registration into
multiple groups, each with less than 255 variables?

  Bill


On Wed, Mar 21, 2018 at 10:43 PM, Eric S. Raymond  wrote:

> From 54e79ba66327bdb54f97f457d76531f657ec546d Mon Sep 17 00:00:00 2001
> From: "Eric S. Raymond" 
> Date: Wed, 21 Mar 2018 22:22:29 -0400
> Subject: [PATCH] include/net-snmp/agent/{snmp_vars.h,var_struct.h}:
> address SF
>  bug 2833.
>
> Tests pass,
> ---
>  include/net-snmp/agent/snmp_vars.h  |  2 +-
>  include/net-snmp/agent/var_struct.h | 12 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/net-snmp/agent/snmp_vars.h
> b/include/net-snmp/agent/snmp_vars.h
> index bd27eeb..b2f2f8f 100644
> --- a/include/net-snmp/agent/snmp_vars.h
> +++ b/include/net-snmp/agent/snmp_vars.h
> @@ -101,7 +101,7 @@ PERFORMANCE OF THIS SOFTWARE.
>  #define INST   0x  /* used to fill out the instance field of
> the variables table */
>
>  struct variable {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  chartype;   /* type of variable */
>  /*
>   * See important comment in snmp_vars.c relating to acl
> diff --git a/include/net-snmp/agent/var_struct.h
> b/include/net-snmp/agent/var_struct.h
> index 15b5770..10bf4ae 100644
> --- a/include/net-snmp/agent/var_struct.h
> +++ b/include/net-snmp/agent/var_struct.h
> @@ -52,7 +52,7 @@ typedef struct netsnmp_subtree_s {
>   * application.  The first 5 elements of the structure must remain
> constant.
>   */
>  struct variable1 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> @@ -61,7 +61,7 @@ struct variable1 {
>  };
>
>  struct variable2 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> @@ -79,7 +79,7 @@ struct variable3 {
>  };
>
>  struct variable4 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> @@ -88,7 +88,7 @@ struct variable4 {
>  };
>
>  struct variable7 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> @@ -97,7 +97,7 @@ struct variable7 {
>  };
>
>  struct variable8 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> @@ -106,7 +106,7 @@ struct variable8 {
>  };
>
>  struct variable13 {
> -u_char  magic;  /* passed to function as a hint */
> +u_short magic;  /* passed to function as a hint */
>  u_char  type;   /* type of variable */
>  u_short acl;/* access control list for variable */
>  FindVarMethod  *findVar;/* function that finds variable */
> --
> 2.7.4
>
>
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> As war and government prove, insanity is the most contagious of
> diseases.   -- Edward Abbey
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Fix patch for SF bug 2833

2018-03-21 Thread Eric S. Raymond 
>From 54e79ba66327bdb54f97f457d76531f657ec546d Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond" 
Date: Wed, 21 Mar 2018 22:22:29 -0400
Subject: [PATCH] include/net-snmp/agent/{snmp_vars.h,var_struct.h}: address SF
 bug 2833.

Tests pass,
---
 include/net-snmp/agent/snmp_vars.h  |  2 +-
 include/net-snmp/agent/var_struct.h | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/net-snmp/agent/snmp_vars.h 
b/include/net-snmp/agent/snmp_vars.h
index bd27eeb..b2f2f8f 100644
--- a/include/net-snmp/agent/snmp_vars.h
+++ b/include/net-snmp/agent/snmp_vars.h
@@ -101,7 +101,7 @@ PERFORMANCE OF THIS SOFTWARE.
 #define INST   0x  /* used to fill out the instance field of the 
variables table */
 
 struct variable {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 chartype;   /* type of variable */
 /*
  * See important comment in snmp_vars.c relating to acl 
diff --git a/include/net-snmp/agent/var_struct.h 
b/include/net-snmp/agent/var_struct.h
index 15b5770..10bf4ae 100644
--- a/include/net-snmp/agent/var_struct.h
+++ b/include/net-snmp/agent/var_struct.h
@@ -52,7 +52,7 @@ typedef struct netsnmp_subtree_s {
  * application.  The first 5 elements of the structure must remain constant.
  */
 struct variable1 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
@@ -61,7 +61,7 @@ struct variable1 {
 };
 
 struct variable2 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
@@ -79,7 +79,7 @@ struct variable3 {
 };
 
 struct variable4 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
@@ -88,7 +88,7 @@ struct variable4 {
 };
 
 struct variable7 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
@@ -97,7 +97,7 @@ struct variable7 {
 };
 
 struct variable8 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
@@ -106,7 +106,7 @@ struct variable8 {
 };
 
 struct variable13 {
-u_char  magic;  /* passed to function as a hint */
+u_short magic;  /* passed to function as a hint */
 u_char  type;   /* type of variable */
 u_short acl;/* access control list for variable */
 FindVarMethod  *findVar;/* function that finds variable */
-- 
2.7.4


-- 
http://www.catb.org/~esr/;>Eric S. Raymond

As war and government prove, insanity is the most contagious of
diseases.   -- Edward Abbey

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders