On 29 May 2010 06:44, Mike Caron <[email protected]> wrote: > On 28/05/2010 2:42 PM, Ralph Versteegen wrote: >> >> On 29 May 2010 06:20, Mike Caron<[email protected]> wrote: >>> >>> On 28/05/2010 2:17 PM, Ralph Versteegen wrote: >>>> >>>> On 29 May 2010 06:02, James Paige<[email protected]> wrote: >>>>> >>>>> How do zstrings work? >>>>> >>>>> Back in the days of the one C/C++ class I took, I remember learning >>>>> that >>>>> zstrings were a zero-terminated string buffer. >>>>> >>>>> They were no good for storing arbitrary binary data, because the first >>>>> 0 >>>>> would terminate the string, causing any data from the 0 to the end of >>>>> the buffer to be ignored. >>>>> >>>>> Am I correct to assume that the zstring ptr's used in Reload are not >>>>> like that? >>>>> >>>>> I would hate to be losing saved tag data beccause 8 or more >>>>> low-numbered tags in a row happened to all be off. >>>>> >>>>> Please put my probably-unfounded fears to rest :) >>>>> >>>>> --- >>>>> James >>>> >>>> Right. They are actually just byte ptrs. I don't understand why Mike >>>> used zstring instead of byte ptr, since there's a separate GetString >>>> if you want a string instead of a binary lump. >>>> >>>> Mike wrote in r3540: >>>> >>>> - Also, nodes now keep track of the size of their internal ZStrings, >>>> in case they have embedded nulls. >>> >>> I used ZString ptr so that I would only need one pointer to do all of the >>> following: >>> >>> - Cast to String if requested >>> - Store arbitrary binary daya >>> - Cache strings if needed (although, this doesn't happen currently with >>> data) >> >> (No idea what you mean) >> >>> - etc. >>> >>> -- >>> Mike >> >> I don't see the point of having a "GetZString" function. Surely if you >> wanted a string, you would use GetString instead, whereas if you >> wanted binary data, you would expect a "GetBinary" function which >> returns a byte ptr instead. Plus a SetContent overload. >> >> So, all binary blobs should be terminated in-memory by an extra null? >> >> Suppose that you want to store x bytes of binary, so you call >> ResizeZString(node, x). Then you retrieve the Zstring and write to it. >> Shouldn't you also write an extra null? That's a bit of a nuisance. >> Just look at SaveBitsetArray: not only does it not write the null, but >> it writes off the end of allocated memory (which may be causing >> crashes for James this very moment :P). > > Take a closer look at ResizeZString: It adds a null for you. The buffer is > actually size + 1. > > -- > Mike
No, it doesn't. It allocates space for the null, but you still have to set it yourself. Unless it was not intended that a terminating null would be required for rltString node data (but in that case, accidentally calling GetString could cause a segfault) _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
