Re: Fix patch for SF bug 2833
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: Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)
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. This article https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/ suggests the problem may have been solved, or nearly so. -- 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
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)
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)
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 To: e...@thyrsus.com, 'Bill Fenner' CC: 'Net-SNMP Coders' 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 Cc: Net-SNMP Coders Subject: C99 (was: Re: Fix patch for SF bug 2833) 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 -- 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)
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 Cc: Net-SNMP Coders Subject: C99 (was: Re: Fix patch for SF bug 2833) 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 -- 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
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)
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
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
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
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
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
>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
