On 29 May 2010 06:57, Ralph Versteegen <[email protected]> wrote: > On 29 May 2010 06:49, Mike Caron <[email protected]> wrote: >> On 28/05/2010 2:47 PM, Ralph Versteegen wrote: >>> >>> 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) >> >> It calls RReallocate, which either calls Reallocate or HeapAlloc with >> HEAP_ZERO_MEMORY, both of which clear any new memory allocated. > > False. > "realloc() changes the size of the memory block pointed to by ptr to > size bytes. The contents will be unchanged to the minimum of the old > and new sizes; newly allocated memory will be uninitialized."
(And, yes, Reallocate is translated directly to realloc()) >> So, you're right. It doesn't add the null, the null is already there. >> >> -- >> Mike >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
