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?
- 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.
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.)
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
