Re: [PATCH] fdo#42492: fixing Basic HEX command

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:
http://help.libreoffice.org/Basic/Using_Variables#Integer_Variables
Microsoft Visual Basic uses double sizes (4 and 8 bytes):
http://msdn.microsoft.com/en-US/library/47zceaw7%28v=vs.110%29

Uray M. János

On Tue, Jul 31, 2012 at 11:08 AM, Noel Power <nopower@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