joemu@tekecs.UUCP (10/04/84)
I have a question that has sparked heated debate within the committee. Should benign (identical) redefinition of a macro be allowed? I think the current draft standard does not allow redefinition of a macro even if the definitions are identical, or if it does, the result of identical redefinition is implementation defined. The reasons for not allowing it are: 1. some implementations "tokenize" the file BEFORE preprocessing. It makes it very difficult to tell if the macro definition is identical to a previous definition. 2. several committee members felt that if you were defining a macro more than once, your source has gotten out of control and it would be benificial to know if your macro has been defined more than once. The reasons for allowing redefinition are: 1. It provides a facility to tell if two macros are identical - there is no other way (I think) 2. Benign redefinition does not hurt anything 3. A lot of U*IX code does it 4. If you want to diagnose benign definition it is easy to do with #ifdef foo die #endif
jim@ism780b.UUCP (10/08/84)
> 1. some implementations "tokenize" the file BEFORE preprocessing. It > makes it very difficult to tell if the macro definition is identical > to a previous definition. Why? The comparison should only be on the tokens. The SysV and later cpp strip leading and trailing blanks, strip comments, compress multiple blanks to a single blank, and then do the comparison. How is that different from "tokenizing"? > 2. several committee members felt that if you were defining a macro more > than once, your source has gotten out of control and it would be > benificial to know if your macro has been defined more than once. I wish the committee members would stop "feeling" and start standardizing. The vast majority of C programs pass through some flavor of the Reiser cpp. The first priority of the committee should be to establish the behavior of that cpp as a standard when it is not clearly buggy or semantically obtuse (expanding formals within strings is arguably semantically obtuse, but not very, and compatibility should take precedence over the committee's tendency to want to do language design). Had that been done from the beginning, implementations that cannot do x would never have been written, because they would have violated the standard. The only reason such implementations are being taken into consideration is because of vested interests of some members of the committee, not because of the interests of the C community at large. If 2. is really an issue, then the committee can recommend that an option be available which warns about identical repeated definitions. It should not be an error; it should not be the default. -- Jim Balter, INTERACTIVE Systems (ima!jim)
karsh@geowhiz.UUCP (Bruce Karsh) (10/08/84)
> From: Jeff Hanes (VLD/VMB) <jeffh@BRL-VLD.ARPA> > Are you asking for a vote? If so, here's mine: > 6 char externs: I vote that I never be forced into six character variable names again. I had enough of that when I used to program in FORTRAN. If manufacturers made the mistake of limiting their linkers to 6 character names, then it's their mistake and they'll just have to do something about it. Eventually they'll have to change anyways. Does anybody think 6 char names are adequate for the future? Suppose some manufacturers had a 2 character limit for external names. Would it make sense to define C with 2 character external names? (We'd really be compatible with Basic then (:-) ). Lets leave stone age baggage like 6 char variable names behind us. Bruce Karsh UW Madison, Dept. of Geology and Geophysics