On 29 May 2010 07:16, Mike Caron <[email protected]> wrote: > On 28/05/2010 3:11 PM, Ralph Versteegen wrote: >> >> 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. > > Me neither. In theory, I could cache data buffers like I do names. But, upon > giving it more than 23 nanoseconds of thought, that wouldn't work so well, > so we may consider that stricken from the list. > >>>>>>>>> >>>>>>>>>> - 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. > > Ah, I see it now. It's a basic off-by-one error: > > for i as integer = 0 to size > d[i * 2] = bs(i) and &hff > d[i * 2 + 1] = int(bs(i) / 256) and &hff > next > > That should be: > > for i as integer = 0 to size - 1 > d[i * 2] = bs(i) and &hff > d[i * 2 + 1] = int(bs(i) / 256) and &hff > next
Ah, I'd figured that was intentional due to plain-old crazy BASIC array ubound nonsense. BASIC really does encourage off-by-one errors. >>>>>> 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 > > > -- > 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
