Xref: utzoo comp.arch:3022 comp.lang.c:5882
Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: Null-terminated C strings
Summary: and their implications.
Keywords: C strings instructions architecture
Message-ID: <2033@geac.UUCP>
Date: 28 Dec 87 17:28:57 GMT
Article-I.D.: geac.2033
Posted: Mon Dec 28 12:28:57 1987
References: <14116@think.UUCP> <2958@okstate.UUCP> <152@piring.cwi.nl>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: The little blue rock next to that twinkly star.
Lines: 29

In article <152@piring.cwi.nl> jack@cwi.nl (Jack Jansen) writes:
| Even though I favour null-terminated strings myself...
[enumeration of booby-traps that catch C programmers]

| Moreover, the approach where the count is kept with the pointer
| has another *big* advantage: it unifies strings with other variable
| dimension arrays. Again, this is not a point that I feel very strong
| about myself (I don't think I *ever* inverted a matrix), but 
| it *is* rather stupid that you have to specify the dimensions of
| a matrix in a call some routine while the compiler knows those
| dimensions already....

  Agreed, but we're drifting away from the architecture question:
should we provide facilities for supporting array operations (search
string/array for terminator) or array descriptors (assign dope-vector 
slice n..m of array x).
  This question can become arbitrarily complex... and is herewith
cross-posted.
  In the meantime, I try to use C as a language to code **into** and
not **in**, so I can often (but not always) back out of
locally-unwise assumptions of the language designers.

 --dave (architecture X programming languages) c-b

ps: for people reading this in comp.lang.c, the discussion of the
strengths and weaknesses of lengths and terminating characters came
out of a discussion of what to put in hardware.  It is worth
reviewing, as this is **not** the religious discussion it might
appear at first glance.