[PATCH] fdo#42492: fixing Basic HEX command

János Uray uray.janos at gmail.com
Tue Jul 31 04:55:55 PDT 2012

Yes, that is what I was trying to say: length 15 and length 16 were both
wrong. There were two mistakes: the buffer overflow, and the non-compatible
types and printf-strings. Fixing the latter one (which resulted in 16
characters on 64-bit platforms, where C++ "long" is 64-bit) makes the
former one (the 15 characters) irrelevant. The patch prints at most 4
(integer) or 8 (long) characters.
The integer and long in LibreOffice Basic are described here:
Microsoft Visual Basic uses double sizes (4 and 8 bytes):

Uray M. János

On Tue, Jul 31, 2012 at 11:08 AM, Noel Power <nopower at suse.com> wrote:

> On 31/07/12 07:13, János Uray wrote:
>> The patch solves this bug: https://bugs.freedesktop.org/**
>> show_bug.cgi?id=42492<https://bugs.freedesktop.org/show_bug.cgi?id=42492>
>> There was a buffer overflow: char aBuffer[16] had no room for the
>> terminating null character.
>> But the hex command was still wrong, because the printf used "%X" and
>> "%lX", which are very platform-dependent.
>> Actually the "integer" is only 16-bit, and "long" is only 32-bit. I've
>> corrected this by using "%"SAL_PRIXUINT32 as described in http://wiki.**
>> documentfoundation.org/**Development/Sal_Types<http://wiki.documentfoundation.org/Development/Sal_Types>(and there is no SAL_PRIXUINT16, so both were converted to sal_uInt32).
> hmm, not looking at the patch in detail yet I am not sure if a length of
> 16 is sensible, if the size of the type for the hex output is 2 (integer)
> or 4 bytes (long) I would expect the max display from HEX to be  FFFF or
> FFFFFFFF respectively :/ I'd like to see what MS vba does here, we should
> try to remain compatible if possible.
> Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120731/a2a36147/attachment.html>

More information about the LibreOffice mailing list