Re: [Oorexx-devel] Possible Buffer Overflow

[Rick M. <obj...@gm...>]

Interesting timing...I was just in the process of replacing all of the
_ltoa() calls with sprintf() calls.  The problem with ltoa() doesn't really
show up until you compile in 64-bit mode.  That's one of the type safety
problems the code has with 64-bit compilation.  On Linux, a long is 64-bit.
On Windows, a long remains 32-bit in 64-bit code.  A bit of a nightmare.

On the linux platform the _ltoa() calls were #defined to be a sprintf()
anyway, which is why we were getting the warning messages in a lot of the
places it is used.

Rick

On 10/18/07, Moritz Hoffmann <ant...@gm...> wrote:
>
> Hi,
> while looking at the code I saw that the function _ltoa is used quite
> frequently to convert longs to strings. Reading its documentation I
> was told that this function does not check for buffer overflows. To
> make sure it does not overflow the char* used as buffer must be >= 33
> characters long as it will never return more than 32 chars plus the
> terminator.
>
> Well, so far, so good. The thing I'm worrying about is that the
> function is being used for shorter buffers as well. For example,
> NumberStringClass::formatInternal creates a 15 character long buffer
> and passes it to _ltoa. Do we need to worry about that?
> Moritz
>
> --
> Moritz Hoffmann;
> http://antiguru.de/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>