Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC840302); site diku.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!diku!keld From: keld@diku.UUCP (Keld J|rn Simonsen) Newsgroups: net.lang.c Subject: ANSI C: CPP predefined constants vs.Message-ID: <420@diku.UUCP> Date: Thu, 18-Oct-84 20:47:25 EDT Article-I.D.: diku.420 Posted: Thu Oct 18 20:47:25 1984 Date-Received: Sat, 20-Oct-84 07:01:06 EDT Organization: DIKU, U of Copenhagen, DK Lines: 68 <> One thing I would like from the C standard, is that as much software as possible could compile *unmodified* on different processor types, under different families of operating systems, and under different levels of an operating system. This should be done by #ifdef-ing or testing on some well defined constants, which should be agreed upon (obviously!). Lately there has been some discussion on C preprocessor defined constants. Well this is good for thing as __LINE__ numbers and __DATE__ compiled, but for operating systems levels, processor type, machine brand etc. I think it is a very bad idea. I advocated a while ago on the net for use of the include file as a solution to some problems. I will elaborate a little more on this seen from an ANSI C standard point of view. I think it is a bad idea to have this information build in the C compiler. C is not the only systems language around in the Unix world, we also have Pascal and Modula-2. The ANSI C is not intended for use with the Unix system only, there are C compilers for CP/M, MS-DOS, OS/370, VMS etc, and all these systems surely have other systems programming languages interested in knowing OS level, processor type etc. This information should be stored in a *unique* place retrievable from all languages/ software interested, and all important site dependent information should also be collected here, so you only have one place to go when the ordinary system adminstrator installs his/her *binary* system. I think the way to configure in this one unique place should provide both for binary only and source systems. This boils down to #ifdef vs. getfoobar(3) techniques, and I think there is a place for obtaining information in both ways for the same item. E.g. nowadays we compile conditionally on the OS level V7/BSD/S5. Someday we may have a common object format and file system format constant over several levels of the OS, so the same application program could run with only minor actions to OS level differencies under these OSes. We also may have machines running several different flavors of an OS (e.g. 4.2BSD and System V) at the same time with only minor differences. A source system would be happy with some C preprocessor syntax like #define statements, and that could go for several other systems programming languages. The binary system would go for some termcap(5) like information base, it could perfectly be in *C header* syntax. We then just have to write info routines, e.g. defines(3) - get string value - and definen(3) - get num value - netnews is already distributed with such routines, and they are simple! We then would have one *unique* place to configure and seek for system dependent information for both source and binary systems. Using is simple (Unix style, folks!). Every system manager can edit this include file; it is not so easy to get information out of a binary file (like the kernel), or even change or add items in it. can exist easily on even V6, PWB and S5, and can easily be updated to include items like organization name needed for netnews, but not provided by any existing Unix OS in system calls. So we could eliminate ifdef-ed calls to gethostname(2), uname(2) and what they call it on IBM, Sperry (MSCON$) etc. I.e. simpler programs! Adding a file on an existing system is simple, so *existing* C compilers could easily be made to comform to the standard on this point, also on UNIX systems already in service. The problem of predefined constants unknown to a programmer is also quite simple to solve, you just don't #include ! So don't do it in CPP, use instead! Keld Simonsen, DIKU, U of Copenhagen ...decvax!mcvax!diku!keld