<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 3 May 2013 04:11, Jamison Maxwell <span dir="ltr"><<a href="mailto:jamison@newasterisk.com" target="_blank">jamison@newasterisk.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">4294496256</blockquote></div><br>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:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">                memphystotal = (atoi(memsizestr) / 1048576);</div><div><br></div><div style>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().</div>

<div style><br></div><div style>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).</div>

<div style><br></div><div style>Henrik, agree that this is a bug?</div><div style><br></div><div style>Cheers</div><div style>Jeremy</div><div style><br></div></div></div>