Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site hou2d.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V6#13 Message-ID: <549@hou2d.UUCP> Date: Wed, 29-May-85 18:42:21 EDT Article-I.D.: hou2d.549 Posted: Wed May 29 18:42:21 1985 Date-Received: Sat, 1-Jun-85 05:51:37 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 133 Approved: osd7@homxa.UUCP From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Wed, 29 May 85 Volume 6 : Issue 13 Today's Topics: Extensions limits.h type void ---------------------------------------------------------------------- Date: 28 May 1985 9:50 EDT From: a.reed@cbosgd.ATT.UUCP Subject: Extensions To: std-c@cbosgd Since the standard will allow compiler extensions, it needs a way to keep extensions from breaking code that conforms to the standard. I think that the best way to do this is an "extension" statement that might work as follows: Every program which uses an extension to standard C shall include a statement of the form "extension xtn_name;", where xtn_name is the name of the extension. A program without extension statements will be compiled in accordance with standard, unextended C. Words reserved in the implementation of any specific extension shall not be treated as reserved unless an extension statement specifying the use of that extension is included in the program. For example, let "cplspls" be the name of the extension from standard C to C++. If a compiler which accepts both standard C and C++ finds in a program the statement extension cplspls; it will compile this program according to C++. On the other hand, a program without extension statements will be compiled as a standard C program, with no special meaning attached to words which happen to be reserved in the implementation of C++. The upper-case equivalent of the name of each implemented extension shall be pre-defined in the compiler's pre-processor. For example, let "sepioadr" be the name of an extension supporting an "io" modifier for ports located on an Intel-style separate i/o address space. The following header fragment might be found in programs using this extension: #ifdef SEPIOADR extension sepioadr; #else #define io volatile #endif What do you think? Adam Reed AT&T Information Systems ihnp4!npois!adam ------------------------------ Date: 24 May 85 12:07:49 EDT (Fri) From: Craig Partridge Subject: limits.h To: cbosgd!std-c@BERKELEY I was re-reading the standard today and noticed a minor problem with the definition of . What happens if there is no limit; when there is no need for a limits value? The most obvious example, though I hate to bring it up because it will cause this issue to flame yet again, is identifier names. On compilers using flexnames the constant EXTERNAL_NAME_LENGTH will have no meaning. What does one do with it? Set it to -1, or not define it? I think we ought to have some answer to this issue -- code may be #ifdef'ed based on some of these values, and certain ones may be superfluous or worse, misleading, on some compilers. I admit that at this point I can identify only the name length definitions and the maximum chars on a line definition as potentially superfluous (and I personally wouldn't want anyone #ifdef'ing on these constraints), but, who knows, it may be that for some reason other constants turn out to be superfluous in odd situations. As an off the cuff suggestion, I suggest not defining the constant. Thus #ifdef EXTERNAL_NAME_LENGTH would suffice as a test to see if my compiler placed a limit on external name lengths. I'm amenable to better ideas. Craig Partridge craig@bbn-loki (ARPA) craig%loki.arpa@csnet-relay (CSNET) {decvax,ihnp4,wjh12}!bbncca!craig (USENET) P.S. My copy of the standard is as of February 11th, so it may be that this problem was fixed... ------------------------------ Date: Thu, 23 May 85 19:57:30 edt From: wanginst!mckeeman@bbncca Subject: type void To: ima!cbosgd!mark@bbncca.uucp My best guess for what is meant by type void is that it IS a type (like the standard says) and that it has NO values. I have a reason to want the below to work and assume that treating void as a first-class-type would not cause any existing code to break. Comments? From my reading of the February 11 standard the following should work. It does not on 4.2. void a() {return (void) 1;} main(){ void b; /* a variable requiring no storage */ int c; /* ...how about &b */ b = a(); /* an assignment generating no store */ if (b == (void) c) /* an always-false test */ b = (void) c++; /* only the increment gets done */ } /s/ Bill McKeeman at WangInst, ...decvax!wanginst!mckeeman ------------------------------ End of mod.std.c Digest - Wed, 29 May 85 18:10:51 EDT ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above.