Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ecr.UUCP
Path: utzoo!hcrvax!ecrhub!ecr!peterc
From: peterc@ecr.UUCP (Peter Curran)
Newsgroups: net.lang.c
Subject: Re: Can #define `token-string' be empty?
Message-ID: <104@ecr.UUCP>
Date: Thu, 21-Feb-85 05:40:24 EST
Article-I.D.: ecr.104
Posted: Thu Feb 21 05:40:24 1985
Date-Received: Sat, 23-Feb-85 02:30:28 EST
References: <800003@acf4.UUCP>
Organization: Emerald City Research Inc., Toronto
Lines: 30

Yes, in all versions of C I have used, the token string can be empty.
However, some version have a bug, which may or not be serious, depending
on the application.  The bug is in V7 UNIX, and variants derived from it.

The problem is that if you #undef a variable that has no value, the
preprocessor symbol table gets screwed up, and actually leaves the
symbol defined, but with its name pointer pointing into the 'stdio'
buffer of the source file.  Under various circumstances, if another
symbol occurs at the same place in the buffer (i.e. if it occurs at
the same place in the file, modulo the block size), the preprocessor
will fail to recognize that symbol, and if it should be preprocessed,
it gets passed through to the main compiler.

No doubt most users will not encounter the problem, because using symbols
with no value is unusual, and using #undef is probably even less common.
Even if you hit the problem, slight modifications to the source will
move things in the buffer and mask the problem.  We have some coding
conventions that call for both of these quite regularly, so it is
a nuisance.  Fortunately, we have found that in all cases where
we used an empty value, the value ';' would do just as well.

I no longer have access to UNIX source, but some time ago we discovered
the cause of the problem.  The function that handles undef's expects
a char parameter that tells it what to do.  The value for undef is
defined as 0xFF, which the author expected to be sign-extended, and
tested for as 'mode < 0'.  Of course, most machines do not sign-extend,
and even those that do treat 0xFF as an integer, not a character, and
don't sign-extend it.  Anyone with access to the preprocessor source
may want to fix this, and perhaps post a better description of the
solution than I can give.