flaps@utcsri.UUCP (Alan J Rosenthal) (01/20/87)
In article <5497@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn ) writes: >For example, the machine I'm preparing this response on would >predefine _sys_bsd43 and _mach_vax. Why _sys_bsd43 and not _sys_bsd but _mach_vax but not _mach_vax8600 (or whatever)? In current environments, often more things are predefined than just a machine name and a system name. Is there some way to specify that all larger groups of machines or systems that this is a component of should be defined? For example, there should be a full system name (bsd43), a system name missing any version number (bsd), and a generic system name (unix). The same could apply to machine names, of course. This still doesn't take care of things like UOFX_THINGGROUP. How common is this sort of thing (other groupings for conditional compilation besides systems and hardware)? Perhaps there should also be _group or _misc or something? Also, why lower case as opposed to the standard of caps for constants? ajr
vrs@omssw2.UUCP (01/26/87)
In article <3952@utcsri.UUCP> flaps@utcsri (Alan J Rosenthal ) writes: >In article <5497@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn ) writes: >>For example, the machine I'm preparing this response on would >>predefine _sys_bsd43 and _mach_vax. > >Why _sys_bsd43 and not _sys_bsd but _mach_vax but not _mach_vax8600 (or >whatever)? I think there is entirely too much emphasis placed on high level symbols (like bsd) where low level symbols (like SIGTSTP) are needed. I often see code that reads #ifdef SYSV ioctl(fd, TCGETA, &term); #endif when it ought (in my opinion) to read #ifdef TCGETA ioctl(fd, TCGETA, &term); #endif so that the test is for the existence of the feature, not some implicit assumption about the features present in a particular system. I'm not familiar with 4.3, but I'd bet most of the features that distinguish it from 4.2 also define lower level symbols which could be checked for instead of _sys_bsd43. Similarly, I usually don't really care if it is a VAX -- I care about the word order or some other low level features. Making the code dependant on these low level feature defines improves portability immensely, because now I can run on any system with the feature (say TCGETA instead of only on a particular OS (SYSV). (If my system has job control, the code will use it, even if the OS isn't BSD). -- Vincent R. Slyngstad Xenix Evaluation Engineering Intel Corporation (omssw2!vrs) "I am not now, nor have I ever been, a gloom cookie." What episode of a popular TV show is the above line from?
news@cit-vax.UUCP (01/27/87)
Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <556@omssw2.UUCP> vrs@omssw2.UUCP (Vincent R. Slyngstad) writes: >I think there is entirely too much emphasis placed on high level symbols >(like bsd) where low level symbols (like SIGTSTP) are needed. I often >see code that reads > #ifdef SYSV > ioctl(fd, TCGETA, &term); > #endif >when it ought (in my opinion) to read > #ifdef TCGETA > ioctl(fd, TCGETA, &term); > #endif Nothing assures the uniqueness of such symbols across implementations. TCGETA may exist and mean something entirely different on a non-SYSV machine. This can lead to really obscure bugs. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
gwyn@brl-smoke.UUCP (01/28/87)
The point about using lower-level "feature defines" like #ifdef TCGETA is well taken, but there is also use for higher-level non-feature conditionalization. For example, my most common conditional seems to be #if BRL_System_V_emulation_really_running_on_a_4BSD_kernel (or equivalent). I know of no reliable way to test combinations of features to determine high-level properties like that. I could also really use #if_header_exists "header_name" but I doubt we could come up with a good way to wedge this into C portably. However, there might be hope; a small subgroup of X3J11 is working on defining minimum syntax for portable filenames for use in #include "header_name" directives. Several of us feel that that is needed to plug a major hole in the facilities a maximally-portable C application can rely on.
judah@mrevox.UUCP (01/29/87)
While reading through the documentation of the "new make" from the AT&T toolchest, I find that it comes with a modified version of "cpp" which seems to address all the comments about "#defines" mentioned in the latest string of notes. To quote parts of the paper "The Fourth Generation Make" by Glenn S. Fowler: " ... The version of _cpp_ distributed with the _new_make_ also contains some changes that improve makefile portability. "#if" statements may use the following builtin tests: exists(file) - Returns 1 if _file_ can be found using the #include search rules. ... ... Additional function predicates are defined by "#assert" statements in the include file <default.h> which is automatically included by _cpp_ before the first input file is read. "#assert _predicate_(_value_)" makes assertions that can be tested in "#if" expressions. Such assertions are only recognized within "#if" expressions and do not conflict with "#define" variable expansions. Most assertions deal with the current machine environment: system(_system-name_) Defines the operating system name. Example values for _system-name_ are "unix" and "gcos". release(_system-release_) Defines the operating system release name. Example values for _system-release_ are "apollo", "bsd", ... ... " These extensions to CPP would allow any level of specification of the parentage of an operating system without having to resort to "_sys_unix_sysV_5_0_" or other such monstrosities. I am no expert on the fine points of C, but this proposal also looks upwardly compatible with existing usage. Anyone in a position to do so willing to propose this to the ANSI C committee? (Or is the idea copyright by AT&T??) Judah Greenblatt, Bell Communications Research, Morristown, NJ, USA (201)829-3059, judah@flash.bellcore.com, ...!bellcore!flash!judah P.S. Any other votes for adding "#elseif" to _cpp_??
guy@gorodish.UUCP (01/31/87)
>These extensions to CPP would allow any level of specification of the >parentage of an operating system without having to resort to >"_sys_unix_sysV_5_0_" or other such monstrosities. That presumes you have some centralized registry of those names, *and* that one name like that is adequate to categorize a system *and* convenient to use. OK, quick, what's a simple predicate equivalent to "does this system have 4.2BSD-style sockets"? Hint - "release(bsd4_2)", or something like that, isn't it. For one thing, 4.3BSD also has them; for another, plenty of systems that would probably advertise themselves as System V also do. The trouble here is that the question "is this System V", for example, isn't very interesting. "Is this system compliant with the SVID" might be, except that this doesn't tell you whether it has S5-style shared memory or not, since that's a kernel extension. "Does this system have S5-style terminal 'ioctl's", or "does this system call the 'search for a character within a string' function" "index" or "strchr" are more likely to be interesting. However, if most systems end up supporting the IEEE 1003.1 or SVID interface and ANSI C, the more interesting questions will be 1) "does this system support the minimal standard interface?" and 2-n) "does this system support some particular extension?" >P.S. Any other votes for adding "#elseif" to _cpp_?? No, but I'll certainly cast a very strong vote against it. ANSI C requires what is probably the same function (as I infer it from the name), but calls it "#elif". The S5R3 "cpp" already implements this. Any trivial aesthetic advantage of spelling out "else" is vastly outweighed by the effort involved in getting ANSI and the vendors that have already implemented this (I suspect more vendors than AT&T have), and the C programmers who have already used this, to go back and change things. (Yes, I know you can do both with a text editor; the aesthetic advantage is *still* outweighed by the effort involved.)