Subject: Re: Model Strings

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 15 Dec 2005 08:47:33 -0800

Joel,

I agree with your reasoning, always using an explicit length improves
robustness over NULL terminated strings. Specifying both a length and
NULL termination is even more confusing and error prone. If we left
things they way they are for consistency, the protocol or model draft
would probably need to clarify that if the NULL terminated string does
not match the length encoding in the protocol, the length encoding is
the length that should be used. This is more confusing than just
removing the declaration that strings are NULL terminated.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 15, 2005 8:25 AM
To: [email-masked]
Subject: Model Strings

The comments about strings and string length made me think a bit about
the 
way the model describes strings.

As has been discussed, the protocol will always use an explicit length 
encoding for strings.

Also, although not discussed, the string handling needs to permit 
internationalized strings.

Hence, it seems to me that we are better off NOT declaring that strings
are 
null terminated.
Rather, rely only on the explicit length that the protocol communicates.

This actually improves robustness.  Before, an implementor might have
been 
tempted to use strcpy to copy strings from a message.  However, if the
null 
and the length did not match, unanticipated results could occr.  This
way, 
the implementor knows to use strncpy, and if the implementation wants a 
null termination, the processing code can add one.
Note that in filling in the string in a message, there is no extra work
for 
doing this since the code had to figure out the length anyway to fill in

the length field.

So I would like to change the model text to say that strings are NOT
null 
terminated, but rather are managed in terms of their length.

Objections?  Comments?

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Dec 2005 13:02:12 -0500

A nod from here as well.
What Joel describes ala strncpy matches what we do in our
implementation.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Dec 2005 16:57:22 -0500

Seems to be agreement that I should make this change to strings.
I will do so, removing the null termination and referencing the explicit 
length protocol behavior.
(I will try to open a ticket so it does not get lost.)

For those who care about the programming nits, after discussion with Alan, 
the right routine to reference is that implementations could use memcpy to 
copy the correct length string.
However, this is a nit for the list, as I do not believe that the model 
text should state anything that specific about processing.

Yours,
Joel M. Halpern

---

From: "Guo, Xiaoyi" <[email-masked]>
Date: Tue, 20 Dec 2005 16:51:23 +0800

Yes, memcpy always do this work, but it's the implementation details.

and in a word , I agree with this change.

cheers,
Xiaoyi

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, December 17, 2005 5:57 AM
Subject: Re: Model Strings

| Seems to be agreement that I should make this change to strings.
| I will do so, removing the null termination and referencing the explicit 
| length protocol behavior.
| (I will try to open a ticket so it does not get lost.)
| 
| For those who care about the programming nits, after discussion with Alan, 
| the right routine to reference is that implementations could use memcpy to 
| copy the correct length string.
| However, this is a nit for the list, as I do not believe that the model 
| text should state anything that specific about processing.
| 
| Yours,
| Joel M. Halpern