Path: utzoo!mnetor!uunet!husc6!uwvax!umn-d-ub!umn-cs!hall!blu
From: blu@hall.cray.com (Brian Utterback)
Newsgroups: comp.arch
Subject: Re: Null-terminated C strings
Message-ID: <2447@hall.cray.com>
Date: 22 Dec 87 18:16:47 GMT
References: <261@ivory.SanDiego.NCR.COM| <164@sdeggo.UUCP> <174@quick.COM> <14116@think.UUCP>
Reply-To: blu@hall.UUCP (Brian Utterback)
Organization: Cray Research, Inc., Mendota Heights, MN
Lines: 20

In article <14116@think.UUCP| barmar@sauron.think.com.UUCP (Barry Margolin) writes:
|
|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.
|Barry Margolin

Amen to that.  I just spent hours trying to find out what was wrong with
a rasterfile to laserprinter filter.  It turned out that the problem is 
that fprintf cannot output a null.  At least the compiler should issue
a warning if it eats a null.  I mean, what is the use of being able to
specify a character in a string (i.e. \000) if the compiler won't really
use it?  And it KNEW it, and didn't tell me. Sheesh.