rfg@snuffy.rtp.dg.com (Ron Guilmette) (08/30/89)
I've just noticed a few unexpected things about the handling of -U and -D options by GCC and by the GNU C preprocessor. Before I describe these things, first let me ask everyone this question. What is your understanding of the "standard" effect of using a -U option with *no* sub-argument. It appears (from reading the Makefile for g++) that some/most/all C compilers and/or preprocessors accept a naked -U option. I had always believed that the "normal" effect of such an option would be to cause the "undefinition" of *all* predefined symbols. Did anybody else have this impression also? Anyway, the ability to wipe out *all* predefined symbols (whatever they may be) is (I think) an obviously useful feature, especially if you are cross-compiling. In such cases, you certainly don't want symbols from the host defined while you are compiling specifically for the target. So how can I get this effect when using GCC? I have taken note of the -undef option which the GCC driver passes on to the GNU preprocessor as a normal matter of course (and God help you if you should try to use some non-GNU preprocessor with the GCC front-end driver). Anyway, this option appears to be useless when it is supplied directly to GCC because the GCC front-end driver seems to totally ignore it (and thus never passes it on to GNU cpp, or to any other pass). Even if it were passed on to GNU cpp, I believe its intended effect would be effectively negated by the fact that GCC always generates its own list of "standard predefinitions" which it then (always) foists onto the (unsuspecting?) GNU cpp. In order to give the user more complete (and more standard?) control over *all* predefinitions of preprocessor symbols, I recommend the following: 1) Have GNU cpp recognize the "naked" -U option and have it respond by undefining all its own internal "standard" predefinitions. 2) Have GCC recognize the "naked" -U option, and have it respond by removing all of *its* "standard" predefinitions from the list of standard predefinitions which it normally supplies (as command line arguments) to GNU cpp. 3) Do away entirely with the (non-standard?) -undef option. In addition to the above suggestions, I believe that one more important change regarding the semantics of -U options should be made. Consider the following Makefile: CFLAGS=-Ddefault_target $(USER_CFLAGS) all: gorp gorp: gorp.o gorp.o: gorp.c In this Makefile, provision has been made for the user to *add* additional CFLAGS. Unfortunately, there is no way for the user to be able to exploit this provision to compile for a target other than the "default" one already specified in the Makefile. This forces the user to edit the Makefile for each different target. Drat! As a solution to this problem, consider this. If the processing of -D and -U options was done in a strictly left-to-right fashion, and if -U options were allowed to override *any* definition appearing to its left on the command line, then the above Makefile could be invoked as follows: make USER_CFLAGS="-Udefault_target -Dmy_new_target" or more briefly: make USER_CFLAGS="-U -Dmy_new_target" thus achieving the desired result *without* editing the Makefile. In order to make this "left-to-right" order-dependent processing work cleanly and consistantly, we would also have to agree that: a) all "standard" symbol predefinitions are (effectively) placed off to the *left* of all user supplied definitions (and undefinitions), and b) any "naked" -U option causes the undefinition of *all* definitions (both user and compiler supplied) which appear to its left. -------------------------------------- I request comments on the above proposals. If there is general support I will implement them and (of course) supply the patches free to all comers. P.S. I would also like it if people would try the "naked" -U option on your own "native" C compiler(s) and report back on the results of its use. Thank you. // rfg@dg-rtp.dg.com