Subject: Model Strings

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Dec 2005 11:24:52 -0500

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: Alan DeKok <[email-masked]>
Date: Thu, 15 Dec 2005 14:04:00 -0500

> Rather, rely only on the explicit length that the protocol communicates.

  I agree.  Implementation and deployment of other protocols indicates
that (only) NUL terminated strings in the protocol are a source of
problems.

> the implementor knows to use strncpy

  From a non-protocol perspective, strncpy() is a bad function, and
should never be used.  But I digress.

> terminated, but rather are managed in terms of their length.

  Absolutely.

  Alan DeKok.