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." > 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
