🚀 go-pugleaf

Another problem that \z would fix is a problem introduced by the standard
that I missed in my first (incomplete) reading of it:

char str[4]= "Help";

would have to compile without error.  If the compiler doesn't even give a
warning,   strchr(str,"z")   is going to be a bit of a surprise.  If it does
give a warning, initializing strings without a trailing null is going to be
annoying.

As Chris mentioned, the committee seems to see a need for non-null-terminated
strings.  Generating a warning every time you use a feature there is a genuine
need for (I mean, they made the language fatter for it) can't be an acceptable
practice.  Creating the maintenance nightmare of strings suddenly losing their
trailing nulls because someone didn't notice that there isn't room for it any
longer can't be an acceptable practice.

I've already run into problems where people forgot to count the trailing null
when computing the size of an array.  Luckilly the compilers currently check
this for you when they can (when you specify the string as an initializer).

Along with the other (also small) reasons for adding \z, I think this justifies
the almost trivial changes to be made to the standard specification.  I havn't
heard *ANY* arguments saying that it shouldn't be added other than "It's not
worth the effort."

I think it's right on the border line as far as last minute changes go.  I
wouldn't be surprised if it didn't make it in, but it'd be a nice change.
Who would it hurt?  (or is it just the fear that after the final draft a
horde of screaming programmers will suddenly decide that \z is the worst
thing since "noalias" and fire bomb committee members' houses?)

Humbly,

Eric Tye McQueen              (801) 753-4683                P.O. Box 159
ericmc@usu.bitnet      Soon to be ericmc@cc.usu.edu      Logan, Utah  84321

UUCP: ...{psuvax1,uunet}!usu.bitnet!ericmc      "I'm going to leave before
Arpa: ericmc%usu.bitnet@cunyvm.cuny.edu     someone baptizes me or something."