expressions and #if - (nf)

jim at ism780b.UUCP jim at ism780b.UUCP
Thu Aug 2 14:19:23 AEST 1984


#R:sri-arpa:-183600:ism780b:25500011:000:3509
ism780b!jim    Jul 17 22:35:00 1984

The way I did this was to add a flag to cpp to only instantiate those
symbols given with -U and -D.  It was a lot of work.  I actually rewrote
cpp from scratch, since the original code was too sick to deal with directly.
I avoided all your questions of what the semantics of cpp are, by retaining
the behavior of the Bell version (I have source) when not clearly buggy and by
guaranteeing that my unifer and cpp had identical semantics by in fact being
the same code.  But, for specific answers:

>   (1) the unary operator ! is not included in the list of legitimate
>    operators.  This makes #if much less useful.  Any views on whether
>    this is intentional or just a typo?  Same question for && and ||.

Typo's.  Bell's cpp supports all the C operators, including "!", "&&", "||",
"?:", and ",".

>    (2) The Berkeley code seems to include a new macro operator
>    defined(x) which returns 1 if x is defined, 0 otherwise.
>    Is this now a generally accepted feature or just a Berkeley extension?

It is a general feature, and is in the SysV manual and the proposed
ANSI standard.

>    (3) the fact that two types of constants raises some interesting
>    troubles.  Is one required to support type casts in the
>    constant-expression?
    
Bell's cpp does not support type casts in #if expressions; since the only kind
of constants it deals with are ints (even if there is a trailing "l" or "L"!),
there isn't much point.

>    (4) Related to (3), must sizeof(expression) be supported?  If
>    so can "expression" be any expression or just a constant-expression?
>    Can "expression" contain type casts?

Bell's cpp does not support sizeof().  And it really should be
"sizeof lvalue" or "sizeof(type)".  There are no lvalues in cpp, and it
would not be reasonable for it to handle other than basic types without
being built into the compiler.

>    (5) /lib/cpp on 4.2 supports a few features that are not mentioned
>    in the standards.  For example, the comma operator is supported in
>    the constant-expression.  Are there other extensions people know
>    of -- are they generally accepted?

Berkeley hasn't added any functionality that wasn't in some Bell version.
And since there is no formal documentation of cpp, it is hard to talk
about extensions.  comma and defined have been there since the PTS
(slightly pre-V7) version; they just haven't ever been documented.

>    (6) A nice definitional problem to finish off the list.
>    #if is clearly a preprocessor statement.  But there is no
>    definition in the manual of how much the preprocessor is
>    supposed to know about.  The manual says simply that the preprocessor
>    is "capable of macro substitution, conditional compilation and
>    inclusion of include files."  No mention is made of expression
>    handling, although #if clearly requires it.  Just how bright
>    is the preprocessor required to be?

The brightness is determined by the functional spec, which includes
macro definitions and use ("macro substitution"), #if, #ifdef, etc.
("conditional compilation"; actually cpp isn't capable of any compilation at
all!), #include ("inclusion of include files" (like the Department of
Redundancy department?), and #if constant-expression, which certainly
implies "expression handling" (are you somehow expecting it to do something
with expressions elsewhere in the file?).  For the best (but not very good)
spec available, see the cpp.1 article in the SysV manual.

-- Jim Balter, INTERACTIVE Systems (ima!jim)



More information about the Comp.lang.c mailing list