Standardization questions (cpp mostly)

Martin Minow minow at decvax.UUCP
Fri Oct 5 10:29:49 AEST 1984


Here are some comments on Joe Mueller's recent submission, and a
question on just how # contatenation should work.  As you probably
know, I've been hacking at a public-domain cpp that will track most
of the Ansi standard (I've omitted things I believe are erroneous,
as will be noted).

1. Benign redefinition should be allowed without comment -- I usually put

	#define TRUE	1
	#define	FALSE	0

   in all of my programs, and have added it permanently to the Decus C
   stdio.h file -- seeing it twice with the same (textual) value shouldn't
   matter.  A different value should cause a warning message, but the
   compilation should proceed.  (Implementation dependent?)

2. Six-character globals are a way of life on Dec's RSX/RT11/RSTS
   operating systems and will stay that way for a while.  If you
   force a change, it will break the outside environment, which I
   don't believe is in the committee's charter.

3. Here are some things that I disagree with in the Standard cpp:
   1.	undefined token has the value zero (in #if's).  Cpp should
	print a warning -- or error if the evaluator is intelligent
	about statements like:
		#if defined (foo) && foo == 0
	My cpp prints a warning, as it erroneously evaluates the
	entire statement.

   2.	<backslash><newline> is "invisible" to all processing in
	the standard.  I regard it as "whitespace" outside of
	strings, and hence a token delimiter.  This greatly
	simplifies accurate error message generation.

   3.	The standard isn't clear about <form-feed> and <vertical-tab> --
	are they everywhere identical to <space>?  I.e. may they appear
	between the start of a line and the # that introduces a control
	statement?  The standard is also unclear about the action to be
	taken at the end of an include file:  is the <eof> a token delimiter?
	Does it terminate a line?

   4.	Just how invisible are comments?  For example, are the following
	correct?

		/* foo */ #ifdef foo
		# /* foo */ endif

   5.	cpp should accept "# <number>" as a synonym for "#line <number>"
	so that it accepts its own output format.

   6.	Some people write

		#ifdef foobar
		#endif foobar

	This should be provided for in the syntax -- or explicitly
	rejected.

   7.	I added __DATE__ to the preprocessor predefineds.  It's
	useful for embedding debugging status (but not essential).

   8.	I claim that nested comments /* ... /* ... */ warrant
	a warning message -- that is a very common source of
	error in the programs I see (and impossible to detect
	without a warning message).

Those are all the problems I have (today).  Here are some questions
about the new concatenation operation:

1.  May it appear anywhere, or only on a #define line?

2.  What are the semantics of, say,

	#define foo abc # def

    Is it (1) "foo";  (2) read "abc"; (3) read '#' and realize we're
    expanding a token, so (4) read "def" and glue them together?
    If so, what happens when "abc" or "def" are macro's:

	#define unique here # __LINE__

3.  May the #define token be concatenated:

	#define unique # counter __LINE__

4.  If I should write:

	#define unique_var	var # counter
	#define counter		(counter + 1)
	#define another_var	var # counter

    will cpp "do what I mean?"

Some guidance would be appreciated.

I just added stringization to Decus cpp and discovered something
interesting:

	#define print(format, value) printf("Result " "format", value)
	    print("%d", 123);

My first attempt expanded to

	    printf("Result " ""%d"", 123);

I've added a hack to strip one level of quotes, but aren't too
happy with it.  Note that you just can't omit the argument
quotes as you may want to pass ',' through.  Also, is this ok:

	    print('%d', 123);

In that case, I generate

	    printf("Result " "'%d'", 123);

without comment.

Here are one or two other suggestions (while I've got your attention):

The committee  might consider specifying the core run-time library
(str..., is..., the math routines, and a few others) such that the
compiler may generate in-line code or non-standard calling sequences.
There should be a way to override some or all of this, of course.
This was done for Fortran with no evil effects.

Martin Minow
decvax!minow



More information about the Comp.lang.c mailing list