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). _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
