Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

5.7.2.pre3 published for testing

1 view
Skip to first unread message

Wes Hardaker

unread,
Jul 31, 2012, 8:11:10 PM7/31/12
to

Get it, test it, smile at it:

http://www.net-snmp.org/download.html

See the ChangeLog file for details on what's changed since pre2.
Hopefully this will be the last pre-release, so test it well!

--
Wes Hardaker
Please mail all replies to net-snm...@lists.sourceforge.net

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Bart Van Assche

unread,
Aug 5, 2012, 6:41:14 AM8/5/12
to
On 08/01/12 00:11, Wes Hardaker wrote:
>
> Get it, test it, smile at it:
>
> http://www.net-snmp.org/download.html
>
> See the ChangeLog file for details on what's changed since pre2.
> Hopefully this will be the last pre-release, so test it well!

Sorry for jumping in late, but this is what I came up with after
inspection of recent commits and of compiler warnings:


[PATCH] Make snmp_alarm_reset() use the monotonic clock. Fixes a bug introduced in commit 37ba7e2.
---
snmplib/snmp_alarm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/snmplib/snmp_alarm.c b/snmplib/snmp_alarm.c
index 2bed22f..c015102 100644
--- a/snmplib/snmp_alarm.c
+++ b/snmplib/snmp_alarm.c
@@ -474,7 +474,7 @@ snmp_alarm_reset(unsigned int clientreg)
struct snmp_alarm *a;
struct timeval t_now;
if ((a = sa_find_specific(clientreg)) != NULL) {
- gettimeofday(&t_now, NULL);
+ netsnmp_get_monotonic_clock(&t_now);
a->t_lastM.tv_sec = t_now.tv_sec;
a->t_lastM.tv_usec = t_now.tv_usec;
a->t_nextM.tv_sec = 0;



[PATCH] Make get_exec_output() work on big endian systems.
---
agent/mibgroup/util_funcs.c | 2 +-
agent/mibgroup/utilities/execute.c | 1 +
agent/mibgroup/utilities/execute.h | 4 ++--
3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/agent/mibgroup/util_funcs.c b/agent/mibgroup/util_funcs.c
index 94b34bd..4c34c32 100644
--- a/agent/mibgroup/util_funcs.c
+++ b/agent/mibgroup/util_funcs.c
@@ -243,7 +243,7 @@ get_exec_output(struct extensible *ex)
#if HAVE_EXECV
char cachefile[STRMAX];
char cache[NETSNMP_MAXCACHESIZE];
- size_t cachebytes;
+ int cachebytes;
int cfd;
#ifdef NETSNMP_EXCACHETIME
long curtime;
diff --git a/agent/mibgroup/utilities/execute.c b/agent/mibgroup/utilities/execute.c
index b2d0bad..68f3654 100644
--- a/agent/mibgroup/utilities/execute.c
+++ b/agent/mibgroup/utilities/execute.c
@@ -35,6 +35,7 @@
#include <net-snmp/agent/net-snmp-agent-includes.h>
#include <ucd-snmp/errormib.h>

+#include "execute.h"
#include "struct.h"

#define setPerrorstatus(x) snmp_log_perror(x)
diff --git a/agent/mibgroup/utilities/execute.h b/agent/mibgroup/utilities/execute.h
index d52dfdc..3c9e84b 100644
--- a/agent/mibgroup/utilities/execute.h
+++ b/agent/mibgroup/utilities/execute.h
@@ -4,8 +4,8 @@
config_belongs_in(agent_module)

int run_shell_command(char *command, char *input,
- char *output, size_t *out_len);
+ char *output, int *out_len);
int run_exec_command( char *command, char *input,
- char *output, size_t *out_len);
+ char *output, int *out_len);

#endif /* _MIBGROUP_EXECUTE_H */

Magnus Fromreide

unread,
Aug 5, 2012, 5:32:26 PM8/5/12
to
The above patch looks ok, so +1 for it.

> [PATCH] Make get_exec_output() work on big endian systems.

I have a hard time understanding why cachebytes and out_size have to be
able to handle negative values in order to work on big endian systems.
Could you please explain this one a little further?

Bart Van Assche

unread,
Aug 6, 2012, 2:47:54 AM8/6/12
to
On 08/05/12 21:32, Magnus Fromreide wrote:
> On Sun, 2012-08-05 at 10:41 +0000, Bart Van Assche wrote:
>> [ ... ]
> The above patch looks ok, so +1 for it.

Thanks !

>> [PATCH] Make get_exec_output() work on big endian systems.
>
> I have a hard time understanding why cachebytes and out_size have to be
> able to handle negative values in order to work on big endian systems.
> Could you please explain this one a little further?

If sizeof(size_t) > sizeof(int), passing a 64-bit variable to a function
that expects a 32-bit variable will cause the result to be written into
the 32 most significant bits instead of the 32 least significant bits.
So the test "cachebytes > 0" will always evaluate to true on such
systems (at least if NETSNMP_MAXCACHESIZE has at least one bit set in
the lower 32 bits).

Bart.

Dave Shield

unread,
Aug 6, 2012, 3:18:04 AM8/6/12
to
On 5 August 2012 11:41, Bart Van Assche <bvana...@acm.org> wrote:
> --- a/agent/mibgroup/utilities/execute.h
> +++ b/agent/mibgroup/utilities/execute.h
> @@ -4,8 +4,8 @@
> config_belongs_in(agent_module)
>
> int run_shell_command(char *command, char *input,
> - char *output, size_t *out_len);
> + char *output, int *out_len);
> int run_exec_command( char *command, char *input,
> - char *output, size_t *out_len);
> + char *output, int *out_len);


Doesn't this introduce a change in the API ?
As such, shouldn't it require a new name for these routines?
(perhaps with the old API retained as a compatability wrapper)

Dave

Bart Van Assche

unread,
Aug 6, 2012, 3:34:37 AM8/6/12
to
On 08/06/12 07:18, Dave Shield wrote:
> On 5 August 2012 11:41, Bart Van Assche <bvana...@acm.org> wrote:
>> --- a/agent/mibgroup/utilities/execute.h
>> +++ b/agent/mibgroup/utilities/execute.h
>> @@ -4,8 +4,8 @@
>> config_belongs_in(agent_module)
>>
>> int run_shell_command(char *command, char *input,
>> - char *output, size_t *out_len);
>> + char *output, int *out_len);
>> int run_exec_command( char *command, char *input,
>> - char *output, size_t *out_len);
>> + char *output, int *out_len);
>
>
> Doesn't this introduce a change in the API ?
> As such, shouldn't it require a new name for these routines?
> (perhaps with the old API retained as a compatability wrapper)

That change restores the API to what it has always been before July 30,
2012 (see also commit 7374b84fe4c2ef8497fde3dae80a69aa89eba19c). So I'm
not breaking the API but restoring it ...

Bart.

Dave Shield

unread,
Aug 6, 2012, 4:13:01 AM8/6/12
to
On 6 August 2012 08:34, Bart Van Assche <bvana...@acm.org> wrote:
>> Doesn't this introduce a change in the API ?
>
> That change restores the API to what it has always been before July 30,
> 2012 (see also commit 7374b84fe4c2ef8497fde3dae80a69aa89eba19c). So I'm
> not breaking the API but restoring it ...

Fair enough.
Dave
0 new messages