jimb@hpfcdc.HP.COM (Jim Bigelow) (02/23/89)
I'm looking for comments and consensus of a suggestion for POSIX and
ANSI C conforming equivalents of cpp predefines. The table below shows
the existing redefined cpp symbols and POSIX/ANSI equivalents with any
discussion.
Existing POSIX/ANSI C Discussion
------------------------------------------------------------------
unix __unix I see this symbol as being
used to distinguish between
code for different operating
systems. As such, it would be
very useful when porting if
all implementations agree on a
common POSIX/ANSI C equivalent.
mert __mert
ibm __ibm
gcos __gcos
tss __tss
etc.
interdata __interdata
pdp11 __pdp11
u370 __u370
u3b __u3b
u3b5 __u3b5
vax __vax
etc.
RES _RES
RT _RT
TS _TS
PWB _PWB
etc.
Since lint(1) defines the preprocessor symbol lint when it runs cpp, I
don't think that lint should be transformed to __lint -- any comments?
Jim Bigelow
Colorado Language Lab, M.S. 96
Hewlett Packard
3404 E. Harmony Rd.
Ft. Collins, CO 80525
303-229-6251
... !hplabs!hpfcrt!jimbflaps@dgp.toronto.edu (Alan J Rosenthal) (02/24/89)
In article <12040014@hpfcdc.HP.COM> jimb@hpfcdc.HP.COM (Jim Bigelow) writes: >Since lint(1) defines the preprocessor symbol lint when it runs cpp, I >don't think that lint should be transformed to __lint -- any comments? I think it should. The advantage of not intruding in the user's name space is just as great when they're writing programs that they intend to lint as it is when they're writing programs that they do not intend to lint. (Besides, one should intend to lint all programs anyway.) The current lint documentation says: The preprocessor symbol "lint" is defined, in order to allow certain questionable code to be altered or removed for lint. Therefore, the symbol "lint" should be thought of as a reserved word for all code that is planned to be checked by lint. [Sun unix 3.5 man lint(1)] In my opinion this is a wart, at least these days if not in the first place. Get rid of it. To put it another way, people writing portable C programs should be able to lint them without having to write lint-ized C programs. Having to treat ``lint'' as a reserved word is writing a lint-ized C program. ajr -- "The goto statement has been the focus of much of this controversy." -- Aho & Ullman, Principles of Compiler Design, A-W 1977, page 54.
jagardner@watmath.waterloo.edu (Jim Gardner) (02/25/89)
[...] Our group at the University of Waterloo maintains a number of C compilers, and we have found the following scheme useful. We have two classes of definitions: machines and operating systems. This copes with the problem of machines that support several operating systems (e.g. PORT, DOS, XENIX on the PC) or operating systems that run on many different machines (UNIX on many kinds of hardware). We further differentiate between the HOST system (where the program is being compiled) and the TARGET system (where the program will run). This takes care of problems that may arise during cross-compilation. As a result, we have four sets of manifests, each beginning with a different prefix: _TS_ target operating system _TM_ target machine _HS_ host operating system _HM_ host machine This gives us a set of definitions like: _TS_UNIX _TM_I80286 _TS_GCOS8_NS _TS_GCOS8_SS /* etc. */ By the way, I put in the last examples to point out that "__gcos" is not a good name. Off the top of my head, I can think of GCOS-III (which ran an old Bell C compiler), GCOS-6 (runs on Bull DPS-6 minis), GCOS-7 (runs on Bull DPS-7 mainframes, and utterly different from any other operating system I've ever seen), and GCOS-8 (running on Bull DPS-8, DPS-8000, DPS-88, and DPS-90 machines, in two different modes that have entirely different sets of service calls). Bull calls all its operating systems GCOS, despite vast differences between them. Jim Gardner, University of Waterloo