On 29 May 2010 07:04, Mike Caron <[email protected]> wrote: > On 28/05/2010 3:00 PM, Ralph Versteegen wrote: >> >> 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) > > About which?
What you meant by caching strings. >>>>>>> >>>>>>>> - 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()) > > Yes, you are correct. I could have sworn I saw somewhere... oh well, not > important. I'll fix it. I'd just like a wrapper function to do resize + write null + return location (as a byte ptr) all in one step. And then remove all the ZString functions. That's an internal implementation detail. > That said, there James likely isn't experiencing any crashes, because > nowhere does a ZString get cast to a string when it isn't already an actual > string with a null. > > (And, [Save|Load]BitsetArray look okay to me.) SaveBitsetArray only allocates size*2 bytes, but writes (size+1)*2 bytes. LoadBitsetArray looks correct to me as well. >>>> So, you're right. It doesn't add the null, the null is already there. >>>> >>>> -- >>>> Mike > > -- > 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
