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