Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!pbox!okstate!gregg
From: gregg@a.cs.okstate.edu (Gregg Wonderly)
Newsgroups: comp.arch
Subject: Re: Null-terminated C strings
Message-ID: <2958@okstate.UUCP>
Date: 22 Dec 87 17:42:04 GMT
References: <14116@think.UUCP>
Organization: Oklahoma State Univ., Stillwater
Lines: 33

in article <14116@think.UUCP>, barmar@think.COM (Barry Margolin) says:
> 
> In article <174@quick.COM> srg@quick.COM (Spencer Garrett) writes:
>>2) Having a CHARACTER to mark the end of a string is ever so much
>>more convenient and efficient than having to compare lengths all the
>>time
> 
> The problem with this is that you must reserve a character.  I've had
> trouble with terminal emulators on machines whose keyboard-reading
> system call returns 0 to indicate that no data is available, but 0 is
> also the code for Control-@.  This type of problem occurs in file
> reading, too.  If you are reading a binary file, or perhaps a file of
> keyboard operations (perhaps you recorded an Emacs session), as
> characters the NULL character can no longer be used as a string
> terminator; such files can contain any 8-bit code, so NO 8-bit
> character can be used as a termination indicator.
> 
> Strings with lengths ALWAYS work.

Think about what you just said.  You applied negative comments to the use
of the zero byte in cases where you WOULD NOT use it.  All of the above
examples cite applications where you make use of system calls to read
a buffer of characters, and then process them one by one.  The point of
the zero byte is NOT to make EVERYTHING possible.  It is susposed to make
general string handling convienent, and that it does.

--------------
Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP:      {cbosgd, ihnp4, rutgers}!okstate!gregg
Internet:  gregg@A.CS.OKSTATE.EDU
IBM:       Yesterday's technology, tomorrow, for incredible prices