Re: Win32Lib bug
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Nov 20, 1998
- 660 views
I've found the cause of the 12-character string bug in win32lib.ew. Using an enhanced version of safe.e, it was easy to locate. In getItem() we have: iLength = sendMessage( id, msg, item, 0 ) -- extra line I added: iLength = iLength+1 -- temporary fix, - David? -- NEW! 0.14c if iLength = 0 then warnErr( "Get item text length is zero." ) return "" end if -- allocate a buffer buffer = allocate( iLength ) -- not quite enough space! -- get the message, based on control type if window_class[ id ] = LISTBOX then msg = LB_GETTEXT elsif window_class[ id ] = COMBO then msg = CB_GETLBTEXT end if -- move the text to a buffer ok = sendMessage( id, msg, item, buffer ) I found that the buffer allocated above was one character too small. It did not allow for the 0 that C always adds to strings (but Euphoria doesn't require). As a result, Windows would write the extra 0, sometimes corrupting the next block of storage. If the string was an exact multiple of 4 in length (such as 12) then Euphoria would allocate exactly the number of bytes requested, but if it wasn't, Euphoria would round up to the next multiple of 4 bytes, thereby protecting against the extra 0. Maybe the fix should just be: buffer = allocate(iLength+1) instead. I don't know. David should consider it. There are other calls to SendMessage that should also be checked. * * * safe.e: I've enhanced safe.e to make detection of these errors much easier. safe.e now allocates extra space before and after each block that you allocate and fills it with a known pattern. This makes it possible to check for blocks of memory where data has been written just before or just after the allocated block. Euphoria code can't write out of bounds, because of safe.e checks in poke, mem_copy etc., but machine code, or Windows can do it. Regards, Rob Craig Rapid Deployment Software http://members.aol.com/FilesEu/