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 <nopo...@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 >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice