Nathan Kurz <[EMAIL PROTECTED]> wrote: > > Also, SQLite makes no guarantees as to the alignment of returned blobs. > > This could cause a random crash somewhere down the line. You could get > > around this by making a copy of the blob to memory obtained from malloc(). > > Can you offer more information about this? In what I'm working on, I > am storing arrays of complex structures as blobs and then reconstituting > them. I was concerned about alignment at one point, but it seems to > be working without problems. Are there 'gotchas' that are likely to > 'get me' in the future? This is server-side, and only for temporary > data, so I'm not concerned about the endian-ness, only the alignment. >
The address of the first byte of a BLOB or text string can be anything. It need not be a multiple of 2 or 4 or 8 as is required by some (most) processors for larger data structures. SQLite assumes that all strings and BLOBs are an array of bytes that can begin on an odd byte. Actually, short blobs and strings - less than 32 bytes - or long blobs and strings - greater than about 1000 bytes - will always be 4- or 8-byte aligned depending on the requirements of the host computer. It is only those middle-length strings and blobs that give a problem. Nevertheless, 33 to 999 bytes is a reasonably common string length... This turns out to be a bug in the current implementation when dealing with UTF16 strings. SQLite can return a UTF16 string that is not aligned on an even byte boundary. Some processors get very upset about that. This bug has only recently been noticed, however, despite being in the code since the very beginning of UTF16 support, so apparently most of the people who actually use UTF16 are doing so on chips that allow odd-byte alignment of UTF16 text. -- D. Richard Hipp <[EMAIL PROTECTED]>
