gnu@hoptoad.uucp (John Gilmore) (12/02/86)
[This is posted to comp.lang.c because mod.std.c seems to be dead. Love
those mod groups!]
The standard's rationale tries to mark as "QUIET CHANGES" any change
in the definition of C that would make a previously working program
quietly take on some new meaning, without any warning or error report.
Unfortunately, they missed a few.
The new standard disallows an implementation's pre-#defining any words
that don't begin with _ (section 3.8.8, "No macro names without a
leading underscore shall be predefined."). This breaks all the code
that uses
#ifdef vax
or
#ifdef unix
or
#ifdef sun
or all the other little predefines we've come to know and love.
Of course, the committee can say "well, they can just change their
Makefile every time they port that code" but it is definitely a change
that breaks large bodies of existing code. Besides, do you want to
add -Dunix -Dsun -Dmc68000 to every compile you ever run?
One possible workaround is a set of configuration #define's which
are only visible to #if and #ifdef, not to program code. Yes, this is
a kludge, but I think it is less of a kludge than breaking all that code
or letting anybody predefine any name (the Main Computer Company will have
a rough time predefining #ifdef main...).
#pdefine sun
would cause #if sun or #if defined(sun) or #ifdef sun to be true, but
would not replace occurrances of "sun" in program text. Presumably an
implementation could more freely have a set of these "pdefines"
predefined, since they would not cause trouble to innocent program
code, just to innocent preprocessor lines.
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
"I can't think of a better way for the War Dept to spend money than to
subsidize the education of teenage system hackers by creating the Arpanet."ron@brl-sem.ARPA (Ron Natalie <ron>) (12/03/86)
In article <1379@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > #pdefine sun > > would cause #if sun or #if defined(sun) or #ifdef sun to be true, but > would not replace occurrances of "sun" in program text. Of course, no one said it had to be a macro definition. You could just say int sun; and the #if defined(sun) would also work. Of course, it takes up a few bytes. Too bad the compiler won't allow me to declare voids. -Ron
greg@utcsri.UUCP (Gregory Smith) (12/04/86)
>In article <1379@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: >> #pdefine sun >> >> would cause #if sun or #if defined(sun) or #ifdef sun to be true, but >> would not replace occurrances of "sun" in program text. > In article <500@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >Of course, no one said it had to be a macro definition. You could >just say > int sun; >and the #if defined(sun) would also work. Of course, it takes up >a few bytes. Too bad the compiler won't allow me to declare voids. > Baloney, the preprocessor doesn't know that 'int sun' has been defined. I like John's idea; it is not really a 'kludge' as he says; in fact the concept of using string-substitution symbols to control conditional compilation is the kludge, and the #pdefine would cure this. How do you define these in the command line? possibility: cc ... -Pfoo -Dbar -Dlimit=200 is equivalent to #pdefine foo #define bar 1 #define limit 200 but I have always thought there should be an explicit mechanism for importing stuff from the command line: cc -Dfoo -Dbar -Dlimit=200 combined with #conditional foo #parameter bar #parameter limit in the source, would be equivalent to the above defines. the '-D' symbols ( and any predefined stuff, 'unix' etc) would be waiting in the wings, so to speak, until activated by the #parameter or #conditional. It would be an error if a #parameter were applied to a symbol that wasn't 'waiting in the wings' -- the advantage of this is obvious. If you had a system that would compile on a vax or sun, you would have to put "#conditional vax/#conditional sun" at the beginning. If you compiled it on a 'widget', the definition of 'widget' would not take effect, hopefully causing a compile error, and forcing the user to take note that changes may be required, and to add "#conditional widget" after making those changes. Conditional switches could be implemented painlessly: #conditional vax,sun,widget could cause an error if none of the symbols are 'waiting'. ( if only one symbol is listed, and is not waiting, nothing happens). If more than one of the symbols is waiting, the first in the list *only* would be activated. Thus the programmer would be certain that exactly one of vax,sun,widget is defined. The mechanism will not allow site-dependant or command line defines, except those anticipated by the programmer, to have any effect on the program. This is the main advantage. Of course this breaks existing code; but it may be fixed by adding #parameters, and #conditionals to the code. These parameters and conditionals should be documented in comments anyhow, of course. -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...
bobr@zeus.UUCP (Robert Reed) (12/04/86)
In article <500@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >In article <1379@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: >> #pdefine sun >> >> would cause #if sun or #if defined(sun) or #ifdef sun to be true, but >> would not replace occurrances of "sun" in program text. > >Of course, no one said it had to be a macro definition. You could >just say > int sun; >and the #if defined(sun) would also work. Isn't the point of John's predefined macro to avoid changing the source code? With your suggestion of "int sun", the first step before compiling would be modifying the source files. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
karl@haddock.UUCP (Karl Heuer) (12/05/86)
In article <1379@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >The new standard disallows an implementation's pre-#defining any words >that don't begin with _ (section 3.8.8, "No macro names without a >leading underscore shall be predefined."). This breaks all the code >that uses ["#ifdef vax", etc.] I noticed this too, and wondered how we are expected to do architecture- dependent conditional compilation in the future. Perhaps the idea is to use "#ifdef _vax", etc. >One possible workaround is a set of configuration #define's which are only >visible to #if and #ifdef, not to program code. [Suggests "#pdefine vax"] This would still break the letter of the proposal. But if it's permitted, it's not necessary to make a new #-word; since macros cannot be recursive, "#define vax vax" will do. I believe the old V6 cpp allowed this sort of thing as a special case. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint