Andy Ross wrote:
My guess is that the property tree doesn't care either, and it's
simply the output routine that is truncating the string due to the
embedded null. Is there some sample code to exhibit the problem?
Hmm, that makes sense, why should Nasal or the property care in the
first
Andy Ross wrote:
You're right. The property system does not support arbitrary byte
arrays in the string value. The SGPropertyNode::setStringValue()
interface supports only C strings (a char* with no length), which are
always nul terminated.
Well, char* doesn't require it to be NULL
I wrote:
The property system does not support arbitrary byte arrays in the
string value. The SGPropertyNode::setStringValue() interface
supports only C strings (a char* with no length), which are always
nul terminated.
Well, char* doesn't require it to be NULL terminated and
Andy Ross wrote:
It does if you don't specify a length: fixing this requires changing
every spot in the code where a string was read from or written to a
property to make the code handle the length properly. It's not hard,
but it's a huge amount of work (and probably not worth it, as you can
Curtis L. Olson wrote:
Andy Ross wrote:
It does if you don't specify a length: fixing this requires changing
every spot in the code where a string was read from or written to a
property to make the code handle the length properly. It's not hard,
but it's a huge amount of work (and probably
On June 1, 2005 07:02 pm, Andy Ross wrote:
This isn't fixable without relatively major surgery, so for now I
think you're stuck. Maybe Melchior's suggestion of storing your data
in Nasal space is the best one for the moment.
Okay. I think I came up with something using Nasal. =)
Objects in
Ampere K. Hardraade wrote:
On June 1, 2005 07:02 pm, Andy Ross wrote:
This isn't fixable without relatively major surgery, so for now I
think you're stuck. Maybe Melchior's suggestion of storing your data
in Nasal space is the best one for the moment.
Okay. I think I came up with
On Thursday 02 Jun 2005 20:18, Curtis L. Olson wrote:
Ampere K. Hardraade wrote:
On June 1, 2005 07:02 pm, Andy Ross wrote:
This isn't fixable without relatively major surgery, so for
now I think you're stuck. Maybe Melchior's suggestion of
storing your data in Nasal space is the best one
Ampere K. Hardraade wrote:
I have been experimenting with Nasal lately. The focus of my experiment is to
have one Nasal script communicate with another using the property tree. In
an attempt of communication, a Nasal script of mine placed the following
stream of characters to the property
Andy Ross wrote:
Property names should be ASCII strings, by convention at least if not
by force. ASCII strings don't contain nuls.
Oh wait, Ampere is actually trying to put \0 etc into a string (or
default) property? That can't be done. You could however define the
properties to be of type
I don';t think the property tree cares much, I expect this is a string
handling problem in Nasal because it is written in C(++).
Actually, it is the otherway around: Nasal doesn't care, while the property
tree does. I hope Nasal stays that way.
Oh wait, Ampere is actually trying to put \0
Ampere K. Hardraade wrote:
Well, last evening I experimented with putting information one byte at a time
to the property tree as opposed to putting a string, but I don't see this as
a way out because it is not scalable. The running time can reach thousands,
if not tens of thousands easily.
Erik Hofman wrote:
I don';t think the property tree cares much, I expect this is a
string handling problem in Nasal because it is written in C(++).
No, Nasal strings are arbitrary byte streams. You can have embedded
zeros. I understood the question to be about the property *name*, not
the
On June 1, 2005 04:23 pm, Andy Ross wrote:
My guess is that the property tree doesn't care either, and it's
simply the output routine that is truncating the string due to the
embedded null. Is there some sample code to exhibit the problem?
Andy
Do you mean something like this?
# **
Ampere K. Hardraade wrote:
Andy Ross wrote:
Is there some sample code to exhibit the problem?
Do you mean something like this?
Yup, that will do it. :)
You're right. The property system does not support arbitrary byte
arrays in the string value. The SGPropertyNode::setStringValue()
Ampere K. Hardraade wrote:
Why doesn't the property tree except the \0 character?
Is there any chance that it can accept the \0 character?
The zero is the ASCII NUL character, which has been used as the end
of string marker since the beginning of time (which we all know was
at midnight GMT on
16 matches
Mail list logo
