[Xymon] SCO OS 6 Returns Negative Memory

[Jamison Maxwell]

Works like a charm! Thanks so much Henrik and Jeremy!



Jamison Maxwell
jamison at newasterisk.com

________________________________________
From: henrik at hswn.dk [henrik at hswn.dk]
Sent: Friday, May 03, 2013 4:48 AM
To: Jeremy Laidman
Cc: Jamison Maxwell; xymon at xymon.com
Subject: Re: [Xymon] SCO OS 6 Returns Negative Memory

On Fri, 3 May 2013 13:14:17 +1000, Jeremy Laidman
<jlaidman at rebel-it.com.au> wrote:
> On 3 May 2013 04:11, Jamison Maxwell <jamison at newasterisk.com> wrote:
>
>> 4294496256
>
>
> Yes, this is bigger than what atoi() will return.  This is done in
> xymond/client/sco_sv.c in the function handle_sco_sv_client() in the
> following line of code:
>
>                 memphystotal = (atoi(memsizestr) / 1048576);
>
> The variable memsizestr is a string pointer to the value in the
[memsize]
> client data section.  The variable memphystotal is defined as a long, so
it
> would make sense that atol() be used instead of atoi().
>
> This is probably a bug in Xymon, but I'm not a C coder so I'm not
entirely
> sure.  However, the [memsize] section is only parsed for (and sent by)
> SCO/Unixware systems, which isn't exactly the most popular OS around.
As
> far as I can tell, it's the only client parsing code that uses atoi()
for
> memory numbers, and has probably rarely been used on SCO systems with
> sufficient memory size to overflow the signed integer type (about
2.1GB).
>
> Henrik, agree that this is a bug?

Sounds like it. It's the first bug report on the SCO client that I can
recall, so as you say - probably not the most widely tested piece of code.

Changing that line to use "atol" instead of "atoi" sounds like a simple
and valid solution. Perhaps Jamison could try that and let us know if it
solves the problem ?


Regards,
Henrik