The unix design of strings as arrays of bytes terminated by a sentinel
value (<nul>) can't begin to be robust at all levels of a software system.
Even when attempts are made to fix the problem with code like strncpy and
snprintf, fundamental problems with the design remain (such as losing the
terminating <nul>). How is it the <nul> isn't part of the string and has
to be managed independently by the programmer? Even without strncpy, how
many programs are broken because they will "happily" store an n+1 character
string (inc'l the <nul>) in an n byte array? The <nul> should have been
protected in all cases with this design.
Proper implementation of strings would have been a data structure along the
lines of:
type
encoding
maxlength
currentlength
{data,pointer to data}
This would have allowed fixed length strings for use with <limits.h> types
of definitions, variable length with a declared maximum size and variable
length (no maximum) strings could be supported. Storage on a heap could be
an option for any type string. (Why? Symmetry!) (Any similarity to PL/1 is
coincidental.) Want to dynamically alloc a string and it's storage? No
problem.
Benefits: Typical features for strings would be available in a standard
fashion, characters larger than 1 byte could be transparently handled,
strings could be marked read-only, no undue performance hit would occur, ...
And the #1 plus: program reliability wouldn't be nearly the joke it is today.
Such a design wouldn't preclude the requirement for careful and
competent programming, but it would provide a mechanism for sanity checks
at all levels of a software system. Such a package, robustly implemented
by a competent programmer, must already exist. Anyone know where it is?
-- Mark Walker UNM/EECE, 7-3688, mwalker@eece.unm.edu"A wife and a steady job have ruined many a good biker."
-- seen at Applebee's