Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pegasus.UUCP
Path: utzoo!linus!decvax!tektronix!uw-beaver!cornell!vax135!houxm!hogpc!pegasus!hansen
From: hansen@pegasus.UUCP
Newsgroups: net.lang.c
Subject: ANSI C and the C Pre-Processor
Message-ID: <1691@pegasus.UUCP>
Date: Thu, 6-Sep-84 15:25:53 EDT
Article-I.D.: pegasus.1691
Posted: Thu Sep  6 15:25:53 1984
Date-Received: Sun, 16-Sep-84 12:20:35 EDT
Organization: AT&T Information Systems, Lincroft NJ
Lines: 57

One of the minor(?) changes being proposed for the C standard is a change in
the C Pre-Processor to change it from a totally character oriented processor
closer to a token processor. It already does this to a certain degree by
recognizing comments as separate tokens that don't get scanned for text to
be replaced. However, this idea is being extended to include strings and
character constants as tokens that don't get scanned for replacement text.
The idea is to prevent bugs similar to the following:

#define foo(d,g)	printf("%d,%d", d, g)

This would expand 

	foo(f,e);

to

	printf("%f,%f", f, e);

and suddenly your integer variables f and e would be getting printed out in
%f format rather than %d format. Under the new rules, the expansion would be:

	printf("%d,%d", f, e);

This certainly solves the above problem. However, I have seen plenty of
programs which use some of the following constructs:

#define libpath(x)		"/usr/lib/x"
#define CTRL(x)			('x'&037)
#define PRINT1(format,arg)	printf("arg=%format.\n", arg);

A common place to find the libpath construct is in uparm.h used by (among
many others) the vi, curses, terminfo and termcap packages on both System Vr2
machines and 32V/BSD machines.

I don't know of any system code that depends on the CTRL example, but I know
of a number of people who have used it in the past.

Those of you who have read the C Puzzle Book will realize that NONE of Alan
Feuer's programs will work anymore!


The questions are: Should this change be endorsed? If so, what should be
done to bring back the lost functionality? If not, how would you make CPP
more regular in its scanning rather than that which is the de-facto standard
from Reiser?

One possibility would be to introduce a new construct #sdefine which has the
special property that strings and character constants would also be scanned
for replacement; otherwise it would be identical to #define. The programs
which use the above constructs would have to be changed to use #sdefine
instead of #define, but no other changes would have to be made.

Without something to replace the lost functionality, I feel that the number
of programs which would have to be changed would be major.

					Tony Hansen
					pegasus!hansen