Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2919 for JMS@ARIZMIS; Fri, 18-APR-1986 22:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/18/86 at 23:43:59 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014522; 19 Apr 86 0:19 EST Received: from USENET by SMOKE.BRL.ARPA id a004803; 18 Apr 86 23:55 EST From: Tim Smith Newsgroups: net.lang.c Subject: Re: An amusing piece of code Message-ID: <1723@ism780c.UUCP> Date: 15 Apr 86 21:34:12 GMT To: info-c@BRL-SMOKE.ARPA In article <360@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: > >Assuming that you can't put BCD-common-code into a function, I >agree with everyone else that you should use [forward-referencing!] >goto's here, and [again] cite Prof. Knuth's _Structured_Programming_ >_with_Goto's_. One major problem is that this code jumps into blocks >[the effect of case C: and case D: ]. This is something that X3J11 >warns about. I thought K&R did, too; but I can't find it. It is >generally a bad practice, although most compilers seem to allow it >without too much trouble. At least in one case, jumping into blocks has been blessed by DMR, so I am not too worried about that. The problem with the goto versions is that one then has to think of a name for the label, and make sure one uses the same name in two places. Yuck-o! Here is a suggested form that should satisfy the goto supporters, and still not make me have to think of a name for the label: #define GOTO_THERE if(0){ #define THERE } switch(v) { case A; A-code; break; case B; B-code; GOTO_THERE; case C: C-code; GOTO_THERE; case D: D-code; THERE; /* the ; looks sort of like a : */ THERE; BCD-common-code; break; case E: E-code; break; } In real programs, one might have several groups of cases, each with different common code. Most of the methods suggested can get kind of ugly, with gotos all over the place. I think the best way is to probably have two switches, one after the other: switch(v) { case A: A-code; break; case B: B-code; break; case C: C-code; break; case D: D-code; break; case E: E-code; break; } /* * handle common code */ switch(v) { case B: case C: case D: BCD-common-code(); break; } This can be easily expanded, and I think it is pretty readable. Not that it can be expanded with a third switch to handle a third level of common code, etc. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2965 for JMS@ARIZMIS; Fri, 18-APR-1986 22:47 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/18/86 at 23:46:48 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014535; 19 Apr 86 0:20 EST Received: from USENET by SMOKE.BRL.ARPA id a004839; 18 Apr 86 23:57 EST From: Raver Dave Newsgroups: net.lang,net.lang.c Subject: Re: Re: ... C builtin functions? Message-ID: <601@ur-helheim.UUCP> Date: 16 Apr 86 17:36:45 GMT Xref: seismo net.lang:2421 net.lang.c:8745 To: info-c@BRL-SMOKE.ARPA In article <359@uvacs.UUCP> rwl@uvacs.UUCP (Ray Lubinsky) writes: >> >C has standard built-in functions???? >> >> It looks like a function invocation, and is known and understood >> by the compiler... > >The thing is, sizeof() evaluates to a constant *at run time*, just like >'c'<<3 or BUFSIZ . That makes it a pretty trivial function. All it >really does is give you a portable, automatic facility for referring to >system dependencies. > >Ray Lubinsky University of Virginia, Dept. of Computer Science < * italics mine * > sizeof and BUFSIZ and a good implementation of 'c' << 3 resolve to constants at *compile time*. No run time *evaluation* is necessary. -- "The Faster I Go the Behinder I Get" --Lewis Carroll Dave Carlson {allegra,seismo,decvax}!rochester!ur-valhalla!dave Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3280 for JMS@ARIZMIS; Fri, 18-APR-1986 23:13 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 00:12:34 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014609; 19 Apr 86 0:36 EST Received: from USENET by SMOKE.BRL.ARPA id a004594; 18 Apr 86 23:47 EST From: Chris Torek Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <961@umcp-cs.UUCP> Date: 16 Apr 86 22:41:58 GMT To: info-c@BRL-SMOKE.ARPA In article <577@ur-helheim.UUCP> badri@ur-helheim.UUCP (Badri Lokanathan) writes: >There are several ways of creating infinite loops: Namely, `while (1)' and `for (;;)'. (There are others, but these seem to be the nominal standard.) >... is there any reason (other than personal preferance) why one >would prefer to use any particular form? Some compilers generate a `test the constant 1' for the former sequence, and no test for the latter; but I imagine that by now this is rather rare. >I personally prefer the while(1) form since it seems to make better reading. Oddly enough, I prefer the other form, but for the same reason. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3326 for JMS@ARIZMIS; Fri, 18-APR-1986 23:18 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 00:17:25 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014612; 19 Apr 86 0:37 EST Received: from USENET by SMOKE.BRL.ARPA id a004615; 18 Apr 86 23:48 EST From: "Roger J. Noe" Newsgroups: net.lang.c Subject: Re: Re: Array of pointers to functions Message-ID: <663@riccb.UUCP> Date: 14 Apr 86 23:32:47 GMT To: info-c@BRL-SMOKE.ARPA > just what do you folks *do* when you try to construct a > declaration in C? This question is *not* rhetorical, nor intended as an > insult.... I'd really like to know how folks go about constructing > variable and type declarations in C. Please mail me your methods... > I'll post a summary if the response warrants it. > -- > Wayne Throop at Data General, RTP, NC Tough luck, Wayne, I feel like posting this. See article <662@riccb.UUCP> in net.sources. It's a shell program to convert words to C declarations or casts, somewhat similar to the CDECL seen on the net before but somewhat more portable and easier to modify. Hope it's some use to somebody. I welcome comments and suggestions regarding it. -- "Listen, in order to maintain airspeed velocity a swallow needs to beat its wings forty-three times every second. Right?" Roger Noe ihnp4!riccb!rjnoe Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3627 for JMS@ARIZMIS; Fri, 18-APR-1986 23:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 00:44:19 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014623; 19 Apr 86 0:44 EST Received: from USENET by SMOKE.BRL.ARPA id a005340; 19 Apr 86 0:18 EST From: robison@uiucdcsb.ARPA Newsgroups: net.lang.c Subject: Re: Byte order (or you are both wro Message-ID: <139200027@uiucdcsb> Date: 15 Apr 86 22:23:00 GMT Nf-ID: #R:rochester.ARPA:17162:uiucdcsb:139200027:000:461 Nf-From: uiucdcsb.CS.UIUC.EDU!robison Apr 15 16:23:00 1986 To: info-c@BRL-SMOKE.ARPA > CHALLENGE: Come up with a scheme for representing numbers, and a sorting > scheme in which numbers sort naturally. Your scheme must deal with variable > length character strings and variable size numbers. That is, you cannot > requires strings to be padded with nulls, or numbers to be padded with zeros. ... -4 = AAAAZ -3 = AAAZ -2 = AAZ -1 = AZ 0 = M 1 = Z 2 = ZZ 3 = ZZZ 4 = ZZZZ ... Arch D. Robison University of Illinois at Urbana-Champaign Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3947 for JMS@ARIZMIS; Sat, 19-APR-1986 00:10 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 01:10:24 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014619; 19 Apr 86 0:40 EST Received: from USENET by SMOKE.BRL.ARPA id a005175; 19 Apr 86 0:12 EST From: richw@ada-uts Newsgroups: net.lang.c Subject: Re: #define kinda stuff Message-ID: <10200041@ada-uts> Date: 15 Apr 86 14:24:00 GMT Nf-ID: #R:cwruecmp.UUCP:1458:ada-uts:10200041:000:1849 Nf-From: ada-uts!richw Apr 15 09:24:00 1986 To: info-c@BRL-SMOKE.ARPA I don't have any suggestions, but I might be able to provide some insight... I think it depends on your implentation of C. You see, it depends on what the "lexical analyzer" of your particular compiler does to the text in the C-preprocessor lines. It would seem that when you say: #define foo that this has the same effect as doing a global replace, as editors do, of "foo" with "". However, at least some compilers I know of first cut up "" into lexical tokens, i.e. it breaks up the text into identifiers, strings, special C symbols (like '{' and '}'), and so on. This sequence of TOKENS, (not simply the sequence of characters) is then used wherever "foo" is encountered (this is actually more efficient since lexical analysis of "" is then only performed once for each occurence of "foo"). The important point, though, is that most lexical analyzers throw away comments. So, if your compiler does this, I see little hope of EVER being able to re-define C's comment delimiters. Judging by your description of the various things you tried, it seems as if your compiler does indeed lex the text of a define, so if I were you I'd give up and REALLY start hacking with "sed" or something. By the way, you'd think that what C is supposed to do here is well- defined. Well, unless the standard that ANSI's working on does so, I know of no such clear definition. A while ago, I played with the idea of writing a lexer for C and discovered that there were some ambiguities (within Kernighan & Ritchie, at least) as to what #define REALLY means. You might want to check Harbison & Steele; that C text might make mention of this sort of thing (I, unfortunately, don't own a copy, but I've looked at it and it's usually more specific than K&R about most things). Hope this helped, Rich Wagner Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4059 for JMS@ARIZMIS; Sat, 19-APR-1986 00:23 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 01:16:50 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014663; 19 Apr 86 1:02 EST Received: from USENET by SMOKE.BRL.ARPA id a005724; 19 Apr 86 0:32 EST From: Gregory Smith Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <2554@utcsri.UUCP> Date: 13 Apr 86 08:58:45 GMT To: info-c@BRL-SMOKE.ARPA In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes: >> That may be the original practice, but the X3J11 (ANSI C) drafts, now quite >> clearly say that all functions defined in the library are reserved (ie, you >> can't redefine them), and may be builtin to the compiler. I believe that the >> /usr/group standard (& probably P1003) reserved every function from all major >> UNIX* variants. It may be that redefining these reserved library functions >> will continue to work in *YOUR* implementation, but it's not guaranteed. >> >Before I flame at the bogosity of this proposed madness, I will entertain >suggestions as to why this decision was made. Fire away. > >On another note, `sizeof' is NOT a builtin funxion. It is merely a funny >way of writing an implementation defined constant. > Many thoughts. First of all, when I read the suggestion that sizeof might be a builtin function, I definitely took that as a gag, and I am tired of reading about why it isn't. Secondly, Jim, you may be interested to know ( if you don't know already ) that, in Britain, the correctn't know already ) that, in Britain, the correct spelling of 'connection' is 'connexion'. :-) Why should library functions be reserved? I haven't seen X3J11 so I don't know which or how many functions they are going after, but on the surface it seems a good idea to reserve things like getc and printf and fopen and so forth. It will make it easier to port stuff - but on the other hand, like any standard, it may well stifle improvement. I don't think it would be smart to reserve the whole friggin' library, though - this is just silly. Does this include things like getenv and getppid and symlink that may not have meaning on a non-UN*X system? Suppose you had an OS where getc(f) could be done by sticking f in a register and executing a processor trap. A compiler recognizing built-ins could generate in-line code for this. On related point ( I'll explain why ), do y'all remember "Weird C behaviour"? One of the problems being that printf was being passed the wrong types? Well, lint can't catch this sort of thing because it is told by /*VARARGS*/ to keep its cotton-picken hands off any call of printf. Anyway, in order to check this, it needs to know (1) that printf,fprintf, sprintf are special cases, (2) how to interpret printf format strings. The format may be known only at run-time: printf(fmt_string,...). However, in view of the facts that printf's are frequent, and that mistakes in parameter types are fairly common, and that 95% of printf calls have string constants for formats, I would like to see lint do this. If the format parameter was not a string constant, you would be on your own of course. The following is a borderline case: printf( c<' '|| c>'\176'? "\\%3o":"%c", c); It would probaby be asking too much for lint to recognize what was going on, and then check *both* format strings - but it would be nice. I do the above sort of thing once in a while. Anyway, so whaddya think? Of course, the same sort of thing can be done for scanf - although this is used less commonly. If 'printf' and friends were to become *quote* built-in *unquote* functions, this addition to lint would be even more justified. Can you imagine redefining printf and then having lint tell you that your format string was out to lunch? Now for something completely different... From: g-rh@cca.UUCP (Richard Harter) > Grumble, grumble. Sorry, this is a real practical problem. > Let me give some context. Suppose you are doing a high speed > sort of character strings. Being a clever fellow you have > read the glossed over parts of the literature and have seen > that a math sort is O(n) rather than O(n log n). You also > notice that it is cheaper to compare 4 bytes at once with > an 32-bit integer compare than to make 4 byte compares. I'm not sure on this - isn't it ridiculous to do a mathsort of 32-bit ints? In O(n) above ( for the mathsort) doesn't n become 2^32 rather than the list size? If so, it would of course be even sillier for larger ( i.e. reasonably-sized ) char strings. 'Bye for now... -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith Unive Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4554 for JMS@ARIZMIS; Sat, 19-APR-1986 00:56 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 01:49:33 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014852; 19 Apr 86 1:54 EST Received: from USENET by SMOKE.BRL.ARPA id a006885; 19 Apr 86 1:16 EST From: cjl%iuvax.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Array of pointers to functions Message-ID: <9500031@iuvax.UUCP> Date: 14 Apr 86 17:14:00 GMT Nf-ID: #R:brl-smok:-239800:iuvax:9500031:000:951 Nf-From: iuvax!cjl Apr 14 12:14:00 1986 To: info-c@BRL-SMOKE.ARPA > I'm confused. How do you specify an array of pointers to functions? Do > you do it: > int (*foo[])(); > or do you do it: > int ((*foo)())[]; If C enforces postfix notations for all its declarations, the world will be more peaceful. Two of its declarators use postfix notation ( [] and () ), while pointer uses prefix notation ( * ). Confusion about declarator precedence will disappear IF we CHANGE the syntax of pointer declarator to a postfix notation. So when we speak "an array of pointers to functions", we can write down immediately as "int foo [] * ()". To face the reality in the C world, we translate the above back into " (* (foo [])) () ". (Parentheses are used here to avoid the precedence problem.) Remembering the rule that postfix declarators has higher priority than prefix declarators, we can save some of the parentheses as " (* foo []) () ". C.J.Lo UUCP : ...!iuvax!cjl ARPA : cjl@Indiana@CSNet-Relay Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4670 for JMS@ARIZMIS; Sat, 19-APR-1986 01:01 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 01:57:37 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014708; 19 Apr 86 1:18 EST Received: from USENET by SMOKE.BRL.ARPA id a005946; 19 Apr 86 0:43 EST From: Lawrence Crowl Newsgroups: net.lang.c Subject: Re: Byte order (or you are both wro Message-ID: <17312@rochester.ARPA> Date: 17 Apr 86 18:39:27 GMT To: info-c@BRL-SMOKE.ARPA >I wrote: >> CHALLENGE: Come up with a scheme for representing numbers, and a sorting >> scheme in which numbers sort naturally. Your scheme must deal with variable >> length character strings and variable size numbers. That is, you cannot >> requires strings to be padded with nulls, or numbers to be padded with zeros. Arch D. Robison wrote: >... -4 = AAAAZ -3 = AAAZ -2 = AAZ -1 = AZ > 0 = M 1 = Z 2 = ZZ 3 = ZZZ 4 = ZZZZ ... > An interesting solution. I totally failed to consider unary notations. Just to keep the answers honest, I will add the requirement that some efficient form of representation be used. Radix notation is efficient, but you are not required to use it. For extra credit, extend your notation to deal with non-integral values. This is easy under current notation if the integral part is the same. P -- Lawrence Crowl 716-275-5766 University of Rochester Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4754 for JMS@ARIZMIS; Sat, 19-APR-1986 01:08 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/19/86 at 02:06:50 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014870; 19 Apr 86 2:00 EST Received: from USENET by SMOKE.BRL.ARPA id a007403; 19 Apr 86 1:36 EST From: Tainter Newsgroups: net.lang.c Subject: Re: define kinda stuff Message-ID: <1818@ihlpg.UUCP> Date: 16 Apr 86 22:46:30 GMT To: info-c@BRL-SMOKE.ARPA > David Eppstein (eppstein@cs.columbia.edu, seismo!columbia!cs!eppstein) > writes (11 Apr 86 21:12:26 GMT) > > Obviously the right way to do this is the following: > > > > #define cat(a,b) a/**/b > > #define (-: cat(/,*) > > #define :-) cat(*,/) > The problem is to define '(-:' as '/*' (start of comment), and :-) '*/'. > Please correct me, but I feel this will not work. Either the cat-definition > will look like 'ab' when it is expanded - obviously wrong -, or it will > look like 'a/**/b', which is wrong also. If you get '//**/*' as the > expansion, this surely isn't a start of a comment. > The whole thing boils down to whether the preprocessor does recursive > deletion of comments, which it never has as far as I know. For example: > > /* if (variable != 21) { /* Test for ... */ > has always been a comment-line, where the first '/*' is an easy > way to discard the whole line. If you put another '*/' at the end of > the line, the 'syntax error' is very near... Ignoring the unportability of a preprocessor which accepts macros that are not identifiers. The assumption the above works on is that BOTH the preprocessor and the compiler extract comments. This is a VALID assumption which is very often violated in the name of efficiency. The compiler SHOULD strip comments even if the preprocessor does since you should not assume it will be preprocessed by a comment stripping preprocessor. But, SHOULD and does are different words. --j.a.tainter Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5030 for JMS@ARIZMIS; Sun, 20-APR-1986 10:21 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/20/86 at 09:36:00 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022204; 20 Apr 86 10:25 EST Received: from USENET by SMOKE.BRL.ARPA id a022063; 20 Apr 86 10:07 EST From: Gregory Smith Newsgroups: net.lang.c Subject: Re: define kinda stuff Message-ID: <2584@utcsri.UUCP> Date: 18 Apr 86 18:49:03 GMT To: info-c@BRL-SMOKE.ARPA In article <2604@brl-smoke.ARPA> see@NTA-VAX.ARPA (Stein-Erik Engbr}ten) writes: >The problem is to define '(-:' as '/*' (start of comment), and :-) '*/'. > >> Obviously the right way to do this is the following: >> >> #define cat(a,b) a/**/b >> #define (-: cat(/,*) >> #define :-) cat(*,/) > >The preprocessor doesn't allow '(-:' as a definition-name >(Berkeley 4.2/4.3). > >However, the program below doesn't do what it is supposed to either. >When the preprocessor has finished, you just get 'main() {'. > >-->#define cat(a,b) a/**/b >-->#define start_comm cat(/,*) >-->#define end_comm cat(*,/) >--> >-->main() >-->{ >--> start_comm This is a comment end_comm >--> cat(pri,ntf)("This is a nice one...\n"); >--> printf("Hello...\n"); >-->} True. > >When in a comment, no expansion is done! > >How do we then define something which is to end a comment? I would say >it is impossible, but is eager to hear of anybody who thinks otherwise. > >Stein-Erik Engbr}ten The following method is stolen from one of the winners of last years' obfuscated-C-code contest ( Col. G. L. Sicherman ): ------------------- funny.c ---------------- #define b * #define start_comm /b #define end_comm b/ main() { start_comm This is a comment end_comm printf("Hello...\n"); } -------- cc -E funny.c: -------------------- # 1 "funny.c" main() { /* This is a comment */ printf("Hello...\n"); } I guess it works because the pre-processor doesn't *know* it is in a comment. The '/*' doesn't appear until *after* the 'b' is expanded, and by then the pre-processor is past the '/', so the comment is not recognized. The following also works (and was used in Col Sicherman's winning entry): #define toggle_comment /b/ Of course, this method causes the pre-processor to pass your comments to the compiler proper. ( By the way, Col Sicherman won the 'worst abuse of the preprocessor' category ). -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1805 for JMS@ARIZMIS; Sun, 20-APR-1986 16:50 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/20/86 at 17:47:08 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024195; 20 Apr 86 18:30 EST Received: from USENET by SMOKE.BRL.ARPA id a024846; 20 Apr 86 17:44 EST From: "Bennett E. Todd III" Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <1444@ecsvax.UUCP> Date: 18 Apr 86 19:04:54 GMT To: info-c@BRL-SMOKE.ARPA I've always been fond of: ... #define EVER ;; ... for (EVER) { ... I know, it's terminally "cute". -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9464 for JMS@ARIZMIS; Tue, 22-APR-1986 04:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 05:32:17 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014562; 22 Apr 86 6:09 EST Received: from USENET by SMOKE.BRL.ARPA id a018854; 22 Apr 86 5:51 EST From: Lawrence Crowl Newsgroups: net.lang.c Subject: Re: Byte order (or you are both wrong) Message-ID: <17420@rochester.ARPA> Date: 21 Apr 86 13:32:12 GMT To: info-c@BRL-SMOKE.ARPA In article <2568@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <17162@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >>CHALLENGE: Come up with a scheme for representing numbers, and a sorting >>scheme in which numbers sort naturally. Your scheme must deal with variable >>length character strings and variable size numbers. That is, you cannot >>requires strings to be padded with nulls, or numbers to be padded with zeros. >How about prepending the digit count to big-endian digit strings? >so 32 and 126 become 232 and 3126, and a lexical comparison gives >3126 > 232. Of course, leading zeroes in the significand cannot be used. ... The problem with this scheme is that it assumes a constant size "length" field. This is the best that I have yet seen though. >>Note that many part numbering schemes have intermixed letters and digits. >But what significance do letters have? do you want them to be ignored, >or to be assigned a dictionary order with the numbers? This is part of the problem! >P.S. this rather obscure scenario hardly seems reason to state that >little- and big-endians are both wrong. Sort the following list of "words": 302, 3B2, -42, 132, 26, AD, ab, 74LS00 --The damn poster program wants more lines. --It says "more included lines than new next". --I've said all I want to say. --You want more lines? --Take this! --Feed it to your line eater! --Burp! -- Lawrence Crowl 716-275-5766 University of Rochester Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9841 for JMS@ARIZMIS; Tue, 22-APR-1986 05:06 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 06:02:13 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014641; 22 Apr 86 6:38 EST Received: from USENET by SMOKE.BRL.ARPA id a019375; 22 Apr 86 6:11 EST From: KW Heuer Newsgroups: net.lang.c Subject: void * Message-ID: <728@bentley.UUCP> Date: 22 Apr 86 03:45:37 GMT To: info-c@BRL-SMOKE.ARPA In article <1883@ucsfcgl.UUCP> ucsfcgl!arnold (Ken Arnold%CGL) writes: >Purists will note that I really should say > ptr = (some_type *) malloc(10 * sizeof *ptr); >But eventually malloc() will be of type "void *". Okay, enlighten me. When I first saw the idea of "void *" I thought it was to be a name for the most restrictive pointer type ("ALIGN *" for those who know the malloc source). Then when I rechecked, I found that it was a new name for the least restrictive pointer type, "char *". Now you seem to say that the cast operator is unnecessary in your example. I'd like some more detail about this beast. Specifically, suppose we have the following: void *v; char *c; short *h; ALIGN *a; Of the 12 nontrivial assignment statements, which ones will ANSI C accept without a cast? What will lint accept (with/without cast)? Currently lint warns about things like h=c because it doesn't know whether c is aligned properly for use as a short pointer. Thus every nontrivial use of malloc, even with the appropriate cast, generates a lint warning. This is why I thought that "void *" was going to mean "ALIGN *", which would be the appropriate return value for malloc(). (Also more efficient, on word-based machines.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0127 for JMS@ARIZMIS; Tue, 22-APR-1986 07:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 06:12:36 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa14648; 22 Apr 86 6:39 EST Received: from USENET by SMOKE.BRL.ARPA id a019394; 22 Apr 86 6:12 EST From: George Robbins Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <116@cbmvax.cbmvax.cbm.UUCP> Date: 21 Apr 86 20:05:31 GMT To: info-c@BRL-SMOKE.ARPA In article <117@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: > >do ... while(1); >while(1) ... >for(;;) ... > >are all widely-used idioms for unconditional looping in C. >I personally prefer the latter, but the choice is just a >matter of taste. Any reasonable compiler will generate >efficient code for all three constructs. #define loop for(;;) This is a clean way to do it, but be aware that there is no obvious stopping point, and soon C purists will soon be declaring that your code has been tainted by exposure to noxious influences from Algol 68 or worse... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0233 for JMS@ARIZMIS; Tue, 22-APR-1986 07:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 06:21:12 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014651; 22 Apr 86 6:40 EST Received: from USENET by SMOKE.BRL.ARPA id a019428; 22 Apr 86 6:13 EST From: KW Heuer Newsgroups: net.lang.c Subject: Re: Wayne Throop's declaration poll Message-ID: <731@bentley.UUCP> Date: 22 Apr 86 04:44:00 GMT Keywords: e2c To: info-c@BRL-SMOKE.ARPA In article <1436@homxb.UUCP> homxb!gemini (Rick Richardson) writes: >There was a memo on "e2c" and "c2e" at AT&T several years back. >You could type at it: > array of pointers to functions returning pointers to ints >And it would tell you what the declaration should look like. Trouble is, many people who can't get the declaration right without help would also have trouble phrasing it correctly in English. In particular, many people say "pointer to array of x" when they mean "pointer to first element of array of x", which is "pointer to x". Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3819 for JMS@ARIZMIS; Tue, 22-APR-1986 12:48 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 13:46:01 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028364; 22 Apr 86 14:24 EST Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a000640; 22 Apr 86 14:11 EST Date: Tue, 22 Apr 86 14:11:01 EST From: Doug Gwyn (VLD/VMB) To: KW Heuer cc: info-c@BRL-SMOKE.ARPA Subject: Re: void * You're mixing two features of malloc(). Malloc() should return (void *), which is a generic pointer type to/from which all other pointer types may be cast without loss of information. (This is the only use of (void *), and it is the only universal pointer type; other pointer casts can be non-portable.) Malloc() ALSO guarantees that the pointer it returns is suitably aligned for safe casting to ANY pointer type. This is a property of malloc(), not of (void *). Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5264 for JMS@ARIZMIS; Tue, 22-APR-1986 15:56 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 16:40:35 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004100; 22 Apr 86 17:24 EST Received: from brl-aos.arpa by SMOKE.BRL.ARPA id aa04750; 22 Apr 86 16:54 EST Received: from icst-cmr.arpa by AOS.BRL.ARPA id a003584; 22 Apr 86 16:37 EST Received: by icst-cmr.ARPA (4.12/4.7) id AA02558; Tue, 22 Apr 86 16:37:56 est Date: Tue, 22 Apr 86 16:37:56 est From: root Message-Id: <8604222137.AA02558@icst-cmr.ARPA> To: info-c@BRL.ARPA, roger@LL-SST.ARPA Subject: Re: C Builtin Funxions Cc: zben@UMD2.ARPA > From roger@ll-sst Sun Apr 20 15:31:29 1986 > > In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes: > > Some of us know what we're doing. One sees lots of redefinitions of > > things like `putc' in {VM,}UNIX code. It is often desirable to use > > high level funxions (printf) while hacking up a lower level one. > > Of course, you realize redefining putc will have no effect on printf... > > Wayne > > > Silly me! I *axually* believed the UNIX documentation! I quote from > > man 3 printf: > > > > ... Characters generated by printf are printed by putc(3S). > > "*Axtually* the documentation is correct!" [The sound of one defending > sacred writ from the unfaithful.] But, well, it's true. Printf does > call putc, but [I quote from man 3 putc]: > > ... BUGS > Because it is implemented as a macro, \fIputc\fR ... > > [a great place to find it documented, no?] and, better, but still not > in a place it will jump out at you, [man 3s intro]: > > ... The in-line macros \fIgetc\fR and \fIputc\fR(3S) handle characters > quickly. The higher level routines [list including printf] all use > \fIgetc\fR and \fIputc\fR ... > > Once putc has been expanded in-line, redefining it elsewhere won't have > full effect. Just as in your better example, you'd have to recompile > printf (and then where's portability? ...). > > Yrs, Roger Silly me! I *axually* goofed! I got confused between `putc' and `putchar', which altho defined as a macro, is also a real funxion as well because it predated the stdio library. Sigh. Allow me to start from square one and appeal to the higher principles I was attempting to demonstrate by my errant example. I don't want the compiler taking the liberty of expanding ANY funxions inline unless I direct it do do so via a macro or some kind of #pragma that specifys inline expansion! Compilers DO NOT know about specific funxion calls! Someone suggested that `putc' could put the char into a register and make a system call. So could `putc.s'. As for portability, I SUPPLIED the funxion with my code, so it does EXACTLY what I say it does. If it is legal portable C, it ports! As to my friend Ben Cranston's suggestion that I should use `myprintf' and `myputchar', this is a very good idea, lest we forget what the funxion really does. However, this may not always be an option where objects but no source is available. Hiya Ben! (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8090 for JMS@ARIZMIS; Tue, 22-APR-1986 23:02 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/22/86 at 23:35:04 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005778; 23 Apr 86 0:19 EST Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a008797; 23 Apr 86 0:09 EST Date: Wed, 23 Apr 86 0:04:53 EST From: Doug Gwyn (VLD/VMB) To: root cc: info-c@BRL-SMOKE.ARPA Subject: Re: lint >> Perhaps he should have said "There is really no justification >> for doing C software development on a system other than UNIX"? > Come on Doug, you don't *really* believe this, do you? Sure I do. Just because you build Chevrolets for a living doesn't mean you can't drive to work in a Mercedes. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9483 for JMS@ARIZMIS; Wed, 23-APR-1986 02:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 03:14:40 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006442; 23 Apr 86 3:59 EST Received: from USENET by SMOKE.BRL.ARPA id a009481; 23 Apr 86 3:44 EST From: Barry Shein Newsgroups: net.lang.c Subject: Re: Sorting ANYTHING Message-ID: <453@bu-cs.UUCP> Date: 22 Apr 86 02:31:52 GMT To: info-c@BRL-SMOKE.ARPA >If you're going to sort a small number of things, it doesn't really >matter what you use. If you're sorting lots of stuff, use a system >sort and save the maintainer the headache of reading *your* sort. > > (Root Boy) Jim Cottrell Or, if your system doesn't have a sort (or a useable sort) go to the library and find Quicker Sort in the ACM Collected Algorithms and copy the Fortran and Publication Algol code and go re-do it in whatever language you like, won't take long and it's short enough it requires no deep understanding. I did this for a bunch of people in a Chem dept who were using the VMS1.6 SORT command and saved them something like 98% of the time for sorting matrix elements (like from 30 minutes to 30 seconds or something like that) and became an instant hero...and I stole the code! Use the terrain. -Barry Shein, Boston University Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4322 for JMS@ARIZMIS; Wed, 23-APR-1986 12:19 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 11:45:17 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015775; 23 Apr 86 11:32 EST Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a017042; 23 Apr 86 11:19 EST Received: by icst-cmr.ARPA (4.12/4.7) id AA04449; Wed, 23 Apr 86 11:18:50 est Date: Wed, 23 Apr 86 11:18:50 est From: root Message-Id: <8604231618.AA04449@icst-cmr.ARPA> To: gwyn@BRL.ARPA Subject: Re: lint Cc: info-c@BRL-SMOKE.ARPA >> Perhaps he should have said "There is really no justification >> for doing C software development on a system other than UNIX"? > Come on Doug, you don't *really* believe this, do you? Sure I do. Just because you build Chevrolets for a living doesn't mean you can't drive to work in a Mercedes. What are you hinting at? (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6572 for JMS@ARIZMIS; Wed, 23-APR-1986 15:13 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 16:07:50 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012659; 23 Apr 86 10:11 EST Received: from USENET by SMOKE.BRL.ARPA id a015086; 23 Apr 86 9:54 EST From: david%ztivax.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Infinite Loops Message-ID: <8200004@ztivax.UUCP> Date: 22 Apr 86 11:36:00 GMT Sender: notes%unido.uucp@BRL.ARPA Nf-ID: #N:ztivax:8200004:000:110 Nf-From: ztivax!david Apr 22 12:36:00 1986 To: info-c@BRL-SMOKE.ARPA Another terminally cute infinite loop which was used in ratfor: repeat { ... } until (hell_freezes_over) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7179 for JMS@ARIZMIS; Wed, 23-APR-1986 16:24 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016657; 23 Apr 86 12:15 EST Received: from USENET by SMOKE.BRL.ARPA id a017763; 23 Apr 86 11:48 EST From: Frank Adams Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <1299@mmintl.UUCP> Date: 22 Apr 86 01:00:17 GMT To: info-c@BRL-SMOKE.ARPA In article <1444@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: > #define EVER ;; > ... > for (EVER) { > ... > >I know, it's terminally "cute". No, no, no. It's INterminally cute. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6618 for JMS@ARIZMIS; Wed, 23-APR-1986 16:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012728; 23 Apr 86 10:14 EST Received: from USENET by SMOKE.BRL.ARPA id a015090; 23 Apr 86 9:54 EST From: "Eugene D. Brooks III" Newsgroups: net.lang.c Subject: Re: lint Message-ID: <1391@lll-crg.ARpA> Date: 23 Apr 86 06:12:26 GMT To: info-c@BRL-SMOKE.ARPA > Perhaps he should have said "There is really no justification > for doing C software development on a system other than UNIX"? > >Come on Doug, you don't *really* believe this, do you? > > (Root Boy) Jim Cottrell > "One man gathers what another man spills" I can't speak for Doug, but Not for money, love, drugs or sex would I do software development on a system other than UNIX. The rest of you guys can suffer if you want to but I have seen enough pain in my lifetime. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6781 for JMS@ARIZMIS; Wed, 23-APR-1986 16:25 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 16:18:07 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013413; 23 Apr 86 10:33 EST Received: from USENET by SMOKE.BRL.ARPA id a015250; 23 Apr 86 9:59 EST From: herndon%umn-cs.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: net.lang.english? Message-ID: <1700008@umn-cs.UUCP> Date: 21 Apr 86 03:26:00 GMT Nf-ID: #N:umn-cs:1700008:000:330 Nf-From: umn-cs!herndon Apr 20 21:26:00 1986 To: info-c@BRL-SMOKE.ARPA Am ie too lait to joyn thu funnetik spelling kraiz? Seereeyuslee, this bizines uv spelling wurds kyootly seemz not too help kompreehenshun graitly. It duz, howevur, maik reeding poestings kwiet inturesting, and purhaps for that reezun shood be enkurrajd. Shood ie enkuruj a deebait, or hav ie sed eenuf? Roburt Hurndun Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6848 for JMS@ARIZMIS; Wed, 23-APR-1986 16:26 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013507; 23 Apr 86 10:35 EST Received: from USENET by SMOKE.BRL.ARPA id a015401; 23 Apr 86 10:02 EST From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Good code for sometimes shared case Message-ID: <2594@utcsri.UUCP> Date: 21 Apr 86 04:14:21 GMT To: info-c@BRL-SMOKE.ARPA In article <2600045@ccvaxa> aglew@ccvaxa.UUCP writes: >Structured programming != Gotoless programming Right on. What was really ironic about the original posting ( using if(0){...} ) was that it was obviously an attempt to avoid those satanic g*t*'s, and therefore wind up with structured code. However, the structure of the if's was twisted around the structure of the switch statement, so the result was worse (less structured) than being honest and using goto's. That was made possible by the lax rules applied to 'case' labels in C (as opposed to, say, Pascal). It was, in a way, analogous to while con1 ... if con2 ... end_while .. end_if Which could be made to work as a 'while' with a 'break' if compilers would allow it. I am not, of course, saying that they should. How about producing a warning if a case label is not *directly* inside the {}'s of the switch? -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7404 for JMS@ARIZMIS; Wed, 23-APR-1986 16:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 16:56:37 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa18458; 23 Apr 86 13:13 EST Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a018904; 23 Apr 86 12:55 EST Received: from acc.arpa by AOS.BRL.ARPA id a017549; 23 Apr 86 12:47 EST Date: 23 Apr 86 09:42:00 PST From: art@ACC.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: non UNIX C development To: info-c Reply-To: art@ACC.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA > Not for money, love, drugs or sex would I do software development > on a system other than UNIX. The rest of you guys can suffer if > you want to but I have seen enough pain in my lifetime. Unfortunately the real world has LOTS of non UNIX systems, many of which have or are getting C compilers. I would rather promote the development of decent languages and development tools for those systems than assume that everything can or will be done under UNIX. Since lint is based on a modified compiler front-end, I wonder why more of the C compiler vendors haven't developed lint-like (or even lint-compatible) tools based on their compiler technology. P.S. I frequently do use various UNIX variants as well as some non-UNIX systems. ------ Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7521 for JMS@ARIZMIS; Wed, 23-APR-1986 16:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 17:03:39 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022631; 23 Apr 86 15:31 EST Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a022934; 23 Apr 86 14:56 EST Received: by icst-cmr.ARPA (4.12/4.7) id AA04996; Wed, 23 Apr 86 14:56:59 est Date: Wed, 23 Apr 86 14:56:59 est From: root Message-Id: <8604231956.AA04996@icst-cmr.ARPA> To: brooks@LLL-CRG.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: lint > Perhaps he should have said "There is really no justification > for doing C software development on a system other than UNIX"? > >Come on Doug, you don't *really* believe this, do you? > > (Root Boy) Jim Cottrell > "One man gathers what another man spills" I can't speak for Doug, but Not for money, love, drugs or sex would I do software development on a system other than UNIX. The rest of you guys can suffer if you want to but I have seen enough pain in my lifetime. Ah, the beauty of ambiguity. Let's play `Comverses & Inverses'. I read his statement as `If you don't have UNIX, don't use C'. I beg to differ. If I was stuck on VMS for some reason, I would much rather use C than Fortrash, Trashcal, ADA, or Ignorance (Bliss). I leave it up to Doug to explain his analogy with automobiles. I agree with 3 out of your 4 criteria. I have enuf money, love, & sex, but I'm running out of drugs :-) (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6698 for JMS@ARIZMIS; Wed, 23-APR-1986 16:27 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 16:16:08 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012827; 23 Apr 86 10:16 EST Received: from USENET by SMOKE.BRL.ARPA id a015100; 23 Apr 86 9:55 EST From: Sam Kendall Newsgroups: net.lang.c Subject: Followup to Very Tough C Riddle Message-ID: <140@delftcc.UUCP> Date: 22 Apr 86 02:35:42 GMT To: info-c@BRL-SMOKE.ARPA Here is the followup to my "Very Tough C Riddle". The riddle was posted about a hundred years ago. Thanks to harvard!draves, Ron Natalie , Tony Li , vu44!jack, enmasse!mike, hadron!jsdy@seismo.ARPA (Joseph S. D. Yao), qtlon!ist!istbt!rb, and callan!tim (Tim Smith) for replying, and my apologies for the long delay in posting this followup. Here is the original note: > Is the token sequence > > [ ] [ ] > > legal anywhere in a C program as defined in K&R? If so, where > and why? If not, why not? > > Warning: some may consider the solution debatable, although I > will endeavor to prove them wrong, i.e., I am pretty sure I > have the correct answer. Now, on to the solutions. The answer is YES, contrary to plenty of replies! (Except that the word "anywhere" in the note should be "somewhere", as Tim Smith pointed out.) To see this, we don't have to depend on my debatable solution; qtlon!ist!istbt!rb provided a clear solution that no one else (including myself) thought of: > How about: > > /* [ ] [ ] */ > " [ ] [ ] " > > or (more seriously): > > #define FRED [ ] [ ] > > where FRED does not appear elsewhere. In the FRED line, `[ ] [ ]' is indisputably a token sequence, for K&R section 12.1 gives the syntax of such lines as `#define identifier token-string'. (The reason, of course, that rb isn't serious about the first two is that in a comment or a string, the brackets are not a "token sequence", only part of a single token.) Even though it's not necessary for the riddle's solution, let's take a look at the other possibility, which is for there to be a formal parameter declaration of the form type formal[][]; Tony Li and Joe Yao mentioned this possibility, but they didn't think it was legal. The passage mentioned in K&R that many people think prohibits any adjacent pairs of empty brackets is this: When several adjacent "array of" specifications are adjacent, a multi-dimensional array is created; the constant expressions which specify the bounds of the arrays may be missing only for the first member of the sequence. (section 8.4) The passage that may allow `[ ] [ ]' for formal parameters is this (first elipsis mine): ... [D]eclarations of formal parameters declared "array of ..." are adjusted to read "pointer to ...". (section 10.1) This passage is why, in my interpretation, type formal[][]; "is adjusted to read" type (*formal)[]; This second type is "pointer to array of unknown length". However strange the idea of a pointer to an object of unknown length, note that this type is legal according to section 8.4, as quoted above. There is a sequence of one "array of" specification, and the bounds are missing only for the first (and only) member of the sequence. (Aside: this type is also usable, since you don't need to know the length of an array to access it. I have seen it, for you trivia fans, used erroneously in the System V Release 0 semop(2) man page and lint library entry. A question for debate: should it be legal in ANSI C? I can see both sides of the question.) The question, then, is whether 8.4 supercedes 10.1, whether the type of a formal argument has to be legal before as well as after it is rewritten. I was going to argue that it does not have to be, and if I were in a debate, I would keep going. But I have convinced myself that the question is, at best, up in the air. No sane programmer would intentionally write a formal argument declaration with `[ ] [ ]', even with one pair of braces hidden by typedefs. Even as an academic exercise -- which is all this article is, of course -- I can't stomach arguing for this dark corner of C. There is an interesting question about whether to consider dark corners to be in a language or not, but that question is beyond the scope of this article. ---- Sam Kendall { ihnp4 | seismo!cmcl2 }!delftcc!sam Delft Consulting Corp. ARPA: delftcc!sam@NYU.ARPA Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8214 for JMS@ARIZMIS; Wed, 23-APR-1986 17:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/23/86 at 18:26:22 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a025362; 23 Apr 86 19:08 EST Received: from wiscvm.wisc.edu by SMOKE.BRL.ARPA id a026426; 23 Apr 86 18:10 EST Received: from (MAILER)TCSVM.BITNET by WISCVM.WISC.EDU on 04/23/86 at 17:12:34 CST Received: by TCSVM (Mailer X1.22) id 0752; Wed, 23 Apr 86 12:34:54 CST Date: Wed, 23 Apr 1986 12:19 CST From: Dan Smith Subject: Re:Re: C work under/not under Unix To: INFO-C@BRL-SMOKE.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA >> Perhaps he should have said "There is really no justification >> for doing C software development on a system other than UNIX"? > Come on Doug, you don't *really* believe this, do you? I'm just leaping in on the discussion, but as someone who has done C software development on CP/M-80/86 and MSDOS before I could afford a Unix machine, I can tell you that even C minus the Unix is a pleasure when compared to what's loose in the world of Micros (and even Mainframes) Of course you end up re-inventing the wheel alot with little utilities to fake some Unix feature, but it is still VASTLY better then changing mental gears for different languages on different machines. Even now I use the WATCOM C compiler at work when I have a chance even tho its pretty much a bust as far as standard lib functions working the expected way. Compared to the everpopular LBT assembler (Large Blue Thing) I'll live with weirdness in order to get a sorta Unix environment to do projects. Dan Smith (aka MadMan) BITNET: SYSBDES@TCSVM ARPA: SYSBDES%TCSVM.BITNET@WISCVM.WISC.EDU UUCP: You Tell Me?? Ma Bell: (504) 865-5631 Real Paper: Tulane University Tulane Computer Services Attn: Dan Smith, Systems Group 6823 St. Charles Ave. New Orleans, LA 70118-5698 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6054 for JMS@ARIZMIS; Fri, 25-APR-1986 14:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/25/86 at 14:52:55 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a025824; 25 Apr 86 13:24 EST Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a025527; 25 Apr 86 12:23 EST Received: from bbn-prophet.arpa by AOS.BRL.ARPA id a024151; 25 Apr 86 12:20 EST Date: Fri, 25 Apr 86 12:10:59 EST From: Dan Franklin To: LINNDR%VUENGVAX.BITNET@wiscvm.ARPA cc: INFO-C@BRL.ARPA Subject: Re: WHAT DOES NARGS() DO? The short answer is, nargs() does nothing, now, and you are unlikely to find it on any modern "UNIX brand operating system." Don't use it. To quote the 6th edition manual page, "altogether it is best to avoid using this routine and depend on, for example, passing an explicit argument count." In 6th edition UNIX, nargs() returned the number of arguments on the stack. Well, not quite: it returned the number of *words* of arguments on the stack; you needed to know already whether the arguments were ints (1 word) or doubles (4 words) or the new-fangled, partially-implemented "long" datatype (also 2 words). Even in 6th edition nargs() was falling out of favor, as the manual page implies. Its main problem then was that it didn't work in separate I & D space, which was becoming quite popular as programs grew too large to fit in 64kbytes (48kbytes for text and data). It was also a bit sluggish, and those of us who looked inside it never really felt comfortable with it either. As the old "dragon book" said in a footnote, "... argument counts are obtained by a method we shall not discuss." The method was to peek at the instruction stream immediately following the JSR and decode the instructions to see how many words were popped off the stack immediately following the call. There was a potential off-by-one problem because the top of the stack was normally kept "empty"; you could call a routine with one argument without doing a push of the argument. So the compiler chose one of two equivalent forms of addressing for the destination to indicate to nargs() whether or not it should add 1 to the number of popped words. Nargs() understood that the compiler might pop the stack using either explicit stack pointer arithmetic or instructions that popped the stack as a side effect ("cmp (sp)+, (sp)+" was good for two words). To handle some kinds of optimization, nargs() was capable of following jump instructions. I think it stopped at the first instruction that wasn't a kind of pop or a jump. In separate I&D space this didn't work because in user mode on a PDP-11, a program couldn't read its own instruction space: instructions and data occupied the same "addresses". In theory you could use the MFPI (move from previous instruction space) instruction to get around this, but in practice you would find that DEC had specially prohibited this, even when both the current and previous instruction spaces were user mode. I think this was intended as a kind of "security". Some organizations solved the problem by cutting a trace on one of the processor boards, which was all it took to make nargs() work using MFPI. It is amusing to note that the wait() system call in the V6 library used nargs() to determine whether it was being called with 0 or 1 arguments. The first time we tried running a program that used wait() in separate I&D space, we got quite a surprise! Dan Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5095 for JMS@ARIZMIS; Sat, 26-APR-1986 18:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/26/86 at 19:34:32 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009042; 26 Apr 86 20:23 EST Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a012531; 26 Apr 86 20:12 EST Received: from cit-hamlet.arpa by AOS.BRL.ARPA id a009019; 26 Apr 86 20:12 EST Received: from Xhmeia.Caltech.Edu by Hamlet.Caltech.Edu with DECNET ; Sat, 26 Apr 86 17:13:58 PST Date: Sat, 26 Apr 86 17:08:27 PST From: zar%Xhmeia.Caltech.Edu@cit-hamlet.ARPA Subject: VAX VMS C Question To: info-c@BRL.ARPA X-ST-Vmsmail-To: ST%"info-c@brl.arpa",ST%"info-vax@sri-kl.arpa" I'm trying to convert some C code I have to VAX-11 C and there appears to be no VAX-11 C system routine FGETS (three args ; buf, sizofbuf, filepointer). Has someone already made this so I don't have to do it myself (I'm not a real C programmer). Please reply directly to me and thanks in advance. Zar (Dan Zirin) ZAR%XHMEIA@HAMLET.CALTECH.EDU (ZAR%XHMEIA@HAMLET.ARPA) Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6045 for JMS@ARIZMIS; Sat, 26-APR-1986 22:09 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/26/86 at 23:07:26 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009325; 26 Apr 86 23:56 EST Received: from USENET by SMOKE.BRL.ARPA id a013365; 26 Apr 86 23:41 EST From: mcdaniel@uiucdcsb.ARPA Newsgroups: net.lang.c Subject: Re: net.lang.english? Message-ID: <139200029@uiucdcsb> Date: 22 Apr 86 03:05:00 GMT Nf-ID: #R:umn-cs:1700008:uiucdcsb:139200029:000:59 Nf-From: uiucdcsb.CS.UIUC.EDU!mcdaniel Apr 21 21:05:00 1986 To: info-c@BRL-SMOKE.ARPA Goe too net.lang too diskuss thyss. net.lang.c iz fore C. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6080 for JMS@ARIZMIS; Sat, 26-APR-1986 22:12 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/26/86 at 23:09:48 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009327; 26 Apr 86 23:56 EST Received: from USENET by SMOKE.BRL.ARPA id a013523; 26 Apr 86 23:47 EST From: KW Heuer Newsgroups: net.lang.c Subject: Re: Jumping into blocks Message-ID: <737@bentley.UUCP> Date: 23 Apr 86 16:34:14 GMT To: info-c@BRL-SMOKE.ARPA In article <275@copper.UUCP> copper!stevesu (Steve Summit) writes: >Most people agree that goto's are pretty acceptable for handling >error conditions. For instance: > > if(stbuf.st_uid != getuid()) { >nope: printf("I don't think you want to delete this file.\n"); > return; > } > if(strcmp(name, "vmunix") == 0) goto nope; > unlink(name); > return; As has been pointed out, this particular example can be handled easily with the || operator. But here's a real example I keep running into: while (argc > 1 && argv[1][0] == '-') { switch (argv[1][1]) { ... default: usage: fputs("usage: a.out [flags] args\n", stderr); exit(1); } --argc; ++argv; } if (!aflag && !bflag && !cflag) goto usage; A trivial variation is to have "goto usage" after "default:" and put the actual usage message inside the "if" -- this makes it a forward goto, but still into a block. So, assuming that goatooze are acceptable for error handling, but jumping into a block is forbidden, what's the best way to write this? Use two braches, and hide the common code at the bottom of main()? Set an error flag and test it outside the while? (Ugh, that requires an artificial boolean *and* a break statement.) Make usage() a non-returning function instead of a label? (My usual preference.) Duplicate the code? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6245 for JMS@ARIZMIS; Sat, 26-APR-1986 22:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/26/86 at 23:34:33 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009419; 27 Apr 86 0:24 EST Received: from USENET by SMOKE.BRL.ARPA id a013966; 27 Apr 86 0:06 EST From: Pete Holzmann Newsgroups: net.wanted,net.lang.c Subject: WANTED: 68K C crosscompiler}i that runs on miscellaneous machines... Message-ID: <203@octopus.UUCP> Date: 24 Apr 86 01:39:14 GMT Xref: seismo net.wanted:9289 net.lang.c:8868 To: info-c@BRL-SMOKE.ARPA I'm looking for a good (ANSI?... optimizing... etc) cross compiler for the 68000/68010/68020. I need one that will run on DG MVxxxx machines, and hopefully PC's (obviously two different compilers). Professional developmnet quality products are needed (lint, etc). What is available? Has anybody used such products from MicroTec}i or Whitesmiths? Please mail any responses. I'll summarize if there is interest! -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hplabs!hpdsd,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8275 for JMS@ARIZMIS; Sun, 27-APR-1986 03:44 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 04:37:42 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010131; 27 Apr 86 6:27 EDT Received: from USENET by SMOKE.BRL.ARPA id a016619; 27 Apr 86 6:01 EDT From: "Bob Mabee, Software" Newsgroups: net.lang.c Subject: Re: Re: Float Double Parameters Message-ID: <844@frog.UUCP> Date: 22 Apr 86 19:58:40 GMT Keywords: BCPL To: info-c@BRL-SMOKE.ARPA In article <139200025@uiucdcsb> kenny@uiucdcsb.CS.UIUC.EDU writes: > When BCPL was built for the >635, it borrowed the existing Fortran library and hence had to adopt the >convention that all float's are promoted to double's for parameter passing. When DMR put an obsolete version of BCPL on the GE 645, it had no support for floating-point operations. We added floating-point operators and constants during the port from CTSS to the 360. Later I wrote a new code generator for the GE 645 (the first BCPL to generate binary directly), and added the floating-point operators here too, and transcendentals written in BCPL. Other functions would have come from the PL/I Multics environment, which did support single precision. In any case, BCPL is typeless and would not have known to convert number formats on function calls. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8449 for JMS@ARIZMIS; Sun, 27-APR-1986 03:56 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 04:55:16 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010158; 27 Apr 86 6:41 EDT Received: from USENET by SMOKE.BRL.ARPA id a017059; 27 Apr 86 6:18 EDT From: Ben Cranston Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <929@umd5.UUCP> Date: 24 Apr 86 01:59:39 GMT To: info-c@BRL-SMOKE.ARPA In article <205@brl-smoke.ARPA> rbj@icst-cmr.ARPA (root) writes: >As to my friend Ben Cranston's suggestion that I should use >`myprintf' and `myputchar', this is a very good idea, lest we >forget what the funxion really does. However, this may not always >be an option where objects but no source is available. Hiya Ben! Oh, good, I had so hoped you would not be offended by my implicit criticism of your earlier posting. I had taken precautions against my being taken too seriously, but the postnews software removed my precaution from the header of the message: Organization: Great Eastern Cow College Home for the Terminally Analytical Remember, "When Source is outlawed, only outlaws will have Source"... > (Root Boy) Jim Cottrell -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8414 for JMS@ARIZMIS; Sun, 27-APR-1986 03:57 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 04:53:20 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010156; 27 Apr 86 6:40 EDT Received: from USENET by SMOKE.BRL.ARPA id a016881; 27 Apr 86 6:11 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: void * Message-ID: <743@bentley.UUCP> Date: 24 Apr 86 18:59:13 GMT To: info-c@BRL-SMOKE.ARPA In article <200@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >You're mixing two features of malloc(). Malloc() should return (void *), >which is a generic pointer type to/from which all other pointer types >may be cast without loss of information. (This is the only use of >(void *), and it is the only universal pointer type; other pointer >casts can be non-portable.) Malloc() ALSO guarantees that the pointer >it returns is suitably aligned for safe casting to ANY pointer type. >This is a property of malloc(), not of (void *). I realize that; it's just that I was expecting the new datatype to correspond to this property of malloc(), so malloc() wouldn't have to be a special case. I probably shouldn't have brought up this (ALIGN *) issue in the same posting. It's *not* true that (void *) can always be cast into another pointer type without loss of information. For example, "intp = voidp;" may drop bits if "voidp" was initialized to an improperly aligned object. What's true is that any pointer may be assigned *to* a void pointer, and that *same* value may be safely copied back. (Currently this is a guaranteed feature of (char *).) To rephrase my original question, what does this have to do with the explicit use of the cast operator? Is "intp = voidp;" going to be as acceptable as the (more correct, to me) syntax "intp = (int *)voidp;"? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8489 for JMS@ARIZMIS; Sun, 27-APR-1986 04:01 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 04:59:17 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010161; 27 Apr 86 6:43 EDT Received: from USENET by SMOKE.BRL.ARPA id a017279; 27 Apr 86 6:27 EDT From: Ken Arnold%CGL Newsgroups: net.lang.c Subject: Re: void * Message-ID: <9831@ucsfcgl.UUCP> Date: 24 Apr 86 19:36:56 GMT To: info-c@BRL-SMOKE.ARPA In article <728@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <1883@ucsfcgl.UUCP> ucsfcgl!arnold (Ken Arnold%CGL) writes: >>Purists will note that I really should say >> ptr = (some_type *) malloc(10 * sizeof *ptr); >>But eventually malloc() will be of type "void *". > >Okay, enlighten me. When I first saw the idea of "void *" I thought it was >to be a name for the most restrictive pointer type ("ALIGN *" for those who >know the malloc source). Then when I rechecked, I found that it was a new >name for the least restrictive pointer type, "char *". Now you seem to say >that the cast operator is unnecessary in your example. I'd like some more >detail about this beast. Specifically, suppose we have the following: > void *v; > char *c; > short *h; > ALIGN *a; >Of the 12 nontrivial assignment statements, which ones will ANSI C accept >without a cast? What will lint accept (with/without cast)? Well, as *I* understand it (and my draft is, of course, out of date), (void *) can be cast to any other pointer type without complaint. So ptr = malloc( ... ); would be as legal as int_var = float_var; i.e., the conversion would be automatic and silent (because it is guaranteed to work properly). Presumably, any other pointer assignment would generate a warning unless accompained by a cast (and I sure hope it is silent if I explicitly cast it). Ken Arnold Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8599 for JMS@ARIZMIS; Sun, 27-APR-1986 04:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:11:46 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010174; 27 Apr 86 6:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a017467; 27 Apr 86 6:35 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: Re: varargs Message-ID: <5336@alice.uUCp> Date: 22 Apr 86 06:00:03 GMT To: info-c@BRL-SMOKE.ARPA > Must va_alist be the only thing in the argument list? (If this is not > true, I don't see how to implement varargs with this compiler.) (The > example in the documentation seems to back up my assumption.) Yes, va_alist must be the only thing in the argument list. However, you can use #define to make va_alist expand into something bigger. That possibility, in fact, is the reason that va_alist must be the only thing in the argument list. > Is it leagal to pass a the rest of an argument list to another > function expecting it? If so, should it be passed as a pointer to a > variable of type va_list? (Without this capability, I supose I'll > have to document this as a non-portable use of varargs.) Yes, it is legal. You may pass either a pointer to a va_list or the entire va_list itself. Passing the pointer is recommended, because on some implementations the va_list may be quite large and therefore slow to copy. If you do pass the pointer, using va_arg in the subroutine will advance the argument list pointer as seen by the caller. > I assume va_start be done in the original function. (Dito the first > va_alist comment.) Does va_end have to be done in the original > function also? (va_end does nothing in my implementation.) It should be. (va_end does nothing in every implementation I've seen) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8671 for JMS@ARIZMIS; Sun, 27-APR-1986 04:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:18:12 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010178; 27 Apr 86 7:00 EDT Received: from USENET by SMOKE.BRL.ARPA id a017523; 27 Apr 86 6:36 EDT From: roe%toram.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <140@toram.UUCP> Date: 21 Apr 86 16:07:39 GMT To: info-c@BRL-SMOKE.ARPA In article <577@ur-helheim.UUCP> badri@ur-helheim.UUCP (Badri Lokanathan) writes: >My question is the following: is there any reason (other >than personal preferance) why one would prefer to use any particular form? >I personally prefer the while(1) form since it seems to make better reading. >Even better, I sometimes define TRUE to be 1 and then use while(TRUE). Unless you have a very unique optimizer, it is usually better to use the for(;;) form rather than the while(1) form. Reason is: while(1) is ALWAYS evaluated (ie. : is 1 TRUE? if so, continue) before each iteration, whereas for(;;) compiles as a simple branch or jump instruction with no test and no conditional branch. simply loops with no checks. -- Roe Peterson {linus,ihnp4,decvax}!utzoo!toram!roe All that glitters is spray-paint. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8639 for JMS@ARIZMIS; Sun, 27-APR-1986 04:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:17:51 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010176; 27 Apr 86 6:58 EDT Received: from USENET by SMOKE.BRL.ARPA id a017484; 27 Apr 86 6:35 EDT From: Mark Rosenthal Newsgroups: net.lang.c,net.unix-wizards,net.unix Subject: Help using dbx Message-ID: <461@aoa.UUCP> Date: 22 Apr 86 23:48:47 GMT Xref: seismo net.lang.c:8875 net.unix-wizards:17878 net.unix:8077 To: info-c@BRL-SMOKE.ARPA I posted the following article some weeks ago. I fear it may have dropped into the bit-bucket, so I am reposting it. It appears that most vendors have given up on 'sdb' in favor of 'dbx' or some derivative of 'dbx'. I find that although 'dbx' is generally more powerful than 'sdb' it lacks some capabilities that I used to depend on quite heavily. If anyone is familiar with how to do the following with 'dbx', please let me know. You will earn my undying gratitude. Note that I have not used sdb in over a year. The examples I give below are from my own faulty memory and may not be 100% accurate. By the way, I am running 'dbx' on a Sun workstation. 1. I'd like to be able to specify the format in which a variable is to be displayed. If I have a variable (char *cp), I could do the following with 'sdb': me: cp/x or: cp/s or: cp/ sdb: 0x7fff3ec string string With 'dbx', the dialogue is something like: me: print cp dbx: 0x7fff3ec me: 0x7fff3ec/s dbx: string Having to type back into dbx what it just typed at me is a pain. 2. The man page for 'dbx' claims that the command to display a memory location is: [address] / [count] [mode] where everything but the "/" is optional, and that "if no address is specified, the address following the one displayed most recently is used". Unfortunately, there is also a "/" command which searches the source file for a string. Typing "/" reports: "No saved search string" rather than showing me the next location. This makes it quite a chore to examine an array. Arrays of structures are even worse. 3. With 'sdb', I could display lines of code relative to the current line. 'dbx' appears to limit me to specifying absolute line numbers. This means that anytime I hit a breakpoint and want to see some context, I have to read the current line number from the screen, do some quick arithmetic, and type "list from_line,to_line". The concentration required to do that is a distraction from the problem I am trying to solve, namely finding and fixing bugs in a program. A symbolic way of referencing dbx's line counter would solve the problem, but I can find no mention of any such capability in the documentation. I'd like to be able to do something like: alias w list .-5,.+5 and then just type "w" to see context around the current line. 4. A common construct in C is a linked list of structures. struct foo { struct foo *next; int data; char *moredata; /* Etc., etc., etc. */ }; struct foo *foobar; Let's say my code malloc()s instances of foo, and links them in to the list beginning at foobar. I am at a breakpoint, and I want to examine the list. I don't remember the exact sequence I used with sdb, but it went something like: me: foobar/ show the value of foobar sdb?: 0x7ff2ea me: .->/ show what the last displayed value points at (i.e. foobar->next) sdb?: 0x7e3720 me: +/d show the next location in decimal (i.e. foobar->data) sdb?: 3 me: +/s show the next location as a string pointer (i.e. foobar->moredata) sdb?: string data me: - back up one location (to foobar->data) sdb?: 3 me: - back up one location (to foobar->next) sdb?: 0x7e3720 me: .->/ show what the last displayed value points at (i.e. foobar->next->next) sdb?: 0x748238 me: +/d show the next location in decimal (i.e. foobar->next->data) sdb?: 2 me: +/s show the next location as a string pointer (i.e. foobar->next->moredata) sdb?: more chars me: - back up one location (to foobar->next->data) sdb?: 2 me: - back up one location (to foobar->next->next) sdb?: 0x748238 me: .->/ show what the last displayed value points at (i.e. foobar->next->next->next) sdb?: 0 end of list me: +/d show the next location in decimal (i.e. foobar->next->next->data) sdb?: 1 me: +/s show the next location as a string pointer (i.e. foobar->next->next->moredata) sdb?: still more chars To do the same thing with dbx, the best I've been able to come up with so far is: me: print foobar dbx: 0x7ff2ea me: print foobar->data dbx: 3 me: print foobar->moredata dbx: string data me: print foobar->next dbx: 0x7e3720 me: print foobar->next->data dbx: 2 me: print foobar->next->moredata dbx: more chars me: print foobar->next->next dbx: 0x748238 me: print foobar->next->next->data dbx: 1 me: print foobar->next->next->moredata dbx: still more chars me: print foobar->next->next->next dbx: 0 end of list Note that the sequence of commands I type to sdb is relatively simple, and stays the same no matter how far through the list I've gone: me: foobar/ me: .->/ me: +/d me: +/s me: - me: - me: .->/ me: +/d me: +/s me: - me: - me: .->/ me: +/d me: +/s whereas with dbx, I have to retype the entire sequence from the starting point every time: me: print foobar me: print foobar->data me: print foobar->moredata me: print foobar->next me: print foobar->next->data me: print foobar->next->moredata me: print foobar->next->next me: print foobar->next->next->data me: print foobar->next->next->moredata me: print foobar->next->next->next This makes a list of length 4 a pain to deal with, and a list of length 16 prohibitive. Linked lists with hundreds of elements are not uncommon. Do the authors of 'dbx' really intend that I should have to type: print foobar->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->next->next->next->next->next->next->next->next->next->next->next->next-> next->data to get to the 128'th (or did I only type next 127 times?) item in a list? There MUST be a better way. Can somebody PLEASE enlighten me. Sorry. I got a bit carried away there. I'll be alright in a second. -- Mark of the Valley of Roses ...!{decvax,linus,ima,ihnp4}!bbncca!aoa!mbr ...!{wjh12,mit-vax}!biomed!aoa!mbr Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8834 for JMS@ARIZMIS; Sun, 27-APR-1986 04:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:34:53 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010292; 27 Apr 86 7:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a017898; 27 Apr 86 6:50 EDT From: Jim Giles Newsgroups: net.lang,net.lang.c Subject: Re: Re: Re: ... C builtin functions? Message-ID: <2323@lanl.ARPA> Date: 25 Apr 86 00:10:56 GMT Xref: seismo net.lang:2455 net.lang.c:8878 To: info-c@BRL-SMOKE.ARPA In article <562@nsc-pdc.UUCP> joemu@nsc-pdc.UUCP (Joe Mueller) writes: >Sizeof is an operator, not a function. It's perfectly legal to say >"sizeof foo" (without the parens). An operator is a syntactic form that invokes a function! SIZEOF is clearly a function: it has a domain (actually two domains - data types and variables) and it has a range (the non-negative integers) and it provides a mapping from one to the other. Since that is the mathematical definition of the word 'function', it is clear that SIZEOF is one. Now, it is true that the syntactic description of C uses the term 'function' in a slightly more restrictive way. But the guy that wrote the syntactic description of C just picked 'function' as a convenient name for a grammar rule. If you take it too literally, you will start saying absurd things like "'+' is an operator and not a function." Most people I know would be quite surprised about that! J. Giles Los Alamos Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8911 for JMS@ARIZMIS; Sun, 27-APR-1986 04:40 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:40:13 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010337; 27 Apr 86 7:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a017983; 27 Apr 86 6:53 EDT From: Jim Ruppert Newsgroups: net.unix-wizards,net.lang.c Subject: am I in the background? Message-ID: <124@eeg.UUCP> Date: 24 Apr 86 23:26:46 GMT Keywords: signal isatty background Xref: seismo net.unix-wizards:17884 net.lang.c:8879 To: info-c@BRL-SMOKE.ARPA I'm new to usenet news, so forgive me if this has been covered before... How can a process tell if it is running in the background? I've tried using isatty() and signal(), but to no avail. Any suggestions? -- ---- Jim Ruppert, EEG Systems Laboratory 1855 Folsom St, San Francisco, Ca 94103 (415) 621-8343 {ihnp4,dual,qantel}!ptsfa!eeg!jim Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8870 for JMS@ARIZMIS; Sun, 27-APR-1986 04:42 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:35:42 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010268; 27 Apr 86 7:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a017828; 27 Apr 86 6:48 EDT From: Rex Ballard Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <792@ccird2.UUCP> Date: 24 Apr 86 23:11:22 GMT Xref: seismo net.lang.c:8877 net.unix-wizards:17882 To: info-c@BRL-SMOKE.ARPA In article <5302@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >> I have always heard that varargs is not very portable. Is this really >> true? If you know of any machine that is running 4.X BSD, System III/V, >> Xenix or any other real unix that doesn't support varargs, please let >> me know. > >If you find any machine with a sensible architecture that cannot >be made to support varargs, I would greatly like to hear about it. > The concern about about varargs is brought up in "Software Tools" by Kernigan and Plauger. The main concern is that certain systems and languages have the caller push the arguments, and have the callee destroy them when they are finished. This is common practice in Fortran and Pascal. The big concern with C is that there might be a compiler out there which has C/Pascal|Fortran compatibility. Since these compilers seem to be the exception rather than the rule, and newer versions of these languages are tending to follow C conventions, this is not likely to be a problem for *most* environments. I have heard that there are a few "peculiar" compilers available for the Atari ST, Mac, and Amiga, which, although not "kosher", CAN support most varargs situations. The problems that can occur are "intelligent" compilers which put arguments directly into registers rather than on the stack. Appearantly, this can be a real problem if you wish to "intercept" a system call at the application side. Why do so many of the micro operating systems insist on putting arguments in registers!!!. Even MS-DOS expects arguments in registers rather than on the stack. The C frame is a more sensible archetecture, but not the only one. Since you specifically asked about UNIX based systems, you can be relatively unconcerned. There are non-portable ways to USE varargs. The classic is to put a long indicator into the "format argument" and pass an int. Do this with a couple of arguments where ints are 16 bits, and longs are 32 bits, and you will return to "never never land". The normal usages (printf, scanf,...) aren't usually a problem, but there are a few "mix and match" functions using varargs which selectively mix and match various modifiable stack addresses, and will "core dump" the whole system. try this: (comments are for 16 bit ints, 32 bit longs, 32 bit pointers). main() { /* top of frame = return address */ int i; long l; scanf("%d %d",&i); /* second argument missing, clobbers frame */ scanf("%d",i); /* cute "poke" of i, can demolish code or core dump */ scanf("%ld",&i); /* extra 16 bits is usually frame pointer or return address */ scanf("%d",l); /* 16 bits of "garbage" plus your number possibly munged beyond recognition due to byte ordering */ } Lint will pass it, assuming printf is declared /*VARARGS*/, and the compiler won't even sneeze. But running it will give you "buss error core dumped" or something equally nasty. This is one of the few areas where lint will not protect you. Anyone figured out a syntax checker for these functions? Of course, you should use a syntax checker for any of these functions. Another cute trick I've seen is using varargs to pass integers to functions which assign to pointers. Such as: main() { int read(); init(0x20L,&read); /* set exception vector */ } /*VARARGS*/ init(a,b) char **a,*b,**i; { *a=b; /* poke absolute value with a valid address */ } This is the ultimate in unportability, but is frequently "hidden" in "hostile" PC programs, typically to mount new device drivers and remove them when the code is complete. Just try plugging one of these into unix unmodified :-). Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8952 for JMS@ARIZMIS; Sun, 27-APR-1986 04:44 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:42:17 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010339; 27 Apr 86 7:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a018049; 27 Apr 86 6:55 EDT From: Donn Seeley Newsgroups: net.unix-wizards,net.lang.c Subject: C bug of the week Message-ID: <3763@utah-cs.UUCP> Date: 23 Apr 86 09:45:05 GMT Xref: seismo net.unix-wizards:17885 net.lang.c:8880 To: info-c@BRL-SMOKE.ARPA /* * If you have a Reiser 'cpp', try running 'lint' on this program. * Observe the amusing errors. It's not too hard to guess what's * going wrong... */ # define X /* Watch lint get very confused */ X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X #ifdef notdef int i = 1; #endif syntax error #ifdef notdef Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn #endif Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9008 for JMS@ARIZMIS; Sun, 27-APR-1986 04:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:46:29 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010351; 27 Apr 86 7:21 EDT Received: from USENET by SMOKE.BRL.ARPA id a018084; 27 Apr 86 6:56 EDT From: Guy Harris Newsgroups: net.lang.c,net.unix-wizards,net.unix Subject: Re: Help using dbx Message-ID: <3578@sun.uucp> Date: 25 Apr 86 01:55:48 GMT Xref: seismo net.lang.c:8881 net.unix-wizards:17886 net.unix:8079 To: info-c@BRL-SMOKE.ARPA > By the way, I am running 'dbx' on a Sun workstation. Which is different from the 4.2BSD "dbx", which is in turn different from the 4.3BSD "dbx", so note that this discussion applies only to the Sun version. > 1. I'd like to be able to specify the format in which a variable is to be > displayed. To print the variable "foo" in a particular format, &foo/ should suffice. > If I have a variable (char *cp), I could do the following with 'sdb': ... In this case, you don't want to display "cp", you want to display what "cp" points to. The Sun UNIX 3.2 version (probably the 3.0 version as well) will print what a "char *" points to, as a string, as well as its value. If you say "print *cp", it will print the char that "cp" points to. > 2. The man page for 'dbx' claims that the command to display a memory > location is: ... > ... rather than showing me the next location. This makes it quite a chore > to examine an array. Arrays of structures are even worse. The fact that the man page says anything indicates you definitely don't have 3.0. I don't know what 3.0 added. First, why are you using the display command to examine an array? "print array[N]" seems sufficient to examine the Nth element. If the entire array is small enough that printing it in its entirety is reasonable, try "print array". Second, if you've just displayed a location using "/", you don't want to use something like a naked "/" to display the same location again. You want to display the next location, which can be done (at least in 3.0 and later releases) using "+/". > 3. With 'sdb', I could display lines of code relative to the current line. > 'dbx' appears to limit me to specifying absolute line numbers. This > means that anytime I hit a breakpoint and want to see some context, I > have to ... "l" by itself will, after hitting a breakpoint, print the line the breakpoint occurred on and the next 10 lines. Repeating the "l" will step through the file. Unfortunately, this doesn't give you a window *around* the breakpoint. If you have "dbxtool", and are doing your debugging on a workstation, you can use that. > 4. A common construct in C is a linked list of structures. ... > (discussion of stepping through the list) What's needed here is a notion of variables inside "dbx", so that you can have an alias which prints whatever points to and sets to ->next. This is a more general solution than what "sdb" offers; I can imagine data structures which "sdb" would not be able to scan through conveniently. Unfortunately, "dbx" doesn't have this notion. The 4.3BSD one might. Perhaps "dbx" should have more such programming-language characteristics, so that it could be "programmed" to display more complicated data structures. I also note from this an other examples that you seem to be using "sdb" and "dbx" as a symbolic debugger which knows about source lines, but not one which knows about data structures. "dbx" can be used that way, but it wasn't really intended to be so used. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9099 for JMS@ARIZMIS; Sun, 27-APR-1986 05:01 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 05:59:53 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010440; 27 Apr 86 7:35 EDT Received: from USENET by SMOKE.BRL.ARPA id a018203; 27 Apr 86 7:00 EDT From: Lawrence Crowl Newsgroups: net.lang.c Subject: Re: Byte order Message-ID: <17610@rochester.ARPA> Date: 25 Apr 86 21:21:47 GMT To: info-c@BRL-SMOKE.ARPA In article <1298@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: ]In article <17312@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: ]]CHALLENGE: Come up with a scheme for representing numbers, and a sorting ]]scheme in which numbers sort naturally. Your scheme must deal with variable ]]length character strings and variable size numbers. That is, you cannot ]]require strings to be padded with nulls, or numbers to be padded with zeros. ] ]Basically, you use a unary notation (pure or modified) to indicate how long ]the number is, and the number follows. Using the scheme above, 257 would ]be ZZZ257. One and a half would be Z15. This is essentially floating point ]notation. ... This has to be modified a bit to deal with negative numbers. ... ]Also, for negative numbers, the digits should be in (9's) complement form. ... ]This can of course be done somewhat better. A higher radix can be used, and ]the exponent encoding can be further optimized. But the point is to describe ]the approach, not to work out all the details. This seems good to me. If there are no radical alternatives, lets close the issue. -- Lawrence Crowl 716-275-5766 University of Rochester Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9132 for JMS@ARIZMIS; Sun, 27-APR-1986 05:05 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:02:54 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010442; 27 Apr 86 7:36 EDT Received: from USENET by SMOKE.BRL.ARPA id a018556; 27 Apr 86 7:09 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Optimization error? Message-ID: <2593@utcsri.UUCP> Date: 21 Apr 86 03:56:36 GMT To: info-c@BRL-SMOKE.ARPA In article <3109@reed.UUCP> joey@reed.UUCP (Joe Pruett) writes: >I contend that if the compiler could figure out that flag could >get set to 1, then it should also figure out that flag might not >bet set to anything, and at least issue a warning, but it should >not optimize the expression away. > >Is this a bug, or a misfeature, or an inherent gotcha with fancy >optimization? I would say that a run-time bug in your code has propogated its way into compile-time - an inherent gotcha. To determine in general that the flag may not be set is probably (?) similar to the halting problem - it can't be done (* In General *) so it will only be detected for simple cases. Lint apparently looks at the textual order of operations - the following draws a warning: int i,j; for(i=1;i<=2;++i){ if(i==2) printf("j = %d\n", j ); j = 123; } Lint will say that j is used before it is set. An example can be set up with goto's { goto b; a: use(j); return; b: j=0; goto a;}. In this case it is more obvious that the code is ok but Lint will still warn. -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9236 for JMS@ARIZMIS; Sun, 27-APR-1986 05:11 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:08:39 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010446; 27 Apr 86 7:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a018656; 27 Apr 86 7:12 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: A simple non-portable expression tha Message-ID: <6612@utzoo.UUCP> Date: 23 Apr 86 00:11:05 GMT To: info-c@BRL-SMOKE.ARPA > No, the compiler is not free to associate right-to-left in an > expression > long + int + int. > Addition associates left-to-right, and the integral widening > conventions apply, so the middle term must be converted to long > and added to the leftmost term before the rightmost term is > added. The compiler is allowed to reorder this only if it > guarantees the same answer as would be obtained by following > the rules... Sorry, Doug, not so. Not in the draft standard, anyway, unless serious changes have been made since my last copy (November). Yes, there is a statement early on to the effect that "the compiler can do things any way it pleases if the results are the same". However, somewhat later, in C.3, we also find: An expression involving more than one occurrence of the same commutative and associative binary operator (*, +, &, ^, |) may be regrouped arbitrarily... provided the types of the operands or of the results are not changed by this regrouping. Note that no mention is made of the types of intermediate values, unless that ambiguous reference to "results" instead of "result" is meant to imply it. And there is no constraint that the value of the expression be unchanged. -- Support the International League For The Derision Henry Spencer @ U of Toronto Zoology Of User-Friendliness! {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9201 for JMS@ARIZMIS; Sun, 27-APR-1986 05:13 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:07:14 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010444; 27 Apr 86 7:37 EDT Received: from USENET by SMOKE.BRL.ARPA id a018646; 27 Apr 86 7:12 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: A simple non-portable expression tha Message-ID: <2609@utcsri.UUCP> Date: 22 Apr 86 16:26:25 GMT To: info-c@BRL-SMOKE.ARPA In article <130@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >No, the compiler is not free to associate right-to-left in an >expression > long + int + int. >Addition associates left-to-right, and the integral widening >conventions apply, so the middle term must be converted to long >and added to the leftmost term before the rightmost term is >added. The compiler is allowed to reorder this only if it >guarantees the same answer as would be obtained by following >the rules. On machines where integer overflow is ignored, If this is strictly true, then the widening semantics are applied to the expression tree before any reassociation is done: long L; int I1,I2; L+I1+I2, parses as (L+I1)+I2, after widening is (L+(long)I1)+(long)I2 The compiler can still do this as L + ( (long)I1+(long)I2), though, since everything is now the same width and so the result won't be affected. >the opportunity arises more frequently than on those where >it traps. However, in this example, information could be >lost by overflow if the compiler treated the expression as > long + (int + int) >so it is not allowed to do that. What if you *write* L+(I1+I2)? If the widening semantics *are* applied before any reassociation is done, the result is L+(long)(I1 + I2), using an integer add for I1+I2, which presumably may not be re-ordered because the result would be affected - besides it is no longer of the form a+(b+c). However, I tried this ( using 16-bit short ints for I1,I2 ) on our native vax compiler and on our 68K compiler. Both produced identical code for (L+I1)+I2 and L+(I1+I2) and L+I1+I2: specifically, ((long)I1+L)+(long)I2. I guess the a+b+c is recognized as a special case, and all three are widened to a common width regardless of the original associativity. Interestingly, writing the expression as L+(short)(I1+I2) had no effect on the vax code, but forced the 68K compiler to do a 16-bit add of I1 and I2 before adding L. The 68K code is what I would expect - although deliberate use of casts as %65536 operators is pretty shaky stuff. A final question - It seems that L+I1+I2 will work regardless of if and where you put the ()'s, since a 'chained' addition is treated as a special case. But is this a feature of the language, or of the compiler? Any 'portability' which is based on a non-essential compiler feature is not really true portability, is it...? -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9289 for JMS@ARIZMIS; Sun, 27-APR-1986 05:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:13:55 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010448; 27 Apr 86 7:40 EDT Received: from USENET by SMOKE.BRL.ARPA id a018667; 27 Apr 86 7:13 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: Signed Characters Message-ID: <6610@utzoo.UUCP> Date: 22 Apr 86 20:43:41 GMT To: info-c@BRL-SMOKE.ARPA > If restricted to only one flavor [of bytes], I would choose signed any day. > It it easier on a PDP-11 to mask the high byte if unwanted than to > generate it (sign extend) if needed. But one ends up doing the masking a lot more often. I believe Dennis has said that he now regrets the concession to the hardware of making char signed in the original C implementation. -- Support the International League For The Derision Henry Spencer @ U of Toronto Zoology Of User-Friendliness! {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9388 for JMS@ARIZMIS; Sun, 27-APR-1986 05:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:19:28 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010453; 27 Apr 86 7:42 EDT Received: from USENET by SMOKE.BRL.ARPA id a018705; 27 Apr 86 7:15 EDT From: Richard Harter Newsgroups: net.lang.c Subject: Re: Byte order (or you are both wrong) Message-ID: <7485@cca.UUCP> Date: 24 Apr 86 05:34:15 GMT To: info-c@BRL-SMOKE.ARPA >In article <17162@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: > >CHALLENGE: Come up with a scheme for representing numbers, and a sorting >scheme in which numbers sort naturally. Your scheme must deal with variable >length character strings and variable size numbers. That is, you cannot >requires strings to be padded with nulls, or numbers to be padded with zeros. Presented without endorsement: Addressing nomenclature -- big endian (i.e. msb is bit 0, etc.) Item is divided into five parts: Part I - sign bit (0 is negative, 1 is postive) Part II - Size of field size in unary, i.e. string of 1's terminated by 0 Part III - Field size, in binary (Field size is size of field to left of implicit decimal point. Part IV - Portion of string to left of implied decimal point, encoded in bytes. Part V - Portion of string to right of implied decimal point, encoded in ternary, using two bits per ternary digit, as follows: 00 Sentinel, terminating right field 01 ternary 0 02 ternary 1 03 ternary 2 All numbers are represented as ascii characters. The point of the ternary representation (or something equivalent) is that it provides for a sentinel for variable length strings that sorts lexicographically. If an integer is to be considered as a number and compared in that fashion it goes in the left field -- if it is to be considered as a character string it goes in the right field. I believe that this representation meets the challenge. I sincerely hope that I never have to work with it. Richard Harter, SMDS Inc. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9473 for JMS@ARIZMIS; Sun, 27-APR-1986 05:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:31:58 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010545; 27 Apr 86 7:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a019075; 27 Apr 86 7:28 EDT From: John Rose Newsgroups: net.lang.c,net.arch Subject: Re: Byte order (retitled) Message-ID: <5056@think.ARPA> Date: 25 Apr 86 20:02:09 GMT Xref: seismo net.lang.c:8889 net.arch:3239 To: info-c@BRL-SMOKE.ARPA In article <1117@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >In article <2590@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >> >>I strongly disagree. If you have long *x, then (char)*x ( as opposed to >>*(char*)x ) is the low-order byte of the pointed-to long and is >>portable. > > What I was trying to say is that *both* should be portable and >equivalent. >..... > And I am saying that the following *should* be portable, and >that any implementation that it doesn't work on is brain-damaged. > > register int i; > unsigned char bytes[ sizeof( long )]; /* lo-byte first */ > long input; > register char *cvptr; > > for(cvptr = (char *)&input, i = 0; i < sizeof(long); i++) > bytes[i] = cvptr[i]; > > Sarima (Stanley Friesen) Well, this is certainly false for all existing C's on big-endian machines. Even if you make the pointer "(char *)&input" point to the last byte of the datum, when you index on it, say by referencing "cvptr[1]", you get bytes *past* the last byte of the long datum. But the funny thing is, a C compiler *could* be designed to make Sarima's code work on a big-endian machine. Pointer ordering and arithmetic could be defined, in a self-consistent way, *backwards* from the machine-word ordering. Arrays and structs would be allocated backward in memory. (As a bonus, conversion between pointers and ints could involve a negation, but portable C makes no such requirements.) In essence, the abstract addressing structure imposed by this hypothetical compiler would turn our misguided big-endian machine into a virtual little-endian. This hack fails for the waverers, such as PDP-11's. (However, you could complement the 1s bit before and after index arithmetic?) Be wrong, but be consistent! Disclaimers: This was not a serious suggestion to the compiler designers of the world. It certainly has nothing to do with the official policy of Thinking Machines Corporation. :-) :-) :-) [P.S. Sarima, if this was your meaning all along, sorry to steal your thunder; I must have missed an article.] [P.P.S. Local work crunch precludes retro-flame on &array responses. But stay tuned, netters.] -- ---------------------------------------------------------- John R. Rose Thinking Machines Corporation 245 First St., Cambridge, MA 02142 (617) 876-1111 X270 rose@think.arpa ihnp4!think!rose Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9566 for JMS@ARIZMIS; Sun, 27-APR-1986 05:39 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:38:22 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010548; 27 Apr 86 7:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a019182; 27 Apr 86 7:31 EDT From: wex%milano.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Sets in C Message-ID: <1376@milano.UUCP> Date: 23 Apr 86 16:12:54 GMT Sender: wex%milano.uucp@BRL.ARPA To: info-c@BRL-SMOKE.ARPA Does anyone out there have a package for doing Pascal-like sets in C? I want to be able to call functions like IN, etc. Please reply directly to me, as I am not a regular reader of this group. Thanks! -- Alan Wexelblat ARPA: WEX@MCC.ARPA UUCP: {ihnp4, seismo, harvard, gatech, pyramid}!ut-sally!im4u!milano!wex ** REJECT THE IMPOSITION OF THE NEW SOCIAL ORDER !! ** Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9598 for JMS@ARIZMIS; Sun, 27-APR-1986 05:42 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:40:56 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010648; 27 Apr 86 8:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a019679; 27 Apr 86 7:48 EDT From: Sam Kendall Newsgroups: net.lang.c Subject: Re: void * [also malloc] Message-ID: <141@delftcc.UUCP> Date: 25 Apr 86 17:21:38 GMT To: info-c@BRL-SMOKE.ARPA In article <200@brl-smoke.ARPA>, gwyn@BRL.ARPA writes: > Malloc() should return (void *), > which is a generic pointer type to/from which all other pointer types > may be cast without loss of information. (This is the only use of > (void *), and it is the only universal pointer type; other pointer > casts can be non-portable.) Can anyone tell me when a `void *' could have a different representation than a `char *'? Since `sizeof (char)' is always 1 according to both practical considerations and the draft standard, a char must be the smallest addressable object. Also according to practical considerations (and the draft standard, I think) all objects consist of an integral number of chars. So there is nothing a `void *' can point at that a `char *' cannot. A `void *' and a `char *' could have different representations, although I cannot think of a good reason. But I think casts to `char *', and from `char *' with proper alignment, are portable. `void *', then, is just a convenience for the human mind and for typecheckers. That's okay with me. > Malloc() ALSO guarantees that the pointer > it returns is suitably aligned for safe casting to ANY pointer type. > This is a property of malloc(), not of (void *). I've always wondered about something here: why is the return value of malloc guaranteed to be aligned for any object, even one bigger than the allocated area? Currently, `malloc(1)' must return a maximally aligned pointer! This prevents an implementation which does something space-efficient with small allocations. ---- Sam Kendall { ihnp4 | seismo!cmcl2 }!delftcc!sam Delft Consulting Corp. ARPA: delftcc!sam@NYU.ARPA Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9629 for JMS@ARIZMIS; Sun, 27-APR-1986 05:44 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:43:38 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010650; 27 Apr 86 8:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a019709; 27 Apr 86 7:49 EDT From: John Owens Newsgroups: net.lang,net.lang.c Subject: Re: Re: structured assembler (BASIC) [Really: C builtin functions?] Message-ID: <705@edison.UUCP> Date: 24 Apr 86 16:29:55 GMT Xref: seismo net.lang:2460 net.lang.c:8892 To: info-c@BRL-SMOKE.ARPA > You are sort of right, but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? > > Paul Guthrie `When the going gets weird, > ihnp4!ihdev!pdg The weird turn pro' > - H. Thompson Yes. Try this on your favorite C compiler and tell me if you still think that "sizeof" is a function as opposed to an operator. main() { int a; printf("%d\n",sizeof a); /* note no parentheses */ } John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own] Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9696 for JMS@ARIZMIS; Sun, 27-APR-1986 05:48 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:47:12 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010718; 27 Apr 86 8:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a020123; 27 Apr 86 8:05 EDT From: Joe Mueller Newsgroups: net.lang,net.lang.c Subject: Re: Re: Re: ... C builtin functions? Message-ID: <562@nsc-pdc.UUCP> Date: 21 Apr 86 17:48:45 GMT Xref: seismo net.lang:2462 net.lang.c:8894 To: info-c@BRL-SMOKE.ARPA > > >C has standard built-in functions???? > > > Well, how about sizeof(foo)? > > > > It looks like a function invocation, and is known and understood > > by the compiler... > > The thing is, sizeof() evaluates to a constant at run time, just like > 'c'<<3 or BUFSIZ . That makes it a pretty trivial function. All it > really does is give you a portable, automatic facility for referring to > system dependencies. > -- Sizeof is an operator, not a function. It's perfectly legal to say "sizeof foo" (without the parens). Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9661 for JMS@ARIZMIS; Sun, 27-APR-1986 05:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 06:46:21 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010664; 27 Apr 86 8:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a020085; 27 Apr 86 8:03 EDT From: Chris Robertson Newsgroups: net.lang.c Subject: Re: Jumping into blocks Message-ID: <149@toram.UUCP> Date: 25 Apr 86 16:45:45 GMT To: info-c@BRL-SMOKE.ARPA In article <737@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <275@copper.UUCP> copper!stevesu (Steve Summit) writes: >>Most people agree that goto's are pretty acceptable for handling >>error conditions. For instance: >> >> [example deleted] > > ... But here's a real example I keep running into: > > [example deleted] > >So, assuming that goatooze are acceptable for error handling, but jumping >into a block is forbidden, what's the best way to write this? Use two >braches, and hide the common code at the bottom of main()? Set an error >flag and test it outside the while? (Ugh, that requires an artificial >boolean *and* a break statement.) Make usage() a non-returning function >instead of a label? (My usual preference.) Duplicate the code? What's wrong with a flag and and "break"s? "Break" after an error condition is perfectly obvious, especially when the error test is right after the loop. Or duplicate the code, when it's so trivial. What's a couple of lines in the interest of readability? Sure "goto"s can sometimes make complicated things more readable (e.g., saving putting great chunks of code in several nests of "if"s), but why on earth use it to make a nice, straightforward error test obscure? Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9865 for JMS@ARIZMIS; Sun, 27-APR-1986 06:02 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 07:01:20 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010828; 27 Apr 86 8:33 EDT Received: from USENET by SMOKE.BRL.ARPA id a020269; 27 Apr 86 8:10 EDT From: Andrew Koenig Newsgroups: net.lang,net.lang.c Subject: Re: structured assembler (BASIC) [Really: C builtin functions?] Message-ID: <5341@alice.uUCp> Date: 24 Apr 86 20:58:43 GMT Xref: seismo net.lang:2463 net.lang.c:8895 To: info-c@BRL-SMOKE.ARPA > Any operator which maps its args into a unique value in its range > defines an operation which is a function. Just because you can > say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not > a function. Similarly, sizeof(i), whether or not you use parens > (and I always do) is an operator which, of course, is a function. > Were you talking about details of implementation, perhaps? The C definition of "function" is not the same as the mathematical definition. A C function is a part of a program. A mathematical function is a set of ordered pairs that meet certain conditions. That said, note that sizeof(i) is syntactically a constant. This would not be true if sizeof were a function. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0025 for JMS@ARIZMIS; Sun, 27-APR-1986 06:07 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 07:05:16 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010840; 27 Apr 86 8:35 EDT Received: from USENET by SMOKE.BRL.ARPA id a020529; 27 Apr 86 8:18 EDT From: "Wayne A. Christopher" Newsgroups: net.lang.c Subject: Re: void * [also malloc] Message-ID: <219@cad.UUCP> Date: 26 Apr 86 20:29:37 GMT To: info-c@BRL-SMOKE.ARPA In article <141@delftcc.UUCP>, sam@delftcc.UUCP (Sam Kendall) writes: > I've always wondered about something here: why is the return value of > malloc guaranteed to be aligned for any object, even one bigger than > the allocated area? Currently, `malloc(1)' must return a maximally > aligned pointer! This prevents an implementation which does something > space-efficient with small allocations. "Maximally aligned" generally means aligned to a multiple of the wordsize of the machine, so you don't lose much space (malloc ususally allocates an extra word anyway before the space for a pointer anyway...) I guess that you wouldn't lose much if you allowed malloc(1) to return an unaligned byte, but it isn't worth the trouble... Wayne Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0026 for JMS@ARIZMIS; Sun, 27-APR-1986 06:09 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 07:05:20 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010831; 27 Apr 86 8:33 EDT Received: from USENET by SMOKE.BRL.ARPA id a020321; 27 Apr 86 8:12 EDT From: Tom Keller Newsgroups: net.lang.c Subject: Re: void * Message-ID: <194@gilbbs.UUCP> Date: 26 Apr 86 08:34:25 GMT To: info-c@BRL-SMOKE.ARPA In article <200@brl-smoke.ARPA>, gwyn@BRL.ARPA (VLD/VMB) writes: > You're mixing two features of malloc(). Malloc() should return (void *), > which is a generic pointer type to/from which all other pointer types > may be cast without loss of information. (This is the only use of > (void *), and it is the only universal pointer type; other pointer > casts can be non-portable.) Malloc() ALSO guarantees that the pointer > it returns is suitably aligned for safe casting to ANY pointer type. > This is a property of malloc(), not of (void *). Well, that's just great! The C compiler on my system doesn't understand such niceties as void. So what do we do? (do *NOT* tell me to get another compiler, there *IS* no other compiler available for this system!) -- Disclaimer: I hereby disclaim any and all responsibility for disclaimers. tom keller {ihnp4, dual}!ptsfa!gilbbs!mc68020 (* we may not be big, but we're small! *) Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0068 for JMS@ARIZMIS; Sun, 27-APR-1986 06:11 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 07:09:25 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010932; 27 Apr 86 8:49 EDT Received: from USENET by SMOKE.BRL.ARPA id a020896; 27 Apr 86 8:30 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Address of array Message-ID: <2629@utcsri.UUCP> Date: 25 Apr 86 04:07:39 GMT To: info-c@BRL-SMOKE.ARPA In article <153@brl-smoke.ARPA> gwyn@BRL.ARPA writes: >typedef struct { whatever-you-need } jmp_buf[1]; > >solves the problem of the way setjmp()'s parameter is used, >with completely type-correct implementation (in the >"whatever-you-need" part). Too bad setjmp() was defined >as taking an array parameter in the first place. I've been wondering about this... Why would you need to define jmp_buf as a structure? It seems (1) it is impossible to write setjump or longjmp in C (2) the contents of the buffer are completely non-portable, so any program that looks at or alters them is non-portable (3) you can't do anything useful with them anyway, from C. All jmp_buf is is a certain amount of space, as far as C needs to be concerned. I think point (3) is a bit shaky - the contents just might be useful in certain inherently non-portable code. And it would be nice, I agree, if jmp_buf had been defined as a structure - if only to allow easy copying of jmp_buf records. A definition might look like `typedef struct{ char *dummy[11];} jmp_buf;'. But are there cases where a structure was used out of necessity? -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0100 for JMS@ARIZMIS; Sun, 27-APR-1986 06:15 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 07:11:32 CST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010934; 27 Apr 86 8:49 EDT Received: from USENET by SMOKE.BRL.ARPA id a020992; 27 Apr 86 8:33 EDT From: Chris Torek Newsgroups: net.lang.c,net.unix-wizards Subject: arguments in registers Message-ID: <1205@umcp-cs.UUCP> Date: 27 Apr 86 05:41:39 GMT Xref: seismo net.lang.c:8905 net.unix-wizards:17910 To: info-c@BRL-SMOKE.ARPA In article <155@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >[Passing arguments in registers] would be fine if C had nested >procedures or inlines or something, but a disaster otherwise. In fact, a compiler is free to optimise any function into inline code, so long as it provides a `regular' version of those that can be called from external modules. For example, given the following as a complete C module, the compiler can eliminate the routine `local1' completely, but not `local2' nor `global': static int local1() { static int count; return (++count); } static void local2() { void ext0(), ext1(); switch (local1()) { case 0: ext0(); break; case 1: ext1(); break; } } void global(ppfv) void (**pfv)(); { *pfv = local2; } [Aside to Joe Yao: Hello! I just used `M' in vi again.] Here the routine `local1' is not accessible outside this module, so a compiler may elide it completely and replace the call in `local2' with a direct reference to an unnamed static variable. However, `local2' is externally accessible, since global() (which is itself reachable) sets the supplied pointer to point at local2. (A really clever compiler will discover unreachable local functions and remove them, which may reveal more unreachable locals.) One can also come up with examples wherein a good compiler might provide a function externally yet also expand calls to it in line within that module: int do_the_obvious(a, b) int a, b; { return (a > b ? a : b); } void something() { register int *p, *q; ... otherproc(do_the_obvious(*p++, *q++)); ... } There is no reason a compiler cannot pretend the call to `do_the_obvious' was a built-in `max' function, and generate something like this Vax code: _do_the_obvious: .globl _do_the_obvious .word 0 # only scratch regs used movq 4(ap),r0 # get a and b into r0 and r1 # assume return a cmpl r0,r1 # if a > b, skip this: bgtr 0f movl r1,r0 # return b 0: ret _something: .globl _something ... movl (r11)+,r0 # get *p++ movl (r10)+,r1 # get *q++ cmpl r0,r1 # if the value from *p is greater bgtr 0f # than that from *q, skip this: movl r1,r0 # move the from-*q value to r0 0: pushl r0 # result onto stack calls $1,_otherproc # go run otherproc ... Incidentally, I have not seen any optimising C compilers myself; are there any available that would have done what I did above? (Just curious.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2765 for JMS@ARIZMIS; Sun, 27-APR-1986 17:15 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 19:03:16 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014550; 27 Apr 86 19:48 EDT Received: from USENET by SMOKE.BRL.ARPA id a027492; 27 Apr 86 19:40 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V15#3 Message-ID: <1007@hou2d.UUCP> Date: 18 Apr 86 14:58:16 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Fri, 18 Apr 86 Volume 15 : Issue 3 Today's Topics: #import could solve the #include problem? C wishlist Unary + and evaluation order ---------------------------------------------------------------------- Date: Mon, 14 Apr 86 18:50:42 PST From: hoptoad!gnu (John Gilmore) Subject: #import could solve the #include problem? To: cbosgd!std-c I keep running across the problem that one include file may need inclusions from another (especially if typedefs, like ino_t, are used). There is no clean solution (yes, I've seen the setups with: #ifndef TYPES_H_INCLUDED #define TYPES_H_INCLUDED #endif and even if you do that to all your header files and all the system include files (and merge it back in every time a new release of the system comes out), your code which assumes this setup will not be portable to anywhere else. It occurred to me that the solution is in hand, though; cpp has enough information to know whether the file has been previously included. There's just no way to ask it. So I propose a way to ask. #import "filename" would have the same effect as #include "filename" unless this include file has already been imported before in this source file. On Unix systems, the file could be defined by its device/inode #s (same definition "mv" uses to avoid moving a file on top of itself). On other systems, string compares or whatever would work. I suggest that the #import form *not* be implemented; I never saw what was wrong with #include "file.h" since it will be found in the standard directories anyway. (Anybody who puts "stdio.h" in their current directory and then wants to include /usr/include/stdio.h is begging for her code to break next year when somebody else maintains it.) ------------------------------ Date: Wed, 16 Apr 86 13:03:43 est From: decvax!bellcore!linus!raybed2!rayssd!rayssdb!cec (Campbell) Subject: C wishlist To: rayssd!raybed2!linus!decvax!bellcore!ulysses!cbosgd!ihnp4!houxm!hou2d!osd Just a short time ago, there was a bit of discussion on net.lang.c on how to get a C function to handle 2 or more argument arrays. Of course, the solution is to force the (poor) programmer to enter in the math necessary to get an equivalent index to a 1 argument array (ie. vector). I really don't see why C should not be able to handle the following: int f(a,n) int n; int a[n][n]; { } where "n" is a user-specified number "upstairs". Obviously, if instead of "n" there was a constant (f(a), etc.), then C will automagically use that constant. Why it can't say "I'll use the user-supplied location for my expansion of indices into a vector index if the user wishes" instead of "I insist: gimme a number, or I won't work!!!" escapes me. It seems that such an extension would be simple. An example of use-cycle follows: 1) I write a linear equation solver (Ax=b). I would like to pass n (int a[n][n]) and then do the calculations using a[i][j] (int i,j;). I can't because of an unnecessary C restriction. 2) After I got the program debugged, and if it was worthwhile, I would then expend the effort to cast the program into pointer use for speed. The latter form is not as readable, but it is faster. I admit that, given the example, that the actual linear equation solver that I wrote does not use index expansion. Nonetheless, it would be lots easier to do this cycle the way I mentioned for, say, double QR iterations to solve for matrix eigenvalues. I have a hard enough time as it is convincing FORTRASH types that C is better. Give 'em one nit and their tunnel vision hits... ------------------------------ Date: Sat, 12 Apr 86 14:32:23 est From: unc!rti-sel!dg_rtp!throopw Subject: Unary + and evaluation order To: As I understand it, the proposed standard overloads the (new) unary + operator, so that it is *not* analogous to the unary -. In particular, it states that +E restricts the order of subexpression evaluation, so that subexpressions inside E cannot be regrouped with subexpressions outside E. All well and good... this is better than requiring explicit temporaries. However, there was already a unary operation that (at least in K&R) had the semantic of "assignment to a temporary", and which therefore could have legitimately been used to restrict evaluation order without the potentially confusing overloading of the + operator. This is, of course, the cast. The definition of the cast in the draft standard doesn't seem to state whether (type)E allows regrouping of subexpressions of E outside the cast, but I suspect that it *does* allow it if the cast is nil (that is, a conversion where the bits of E don't need to change) and doesn't if the cast is non-nil, making this aspect of casting implementation dependant. (Again, this last is my interpretation, and isn't explicitly mentioned in the standard.) I'd recommend that the surprising overloading of + be dropped in favor of the less-surprising overloading of cast. This would make the operation of cast a little less implementation dependant, remove a confusing overloading of +, and in general conform more closely to K&R at no cost to newly added functionality. The only substantial negative point I can think of is that using casts for order-of-evaluation tinkering implies that the tinkerer knows the types of the subexpressions tinkered with. This doesn't seem a severe constraint to me... the tinkerer had *better* know what is going on. Has this proposal been made and rejected already? Does it seem reasonable? Are there strong reasons for using + and not using cast? How about weak reasons? What is the capital of Sri Lanka? What is the principle export of Brazil? If a chicken and a half lays an egg and a half in a day and a half... (oops sorry, little carried away there :-) -- (Evil Android Duplicate Prof grabs Our Hero, who, thinking quickly, asks) "Professor, what is the capital of Sri Lanka?" " Miami. " from _The_Annihilator_ (an example of truely *bad* cinema) -- Wayne Throop at Data General, RTP, NC !mcnc!rti-sel!dg_rtp!throopw ------------------------------ End of mod.std.c Digest - Fri, 18 Apr 86 09:56:26 EST ****************************** 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2858 for JMS@ARIZMIS; Sun, 27-APR-1986 17:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 19:20:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014592; 27 Apr 86 20:11 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a027784; 27 Apr 86 20:00 EDT Date: Sun, 27 Apr 86 19:54:09 EDT From: Doug Gwyn (VLD/VMB) To: roe%toram.uucp@BRL.ARPA cc: info-c@BRL-SMOKE.ARPA Subject: Re: Infinite loops Actually, any decent C compiler will optimize away "while(1)", so that it will be no less efficient than "for(;;)". Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3011 for JMS@ARIZMIS; Sun, 27-APR-1986 18:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 19:59:18 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014764; 27 Apr 86 20:54 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id aa28255; 27 Apr 86 20:41 EDT Date: Sun, 27 Apr 86 20:40:39 EDT From: Doug Gwyn (VLD/VMB) To: Henry Spencer cc: info-c@BRL-SMOKE.ARPA Subject: Re: A simple non-portable expression tha "provided the types of the operands ... are not changed by this regrouping" to me covers the case of a change in "widening" also. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3123 for JMS@ARIZMIS; Sun, 27-APR-1986 18:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 20:16:05 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014827; 27 Apr 86 21:06 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a028324; 27 Apr 86 20:52 EDT Date: Sun, 27 Apr 86 20:46:45 EDT From: Doug Gwyn (VLD/VMB) To: Sam Kendall cc: info-c@BRL-SMOKE.ARPA Subject: Re: void * [also malloc] The idea is, conversion to/from (void *) is legal, but conversion to/from (char *) would generate a warning. Little would be gained by relaxing the alignment constraint when malloc()ing very small objects (less than the alignment quantum). Even malloc(1) actually will use up much more than one byte of storage, for the bookkeeping overhead. It is simpler to leave malloc() defined the way it is; why add complexity when it doesn't gain much? Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3270 for JMS@ARIZMIS; Sun, 27-APR-1986 18:54 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 20:49:02 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014929; 27 Apr 86 21:27 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a028484; 27 Apr 86 21:13 EDT Date: Sun, 27 Apr 86 20:58:39 EDT From: Doug Gwyn (VLD/VMB) To: Tom Keller cc: info-c@BRL-SMOKE.ARPA Subject: Re: void * If your C compiler doesn't understand "void" (which has been in the language for years; X3J11 did not invent it, just (void *)), or lacks bit fields, enums, struct assignment, __LINE__, decent library routines, etc., then I would think you would want to get it fixed. Even the compiler on my Apple //e understands most of these (as well as (void *))! Didn't you pay for vendor support? I have a header file I #include in my applications, that is set up on different systems to compensate for such things and to provide a uniform set of extensions such as boolean data type. Here are some relevant excerpts for a relatively puny system: typedef char *pointer; /* generic pointer (void *) */ #define const /* nothing */ /* (undefine for ANSI C) */ #define signed /* nothing */ /* (undefine for ANSI C) */ #define volatile /* nothing */ /* (undefine for ANSI C) */ #define strchr index /* 7th Edition UNIX, 4.2BSD */ #define strrchr rindex /* 7th Edition UNIX, 4.2BSD */ #define void int /* K&R Appendix A followers */ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3320 for JMS@ARIZMIS; Sun, 27-APR-1986 19:11 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 21:04:06 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014955; 27 Apr 86 21:39 EDT Received: from USENET by SMOKE.BRL.ARPA id a028661; 27 Apr 86 21:29 EDT From: Doug Gwyn Newsgroups: net.unix-wizards,net.bugs.4bsd,net.lang.c Subject: Re: C startup in /lib/crt0.o Message-ID: <327@brl-smoke.ARPA> Date: 28 Apr 86 01:28:57 GMT To: info-c@BRL-SMOKE.ARPA In article <100@cstvax.UUCP> simon@cstvax.UUCP (Simon Brown) writes: > >I see that the C startup routine _start in /lib/crt0.o under 4.2BSD >is a bit over-protective, in that it calls routine _exit (rather than >the system-call __exit) when it terminates. > >Does anyone know why? (or care, for that matter). >I suppose it does no harm really (except load in 4k of stdio-library >garbage, which I could really cope without!). Return from main() is legally required to be equivalent to invoking exit(), not _exit(), with parameter equal to the return value of main(). If your C library is set up correctly, exit() should not force stdio code to be linked in (although some of the other C library routines you invoke might use stdio). The _cleanup() function exists in two places in reasonable UNIX C libraries; once in a stdio module and once in a stub module just to vacuously satisfy the call when stdio isn't used. The X3J11 onexit() function provides an even better solution, but it has met with stiff opposition from IEEE 1003.1 members, for some reason. They also seem to have trouble with exit() and _exit(). I don't understand the objections; it seemed okay to me. Perhaps they're unaware of the point explained in my previous paragraph. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3584 for JMS@ARIZMIS; Sun, 27-APR-1986 19:55 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/27/86 at 21:52:03 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015160; 27 Apr 86 22:32 EDT Received: from brl-tgr.arpa by SMOKE.BRL.ARPA id a029254; 27 Apr 86 22:13 EDT Received: from mitre-bedford.arpa by TGR.BRL.ARPA id a000415; 27 Apr 86 22:05 EDT Full-Name: James R. Vanzandt Message-Id: <8604280206.AA19841@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: info-c@BRL-TGR.ARPA Cc: jrv@MITRE-BEDFORD.ARPA Subject: lint query Date: Sun, 27 Apr 86 22:06:02 -0500 From: "James R. Van Zandt" I'm aware of four lint-type programs for checking C code on an MS-DOS machine: PC-LINT Tecware $ 99 PC-Lint Gimpel Software $139 Pre-C Phoenix Computer Products Corp. $395 Lint Wizard Systems Software, Inc. $450 (bundled with compiler) Can anyone report experience with these or others, or point to published reviews? Please send messages to me directly, as I don't monitor info-c. If there's sufficient interest, I'll be glad to post a summary. - Jim Van Zandt Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3738 for JMS@ARIZMIS; Sun, 27-APR-1986 20:25 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 04/27/86 at 22:19:41 CDT Received: from Hamlet.Caltech.Edu by SRI-KL.ARPA with TCP; Sat 26 Apr 86 17:12:59-PST Received: from Xhmeia.Caltech.Edu by Hamlet.Caltech.Edu with DECNET ; Sat, 26 Apr 86 17:14:18 PST Date: Sat, 26 Apr 86 17:08:27 PST From: zar%Xhmeia.Caltech.Edu@Hamlet.Caltech.Edu Subject: VAX VMS C Question To: info-vax@sri-kl.arpa X-ST-Vmsmail-To: ST%"info-c@brl.arpa",ST%"info-vax@sri-kl.arpa" I'm trying to convert some C code I have to VAX-11 C and there appears to be no VAX-11 C system routine FGETS (three args ; buf, sizofbuf, filepointer). Has someone already made this so I don't have to do it myself (I'm not a real C programmer). Please reply directly to me and thanks in advance. Zar (Dan Zirin) ZAR%XHMEIA@HAMLET.CALTECH.EDU (ZAR%XHMEIA@HAMLET.ARPA) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4992 for JMS@ARIZMIS; Mon, 28-APR-1986 01:22 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 04/28/86 at 03:14:15 CDT Received: from ucbvax.berkeley.edu by SRI-KL.ARPA with TCP; Sun 27 Apr 86 05:13:46-PDT Received: by ucbvax.berkeley.edu (5.48/1.11) id AA15490; Sun, 27 Apr 86 05:10:56 PDT Date: Sun, 27 Apr 86 05:10:56 PDT From: ihnp4!ttrdc!levy@ucbvax.berkeley.edu Message-Id: <8604271210.AA15490@ucbvax.berkeley.edu> Received: by ihnp4.ATT.COM id AA17302; 27 Apr 86 07:02:05 CDT (Sun) To: ucbvax!info-vax Subject: problem with VMS C getenv() with a Fortran main Fellow VMessers: I am having difficulty trying to get the VMS C getenv() to work correctly (actually, at all!) when the main program is a Fortran routine. It works fine if the main routine is in C, even if there are Fortran routines in the calling chain between the main C routine and the C routine that uses getenv(). However, if the main routine is a Fortran routine, getenv() will blow up with an access violation. Example: C C BLOWUP.FOR C CALL EXPLODE END /* explode.c */ explode() { char *c; char *getenv(); c = getenv("USER"); /* Here is where the access violation happens */ if (c) printf("USER=%s\n",c); else printf("No value for environment variable USER\n"); } $ FORTRAN BLOWUP $ CC EXPLODE $ LINK BLOWUP,EXPLODE,SYS$LIBRARY:CRTLIB/LIB $ RUN BLOWUP %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC=0000105F, PSL=03C00004 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 0000105F 0000105F EXPLODE EXPLODE 6 00000012 0000101F BLOWUP$MAIN BLOWUP$MAIN 4 00000009 00001009 If I make the Fortran main program into a subroutine and use a C main() to call THAT, it works just fine. I have a feeling that the C startup routines are doing something to make getenv() work, but I would rather hope that getenv() would at least return a null pointer to indicate that it does not know what to do, instead of blowing up. What I was really hoping to do was to use it as a semi-portable way of getting at logical names (which getenv() appears to do under VMS C for strings other than three or four special ones such as "USER") that I could also use under Unix by setting the appropriate environment variable from the shell before invoking the program. So is there, perhaps, a routine that I could call from my Fortran program (or the C subroutine that uses getenv()) which would keep getenv() from blowing up when I use it later? If it is of any information, I am using a version 1 edition of vax11c (I have heard that the version 2 edition is much better, but I haven't had a chance to get it yet). Thanks much, in advance. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6755 for JMS@ARIZMIS; Mon, 28-APR-1986 07:44 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/28/86 at 09:38:22 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023286; 28 Apr 86 10:26 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a005871; 28 Apr 86 9:42 EDT Received: from lll-crg.arpa by AOS.BRL.ARPA id a021495; 28 Apr 86 9:34 EDT Received: by lll-crg.ARPA id AA27484; Mon, 28 Apr 86 06:34:12 pdt id AA27484; Mon, 28 Apr 86 06:34:12 pdt Date: Mon, 28 Apr 86 06:34:12 pdt From: cuuxb!rsb@LLL-CRG.ARPA Message-Id: <8604281334.AA27484@lll-crg.ARPA> To: lll-crg!bentley!kwh@LLL-CRG.ARPA Subject: Re: Jumping into blocks Cc: lll-crg!info-c@BRL.ARPA >>So, assuming that goatooze are acceptable for error handling, but jumping >>into a block is forbidden, what's the best way to write this? Use two >>braches, and hide the common code at the bottom of main()? Set an error >>flag and test it outside the while? (Ugh, that requires an artificial >>boolean *and* a break statement.) Make usage() a non-returning function >>instead of a label? (My usual preference.) Duplicate the code? I've seen two variations that *I* prefer: 1) If you're in a condition that calls for bailing out, use a function that prints an error message (to the appropriate place) and call exit(). This is what I tend to use for usage/fatal error kinds of situations. 2) In some (kernel) routines, one may have several "error" conditions that have a common set of "cleanup procedures" (like setting an error code or some such thing) before returning. In this case, several "gohtoose" that wind up at the bottom of the routine seem the neatest (well, least sloppy) way of doing it. I've used the other variations that you mentioned, but wouldn't in anything that anyone else would have to see/support. Rich Brown Downers Grove, IL P.S. I take that back. I've never jumped into a block like that. I think I would put that under the heading of "tacky". Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7837 for JMS@ARIZMIS; Mon, 28-APR-1986 09:42 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/28/86 at 11:26:52 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029858; 28 Apr 86 12:14 EDT Received: from bbn-prophet.arpa by SMOKE.BRL.ARPA id a009341; 28 Apr 86 12:02 EDT Date: Mon, 28 Apr 86 12:00:47 EDT From: Dan Franklin To: Doug Gwyn cc: info-c@BRL-SMOKE.ARPA Subject: Re: C startup in /lib/crt0.o I don't know why P1003.1 might object to onexit(), but I always thought it was a bit bizarre that it could not be declared correctly in C. It requires a recursive typedef typedef onexit_t onexit_t(onexit_t); which would, if it worked, define "onexit_t" to be a function whose sole argument, and return value, were of type "onexit_t". (The usage is that a caller supplies it with a function to be invoked on exit, and gets back some other function that the caller must arrange to be invoked on exit.) Even more odd is that the purpose of this unusual calling sequence is to permit a program to cascade an indefinite number of functions to be performed before exiting, but X3J11 still specifies that the implementation must support the registration of at least 32 functions (April 1985 draft, but I bet this hasn't changed). If the number of functions can be finite and small, then obviously you can define onexit() to take one argument which is a function to call; no funny return value, no additional arrangements to be made by the caller. The routine would just keep a static array of functions to call. And it could be declared in C. The additional benefit to be gained by the current "generalization" to any number of functions seems marginal to me. Dan Franklin Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9493 for JMS@ARIZMIS; Tue, 29-APR-1986 10:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 12:01:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003368; 29 Apr 86 12:40 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id aa18997; 29 Apr 86 12:32 EDT Date: Tue, 29 Apr 86 12:22:08 EDT From: Doug Gwyn (VLD/VMB) To: Tom Lanning cc: info-c@BRL-SMOKE.ARPA Subject: Re: oops, corrupted memory again! If you check the malloc source code, you'll see that it can be compiled with debugging checks turned on; the version in the C library has them disabled. I suggest keeping the debugging malloc.o around somewhere like /usr/lib so everyone can get it when needed. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8535 for JMS@ARIZMIS; Tue, 29-APR-1986 10:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 10:36:00 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000595; 29 Apr 86 11:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a015077; 29 Apr 86 10:19 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: void * Message-ID: <766@bentley.UUCP> Date: 28 Apr 86 20:16:17 GMT To: info-c@BRL-SMOKE.ARPA In article <194@gilbbs.UUCP> gilbbs!mc68020 writes: > Well, that's just great! The C compiler on my system doesn't understand >such niceties as void. So what do we do? (do *NOT* tell me to get another >compiler, there *IS* no other compiler available for this system!) What I've done in the past is "typedef int void;" or "cc -Dvoid=int" when trying to port new code to old compilers. Now suddenly void takes on a new meaning. Hmm, I'd say your best bet (other than getting a compiler that understands at least the current standard) is to process any such sources with a sed script (or something smarter) to change "void *" to "char *" and other "void" to "int". Actually, I don't think "void *" will start showing up in programs for a while after it becomes "standard". Maybe someone will upgrade your compiler in the meantime? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6863 for JMS@ARIZMIS; Tue, 29-APR-1986 10:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 07:48:02 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a019768; 29 Apr 86 8:32 EDT Received: from USENET by SMOKE.BRL.ARPA id a009919; 29 Apr 86 7:46 EDT From: Don Steiny Newsgroups: net.lang.c Subject: Re: Infinite Loops Message-ID: <645@scc.UUCP> Date: 26 Apr 86 05:38:05 GMT To: info-c@BRL-SMOKE.ARPA ** This loop looked strange to me, but I felt kind of silly when I realized that it is perfectly good C. main() { main(); } It loops until it overflows the stack. -- scc!steiny Don Steiny @ Don Steiny Software 109 Torrey Pine Terrace Santa Cruz, Calif. 95060 (408) 425-0382 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7613 for JMS@ARIZMIS; Tue, 29-APR-1986 10:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 09:18:06 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a027776; 29 Apr 86 10:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a013867; 29 Apr 86 9:47 EDT From: Bennett Broder Newsgroups: net.micro,net.micro.pc,net.lang.c,net.unix-wizards Subject: Help with C-kermit on SCO Xenix V Message-ID: <294@catnip.UUCP> Date: 26 Apr 86 16:37:46 GMT Keywords: It isn't working Xref: seismo net.micro:15200 net.micro.pc:8485 net.lang.c:8919 net.unix-wizards:17939 To: info-c@BRL-SMOKE.ARPA I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. We have been using this version at work on a Perkin Elmer 3250XP and an AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix. Well the package compiles without error, and appears to work okay, until you attempt to do a transfer. Then it can't even seem to get past the header packet, and keeps printing SS%S%S%S%S% and the like on the screen. Looking at the debugging output from both ends show that the Xenix machine is computing the checksum incorrectly. Please, can anyone help??? -- Ben Broder {ihnp4,decvax} !hjuxa!catnip!ben {houxm,topaz}/ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7672 for JMS@ARIZMIS; Tue, 29-APR-1986 10:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 09:22:58 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a027857; 29 Apr 86 10:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a013878; 29 Apr 86 9:47 EDT From: KW Heuer Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <763@bentley.UUCP> Date: 27 Apr 86 19:27:12 GMT Xref: seismo net.lang.c:8920 net.lang.c++:175 To: info-c@BRL-SMOKE.ARPA In article <4495@cbrma.UUCP> cbrma!trl (Tom Lanning) writes: > Are there any "malloc" routines that check for modification of >malloc's link pointers by the "user's" code? Close to 70% of by bugs >are stack/memory problems were I use more space than I allocated. As mentioned in the man page, the malloc() code has a compile-time option for strict checks on the arena. (This is not too useful if you have no source code, of course.) In C++, you can define a datatype that works like a pointer but does run-time bounds checking; this requires changing your declarations from "char *" to "vector" (or whatever). Now, if only somebody would invent an architecture where all objects, including dynamicly allocated objects, are isolated in memory, then any subscript error would cause an immediate memory fault. You'd still be vulnerable to completely wild pointers (but less likely in a huge address space), and overflow of an array inside a structure might be untrappable, but otherwise it sounds like a great machine to do your debugging on. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8057 for JMS@ARIZMIS; Tue, 29-APR-1986 10:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 09:56:30 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028696; 29 Apr 86 10:27 EDT Received: from USENET by SMOKE.BRL.ARPA id a014673; 29 Apr 86 10:09 EDT From: Don Libes Newsgroups: net.lang.c Subject: multitasking in one process (4.2BSD) Message-ID: <269@nbs-amrf.UUCP> Date: 27 Apr 86 14:09:02 GMT To: info-c@BRL-SMOKE.ARPA > I an not aware of the situation for C++, but there is a stand alone > Multitasking package avaiable for C (for free). It runs under Unix, > is compatible with dbx, and can be set to interleave the execution of > the arbitrary number of tasks every instruction if so desired. It I had the mispleasure of porting an application on a standalone 68000 to a Sun. Only problem was that the application was a set of multitasking procedures that shared a lot of data structures. For efficiency, my only choice was to get the whole mess to run as one UNIX process. The result is an operating system in a process. Unlike what is described above, scheduling is based upon timers, ASTs (ala VMS) or waiting for an event. While a bitch to debug itself (mainly because of the 4.2 software timers), you can play with your whole system under dbx, watching every process. It's certainly free. Let me know if anyone is interested. If there are enough requests, I might even document it and send it to mod.sources. Don Libes {seismo,umcp-cs}!nbs-amrf!libes Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8371 for JMS@ARIZMIS; Tue, 29-APR-1986 10:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 10:22:12 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000650; 29 Apr 86 11:07 EDT Received: from USENET by SMOKE.BRL.ARPA id a015274; 29 Apr 86 10:24 EDT From: "Daniel M. Frank" Newsgroups: net.lang.c,net.lang.c++,net.arch Subject: Re: oops, corrupted memory again! Message-ID: <117@prairie.UUCP> Date: 28 Apr 86 15:58:11 GMT Xref: seismo net.lang.c:8931 net.lang.c++:177 net.arch:3247 To: info-c@BRL-SMOKE.ARPA ------------- >Now, if only somebody would invent an architecture where all objects, >including dynamicly allocated objects, are isolated in memory, then any >subscript error would cause an immediate memory fault. If I'm not mistaken, this was done on the iAPX432, using a capability- based addressing scheme. Dimmed the lights. You could probably construct such an environment on the 80286, but no one does, probably for efficiency reasons. You're probably better off with a language that compiles checks into the code, and an option to turn off those checks once you're confident (?!) of the program. With a capability-based architecture, you pay the price all the time, whether you want to or not. -- Dan Frank ... uwvax!geowhiz!netzer!prairie!dan -or- dan@caseus.wisc.edu Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5871 for JMS@ARIZMIS; Tue, 29-APR-1986 10:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 04:38:13 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015948; 29 Apr 86 5:23 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a008208; 29 Apr 86 4:43 EDT Received: from nta-vax.arpa by AOS.BRL.ARPA id a015878; 29 Apr 86 4:38 EDT Date: Tue, 29 Apr 86 10:41:45 -0200 From: Stein-Erik Engbr}ten Posted-Date: Tue, 29 Apr 86 10:41:45 -0200 Message-Id: <8604290841.AA25304@nta-vax.ARPA> Received: by nta-vax.ARPA (5.31/3.21) id AA25304; Tue, 29 Apr 86 10:41:45 -0200 To: info-c@BRL.ARPA Subject: Include the va_end! In message <5336@alice.uUCp> Andrew Koenig () writes: >> I assume va_start be done in the original function. (Dito the first >> va_alist comment.) Does va_end have to be done in the original >> function also? (va_end does nothing in my implementation.) > >It should be. (va_end does nothing in every implementation I've seen) I have found an implementation which needs the va_end. It caused me a great deal of trouble - the source I was compiling (the SYSTEM_V source for curses!) had left out the va_end ("It doesn't do anything, so why bother..."). The implementation is on the Pyramid 90x machine, the System V part of it (it runs both 4.2 and System V at the same time!), where va_end is defined to be an '}'. So please, everybody - even if 'nobody' defines the va_end, include it all the same! Stein-Erik Engbr}ten Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3068 for JMS@ARIZMIS; Tue, 29-APR-1986 10:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/28/86 at 21:11:34 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014844; 28 Apr 86 21:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a005372; 28 Apr 86 21:42 EDT From: Tom Lanning Newsgroups: net.lang.c,net.lang.c++ Subject: oops, corrupted memory again! Message-ID: <4495@cbrma.UUCP> Date: 24 Apr 86 00:40:43 GMT Keywords: malloc free stack tools core Xref: seismo net.lang.c:8906 net.lang.c++:173 To: info-c@BRL-SMOKE.ARPA Are there any "malloc" routines that check for modification of malloc's link pointers by the "user's" code? Close to 70% of by bugs are stack/memory problems were I use more space than I allocated. Tracking this kind of problem is horrible. Once you get a core, if you get a core, you only know that malloc's data was corrupted; you do not know where or when. Since malloc's structures and algorithms are "hidden", a developer can not easily use the "stop when this address has been modified" feature of sdb. This problem is not unique to my code, I know others that are plagued by these bugs also. A programmer only needs one of these bugs in a large piece of software to waste a week of effort. I am aware of all the things I can and should do to prevent this, but what I am looking for is a tool or procedure to ** quickly ** locate where and when corruption is taking place. I am interested in any tools, recommendations, or routines that may help. Thanks. Tom Lanning AT&T Bell Laboratories Columbus Ohio 614-860-4153 -- Tom Lanning AT&T Bell Laboratories Columbus OH 43213 614-860-4153 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3336 for JMS@ARIZMIS; Tue, 29-APR-1986 10:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/28/86 at 21:47:21 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014922; 28 Apr 86 22:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a005393; 28 Apr 86 21:42 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Byte order (retitled) Message-ID: <2637@utcsri.UUCP> Date: 25 Apr 86 21:59:27 GMT To: info-c@BRL-SMOKE.ARPA In article <1117@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >In article <2590@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >>... > And I am saying that the following *should* be portable, and >that any implementation that it doesn't work on is brain-damaged. > > register int i; > unsigned char bytes[ sizeof( long )]; /* lo-byte first */ > long input; > register char *cvptr; > > for(cvptr = (char *)&input, i = 0; i < sizeof(long); i++) > bytes[i] = cvptr[i]; > Sorry - I thought you were suggesting that big-endian pointer conversions should set the lower bits (when pointing to a smaller object) and clear them (when pointing to a larger one). What you are actually saying is that any implementation which is not strictly little-endian is 'brain- damaged' (Including (a) PDP11 _longs_, (b) 68000). I will agree that (a) is brain-damaged, but I think the adjective is a little strong for (b). I am a little-end fan myself, but I can face reality, and the reality is there will be big-endian machines around that are still worth using, and that the 'problem' can be dealt with so easily that one needn't damn the 68K to eternal flames on this one point. -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7998 for JMS@ARIZMIS; Tue, 29-APR-1986 10:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 09:53:09 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028625; 29 Apr 86 10:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a014428; 29 Apr 86 10:02 EDT From: Martin Minow Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <208@decvax.UUCP> Date: 27 Apr 86 23:40:02 GMT Keywords: malloc free stack tools core Xref: seismo net.lang.c:8927 net.lang.c++:176 To: info-c@BRL-SMOKE.ARPA A requestor asks for tools to verify that malloc'ed memory hasn't been crashed. Decus C provides the following functions that could be adapted to your system: isalloc(pointer) returns 0, 1, -1 depending on whether the argument is not malloc'ed memory, is a pointer returned by malloc, or is a recently freed malloc result. $$mchk() Checks all memory allocated by malloc, crashes the program if the chains are corrupt. $$link() Prints the memory list on stderr (called by $$mchk() above. The implementation of $$mchk and isalloc depend on the way in which memory is organized and must be adapted to your specific system. Decus C uses the same organization as Unix V6 -- a linked list of pointers ascending in memory. $$mchk() will fail if the contents of a pointer is less than its address, unless the contents is the "memory head" location (in which case, the memory chain is correct). Depending on how your operating system's malloc was written, an $$mchk equivalent could be either very easy or impossible. Martin Minow decvax!minow Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8862 for JMS@ARIZMIS; Tue, 29-APR-1986 10:37 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 11:09:41 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001286; 29 Apr 86 11:21 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a015633; 29 Apr 86 10:34 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA11663; Tue, 29 Apr 86 10:35:31 edt Date: Tue, 29 Apr 86 10:35:31 edt From: root Message-Id: <8604291435.AA11663@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Re: Byte order (retitled) > In article <1117@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > >In article <2590@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: > >>... > > And I am saying that the following *should* be portable, and > >that any implementation that it doesn't work on is brain-damaged. > > > > register int i; > > unsigned char bytes[ sizeof( long )]; /* lo-byte first */ > > long input; > > register char *cvptr; > > > > for(cvptr = (char *)&input, i = 0; i < sizeof(long); i++) > > bytes[i] = cvptr[i]; > > > Sorry - I thought you were suggesting that big-endian pointer conversions > should set the lower bits (when pointing to a smaller object) and clear > them (when pointing to a larger one). What you are actually saying is > that any implementation which is not strictly little-endian is 'brain- > damaged' (Including (a) PDP11 _longs_, (b) 68000). I will agree that (a) > is brain-damaged, but I think the adjective is a little strong for (b). > I am a little-end fan myself, but I can face reality, and the reality is > there will be big-endian machines around that are still worth using, and > that the 'problem' can be dealt with so easily that one needn't damn > the 68K to eternal flames on this one point. > > "For every action there is an equal and opposite malfunction" > ---------------------------------------------------------------------- > Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg To all you Big Endian fans out there: What's your problem? You guys are the ones saying that the first byte is the most significant, so why are y'all bitchin that you don't get the low byte like on *sane* machines? Axually, I like the 680[012]0 also. Byte order doesn't really bother me either way except as an academic issue. I don't see the need or the possibility for your example to be both portable and work the way you described. The two are at odds. Remember, C does what you tell it to do, not what you think it should do. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7221 for JMS@ARIZMIS; Tue, 29-APR-1986 10:37 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 08:25:49 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020859; 29 Apr 86 8:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a009974; 29 Apr 86 7:47 EDT From: "Richard M. Geiger" Newsgroups: net.unix,net.lang.c,net.lang.pascal,net.lang.f77 Subject: UNIX OS / Language Validation Suites (summary) Message-ID: <456@mips.UUCP> Date: 27 Apr 86 00:42:52 GMT Xref: seismo net.unix:8097 net.lang.c:8918 net.lang.pascal:568 net.lang.f77:528 To: info-c@BRL-SMOKE.ARPA Original Posting: > From postnews Mon Mar 31 12:02:39 1986 > Subject: UNIX OS / Language Test & Validation Suites > Newsgroups: net.lang.f77,net.lang.c,net.lang.pascal,net.unix > Distribution: net > > I am interested in the availability, either commercially or in the public > domain, of test suites covering the following areas: > > - UNIX kernel (BSD / SYSV) & Utilities > - Compilers > - C > - Pascal > - Fortran 77 > > I already know of the SVVS and Perennial products. Please send mail > if you know of any others; I will summarize & post if volume warrants. > > And, of course, the usual apologies if this topic has been covered > recently... If there is already a summary out there somewhere, please > mail me a copy! > > Thanks. I received informative responses from: From: glacier!sun!ihnp4!cray!hrp Hal Peterson From: glacier!hplabs!hp-sdd!ncr-sd!steves Steve Schlesinger From: decwrl!seismo!mcvax!ukc!trh@SRI-IU.ARPA Tim Hopkins From: decwrl!amdcad!scgvaxd!tcville!pete!arndt Peter A. Arndt From: decwrl!sun!convex!tork Bill Torkelson jensen@uiowa (CSNET) Nancy Jensen Thanks to you all. If anyone knows of any other public domain or commercially available testing or validation tools covering these areas, please let me know! Summary of Responses: UNIX kernel / utilities: ------------------------ Package: Perennial UNIX Validation Suite Supplier: Perennial Suite 450 4677 Old Ironsides Drive Santa Clara, CA 95054 (408) 727-2255 This suite is available in both BSD 4.2 and SYSV flavors. Includes tests of system calls, library functions, and commands. Also, there are a few "exerciser" tests which stress the file system and virtual memory. Many of the command tests (ls, sed, awk, etc.) are *extremely* cursory, testing the absolute minimum level of functionality, such as "can I invoke this command and get a good return status?". Parts of the software which are the most machine dependent, (requiring the greatest porting effort), are tested more thoroughly. This is the only suite I presently know of aimed at validating 4.2 ports. I would love to hear of any others. Package: System V Verification Suite Supplier: AT&T Information Systems for ordering information contact: AT&T Information Systems Customer Information Center P.O. Box 19901 Indianapolis, Indiana 46219 This is the official validation tool for System V ports. It is intended to verify that a given SYSV port conforms to the SVID (System V Interface Definition). SVVS comes complete with an AT&T license agreement under which I am not allowed to say anything more about it... But what the heck, I'll go out on a limb and say (at least) that looks like a very good package from what I've seen so far, both of SVVS and of other OS validation suites. The suite follows the structure of the SVID, and knows about dependencies, so that the test programs employ only features which have previous validated (within reason). Package: AIM Benchmarks / Tuning tools Supplier: AIM Technology 4655 Old Ironsides Drive Suite 390 Santa Clara, CA 95054 While these aren't really meant as validation tools, they may be of use. From what little I know, the AIM benchmarks are a commonly used basis for performance comparisons between different UNIX systems. Pascal Suites: -------------- Package: Pascal Validation Suite a.k.a. "Tasmanian" Pascal Validation Suite a.k.a. "SALE" a.k.a. British Standard Institution Pascal Validation Suite Suppliers: Richard J Cichelli Software Consulting Services 901 Whittier Dr. Allentown, PA 18103 (215) 797-9690 I was also given another phone number for Software Consulting Services: (215) 837-8484 And yet another address and phone for S.C.S.: Ben Franklin Technology Center Suite 10 Murray H. Goodman Campus Lehigh University Bethleham, PA 18015 (215) 861-7920 This seems to be the only Pascal suite around... and it seems to have been around in several incarnations. The original version grew out of work by B.A. Wichmann and A.H.J. Sale at the University of Tasmania. It appears to now be under the control of the British Standards Institute. The suite tests against the the ISO 7185 (BS 6192) Pascal standard. The last address above may the the one to try first; I picked it up from a genuine printed document sent me by Nancy Jensen. I am very interested in learning about any Pascal suites which validate to ANSI Pascal. C Suites: --------- HCR C Test Suite Supplier: Human Computing Resources 10 St. Mary Street Toronto, Ontario, Canada M4Y 1P9 (416) 922-1937 An extensive C test & validation suite. This is apparently a tool which was originally developed by HCR to test their C compiler products, and later became a product in its own right. It is organized into three major divisions, called the breadth, minor depth, and major depth suites. The version I have seen tests conformity to K&R ("...tempered by what the System V VAX C compiler accepted, with obvious bugs removed."), pending the official acceptance of the ANSI C standard. The suite appears to be a very thorough set of tests, and comes with a menu-driven user interface. In all, HCR says the suite runs for about 60 hours on a VAX 11/750. Package: metaWare C validation suite Supplier: Frank DeRemer and Tom Pennello (Anybody have an address for these guys?) Hal Peterson reports that this suite sells for $750, and that the people listed as supplier are "with the ANSI C committee, X3J11". Perhaps they could be reached in care of X3J11? Package: C-Lance Supplier: RAPA (Ralph Phraner) (415) 752-8590 Hal Peterson reports that this suite sells for $10K. Package: Perennial C Compiler Validation Suite Supplier: Perennial Suite 450 4677 Old Ironsides Drive Santa Clara, CA 95054 (408) 727-2255 Available in VAX/VMS and MS-DOS, as well as UNIX versions. Validates against ANSI standard. $10K. FORTRAN 77 Suites: ------------------ Package: 1978 FORTRAN Compiler Validation Suite (FCVS78) Supplier: Federal Software Testing Center Two Skyline Place 5203 Leesburg Pike Falls Church, VA 22041 Available through U.S. Dept. of Commerce National Technical Information Service (I don't have the NTIS address) A validation package for compilers conforming to the ANS FORTRAN X3.9-1978 (FORTRAN-77) standard. "The tests are progressively complex exercises of statement combinations representing typical language usage. They can be used to evaluate compiler usability and conformance to the 1978 FORTRAN Standard, and can aid in precise identification of compiler flaws. The test case outputs are tailored to each of the tests involved in order to aid in the specific diagnosis of instances of nonconformance or of compiler errors." - from the FCVS78 abstract. Package: (name of package?) Supplier: CCTA (Central Computer and Telecommunications Agency) (in the U.K.) Hal Peterson mentioned this one. If anybody has more complete information, please send it to me! If you know of any packages which should be on this list but aren't, please send me mail. If there are any significant additions, I will add them to the list and repost. Once again, thanks to all who responded. *** The information given above reflects my own opinions only, which are *** not necessarily those of MIPS Computer Systems. -- -- -Richard Geiger UUCP: {decvax,ucbdvax,inhp4}!decwrl!mips!rmg DDD: (408) 720-1700 USPS: MIPS Computer Systems, 930 E. Arques Ave., Sunnyvale, CA 94086 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0223 for JMS@ARIZMIS; Tue, 29-APR-1986 11:31 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 13:15:05 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009001; 29 Apr 86 13:50 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a020029; 29 Apr 86 13:29 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA12149; Tue, 29 Apr 86 13:29:33 edt Date: Tue, 29 Apr 86 13:29:33 edt From: root Message-Id: <8604291729.AA12149@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, nbs-amrf!libes@seismo.ARPA Subject: Re: multitasking in one process (4.2BSD) > > I an not aware of the situation for C++, but there is a stand alone > > Multitasking package avaiable for C (for free). It runs under Unix, > > is compatible with dbx, and can be set to interleave the execution of > > the arbitrary number of tasks every instruction if so desired. It > > I had the mispleasure of porting an application on a standalone > 68000 to a Sun. Only problem was that the application was a set of > multitasking procedures that shared a lot of data structures. > > For efficiency, my only choice was to get the whole mess to run as > one UNIX process. The result is an operating system in a process. > > Unlike what is described above, scheduling is based upon timers, > ASTs (ala VMS) or waiting for an event. While a bitch to debug > itself (mainly because of the 4.2 software timers), you can play > with your whole system under dbx, watching every process. > > It's certainly free. Let me know if anyone is interested. If > there are enough requests, I might even document it and send it to > mod.sources. > > Don Libes {seismo,umcp-cs}!nbs-amrf!libes I once did a similar thing, except it was pretty much round robin and each task checked it's input queue each cycle for work to do. All we had to to was save our regs on our stack, point to the next proc entry, switch stack ptrs (need assembly for this) restore regs and go! Even this provided it's share of education tho! How strange to be sending this cross town & back when I am only a few hundred feet away from you physically (B358 Bldg 223). (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1521 for JMS@ARIZMIS; Tue, 29-APR-1986 13:37 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 15:26:13 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015126; 29 Apr 86 16:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a024120; 29 Apr 86 15:52 EDT From: "Wayne A. Christopher" Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <229@cad.UUCP> Date: 28 Apr 86 18:35:53 GMT Keywords: malloc free stack tools core Xref: seismo net.lang.c:8937 net.lang.c++:179 To: info-c@BRL-SMOKE.ARPA In article <4495@cbrma.UUCP>, trl@cbrma.UUCP (Tom Lanning) writes: > Are there any "malloc" routines that check for modification of > malloc's link pointers by the "user's" code? Close to 70% of by bugs > are stack/memory problems were I use more space than I allocated. You could compile the 4.3 malloc() with the -DRCHECK flag, which checks that you haven't modified the areas beyond your segment when you free it. Also, if you're REALLY paranoid, write your own malloc that puts lots of padding around the allocated areas and checks that none of the padding areas has been changed every time you call malloc() or free(). Wayne Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3515 for JMS@ARIZMIS; Tue, 29-APR-1986 17:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 19:17:33 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015554; 29 Apr 86 16:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a024360; 29 Apr 86 15:58 EDT From: Chris Shaw Newsgroups: net.lang,net.lang.c Subject: Re: Re: Re: Re: Re: Re: Re: ... C builtin functions Message-ID: <925@watdragon.UUCP> Date: 27 Apr 86 22:22:37 GMT Xref: seismo net.lang:2470 net.lang.c:8938 To: info-c@BRL-SMOKE.ARPA This discussion is getting really boring. (Yes I know I can "n" past them, but that's not the point). Could people who have a burning desire to talk this to death please stop (or do so by mail) ? I'm getting rather sick of sizeof blah. Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath University of Waterloo Bogus as HELL !!! Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3604 for JMS@ARIZMIS; Tue, 29-APR-1986 17:42 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 19:30:26 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015591; 29 Apr 86 16:28 EDT Received: from USENET by SMOKE.BRL.ARPA id a024723; 29 Apr 86 16:08 EDT From: Guido van Rossum Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <6889@boring.UUCP> Date: 25 Apr 86 02:04:57 GMT Apparently-To: rnews@mcvax To: info-c@BRL-SMOKE.ARPA In article <3186@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: >>[plea for lint to check printf formats] >Ok, there *is* a way to do this. One of the europeans (that guy that >had been doing Hack) posted a tool for aiding lint last year sometime. >[rough explanation of the idea] This code is still available; I can mail it to interested parties. The author is called Andries Brouwer (and currently not at our institute but in Denmark). I've also heard that system 5 lint has this built-in; there's even a directive /*PRINTFLIKE*/ so you can define your own. >>... The following is a borderline case: >> printf( c<' '|| c>'\176'? "\\%3o":"%c", c); >I dunno what it would do with this case... It gives up here. There is a limit to what you can check. >One thing that occurs to me... do char's always get casted to ints >when they're arguments to functions????? Yes, definitely. And so do shorts. This is supposed to be standard knowledge amongst posters to this group! (At least posters that answer questions.) -- Guido van Rossum, CWI, Amsterdam Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3723 for JMS@ARIZMIS; Tue, 29-APR-1986 17:53 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/29/86 at 19:36:38 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015601; 29 Apr 86 16:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a024751; 29 Apr 86 16:08 EDT From: Kay Dekker Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <475@snow.warwick.UUCP> Date: 26 Apr 86 07:49:23 GMT To: info-c@BRL-SMOKE.ARPA In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >After three years of C programming I'm just starting to use lint, so >please no negative reinforcement by flaming about how stupid my questions >are, lest I give up on it entirely :-). Mark, I'm not flaming you, but I *am* worried! If you've been programming in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* lint. You have my profound sympathy. OR 2) Nobody ever taught you about using lint. I wonder why not? OR 3) You never realised that using lint was important. You must have wasted many hours (that you could have spent playing Rogue or whatever :-)) chasing problems down that lint might well have indicated to you. People, what are *we* doing wrong when somebody can spend 3 years programming in a particular language and only then start using one of the most important development tools for it? It's got to the point when if I'm doing program surgery and someone comes up saying that their program "doesn't work", if they haven't brought a line-numbered listing of the source AND a lint output, I don't really want to start looking for the problems. Kay. -- "I AM; YOU ARE; HELLO: all else is poetry" ... mcvax!ukc!warwick!kay Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0767 for JMS@ARIZMIS; Wed, 30-APR-1986 08:40 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/30/86 at 10:30:07 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029447; 30 Apr 86 11:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a011920; 30 Apr 86 10:08 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: Jumping into blocks Message-ID: <1324@mmintl.UUCP> Date: 28 Apr 86 22:40:15 GMT To: info-c@BRL-SMOKE.ARPA In article <737@bentley.UUCP> kwh@bentley.UUCP writes: >So, assuming that goatooze are acceptable for error handling, but jumping >into a block is forbidden, what's the best way to write this? Use two >branches, and hide the common code at the bottom of main()? Yes. Exception handlers belong at the bottom of the routine. It isn't "hidden" there -- that's the first place I would look for it. I would describe it as being hidden in your code (for whichever case it is being jumped to). Duplicating the code is also acceptable. It depends mostly on a comparison of two considerations: (1) how likely are there to be more instances where the code is to be used in later versions of the routine, and (2) how likely is it that later versions will want a different error message for the two cases? Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1656 for JMS@ARIZMIS; Wed, 30-APR-1986 10:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/30/86 at 11:14:42 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001719; 30 Apr 86 12:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a001881; 30 Apr 86 11:54 EDT From: Sam Kendall Newsgroups: net.lang.c Subject: Re: oops, corrupted memory again! Message-ID: <142@delftcc.UUCP> Date: 29 Apr 86 15:06:17 GMT Keywords: malloc free stack tools core To: info-c@BRL-SMOKE.ARPA In article <4495@cbrma.UUCP>, trl@cbrma.UUCP writes: > Are there any "malloc" routines that check for modification of > malloc's link pointers by the "user's" code? Close to 70% of by bugs > are stack/memory problems were I use more space than I allocated. Tracking > this kind of problem is horrible. > .... > This problem is not unique to my code, I know others that are > plagued by these bugs also. A programmer only needs one of these bugs > in a large piece of software to waste a week of effort. > .... > I am interested in any tools, recommendations, or routines that may > help. Thanks. The Bcc Compiler, a tool made by Delft Consulting Corp., catches bugs of this sort (as one case of "pointer out of bounds") and tells you exactly where in your source the transgression occurred. An item about Bcc was recently posted to mod.newprod. Please contact me for more info. Also, if you have source, you can recompile malloc to check its internal pointers stringently. At least you could on V7, and I doubt anyone has removed this capability. This won't locate your bug, but it might help. ---- Sam Kendall { ihnp4 | seismo!cmcl2 }!delftcc!sam Delft Consulting Corp. ARPA: delftcc!sam@NYU.ARPA 432 Park Avenue South Phone: +1 212 243-8700 New York, NY 10016 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1848 for JMS@ARIZMIS; Wed, 30-APR-1986 10:52 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 04/30/86 at 11:25:54 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001732; 30 Apr 86 12:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a001889; 30 Apr 86 11:54 EDT From: Sam Kendall Newsgroups: net.lang.c Subject: Alignment of malloc return value (Re: void * [also malloc]) Message-ID: <143@delftcc.UUCP> Date: 29 Apr 86 18:18:14 GMT To: info-c@BRL-SMOKE.ARPA In article <219@cad.UUCP>, faustus@cad.UUCP writes: > In article <141@delftcc.UUCP>, sam@delftcc.UUCP (Sam Kendall) writes: > > Currently, `malloc(1)' must return a maximally > > aligned pointer! This prevents an implementation which does something > > space-efficient with small allocations. > > "Maximally aligned" generally means aligned to a multiple of the wordsize of > the machine, so you don't lose much space (malloc ususally allocates an > extra word anyway before the space for a pointer anyway...) I guess that > you wouldn't lose much if you allowed malloc(1) to return an unaligned > byte, but it isn't worth the trouble... Doug Gwyn responded similarly to faustus@cad.UUCP, so I'll elaborate on what I meant. A common allocation algorithm, not used in standard UNIX malloc(3) but perhaps available in sVr2's malloc(3X) or 4.2 BSD's malloc(3), is to preallocate a contiguous set of pages for each blocksize below some small threshold. Thus one set of pages would be allocated for 1-byte blocks, another set of pages for 2-byte blocks, and so on. (Above the threshold, some other algorithm is used.) You can tell by the address of an area how large it is, simply by checking which set of pages it is in. You can keep track of which blocks are allocated by using a bitmap. If you are allocating many small blocks, this algorithm surely is "worth the trouble", since it is extremely fast and wastes no space. It is particularly good on a paging OS. The current man pages for malloc(3) and malloc(3X) prohibit such an algorithm, because they say that Each of the allocation routines returns a pointer to space suitably aligned (after possible pointer coercion) for storage of any type of object. And this implies: even one larger than the allocated space. This is true for V7 malloc, but not for the algorithm described above. I'm just suggesting that the man page be corrected to say, "... small enough to fit in the allocated space", or something like that. I wasn't very clear about this suggestion in my previous posting; thanks to alice!ark for clarifying this. There is a more general point lurking here: a man page should describe a function's _interface_. The man page may note additional constraints imposed by the current _implementation_, but notes on the implementation should be separated from the description of the interface. The C language sometimes encourages people to confuse the abstraction (interface) with the implementation, and I think I see this confusion reflected in the way UNIX is documented. AT&T has taken some steps to correct this confusion, probably as a side effect of writing the System V Interface Definition. Berkeley, on the other hand, gets worse with each release. So my complaint about malloc's man pages on various UNIX systems is really that they describe the current implementations too specifically (and perhaps incorrectly). The DESCRIPTION should say less, leaving room for other implementations. Notes about the current implementation should be in a separate NOTES section of the man page. ---- Sam Kendall { ihnp4 | seismo!cmcl2 }!delftcc!sam Delft Consulting Corp. ARPA: delftcc!sam@NYU.ARPA Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8010 for JMS@ARIZMIS; Wed, 30-APR-1986 23:47 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/01/86 at 01:34:49 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023683; 30 Apr 86 23:25 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a013797; 30 Apr 86 22:54 EDT Received: from juliet.caltech.edu by AOS.BRL.ARPA id a023578; 30 Apr 86 22:43 EDT Date: Wed, 30 Apr 86 19:43:32 PDT From: "William E. Woody" Message-Id: <860430194332.01s@Juliet.Caltech.Edu> Subject: LINT To: info-c@juliet.caltech.edu Comment: Some assembly required. > > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do.... > > (Root Boy) Jim Cottrell Here here! Though (whenever possible) I try to run my code through lint, I think I only use about a fifth of what lint complains (screams, shouts, moans, groans) about. And running my code through lint is not a happy little chore that I do just before running my code and going to sleep at night; it's a horrible little task (akin to turning homework into the mean little ol' silver haired english teacher, knowing she's going to slash my entire paper apart). But that fifth of information lint does cough up is extremely nice; sometimes when you're tired and have about three million four byte structures bouncing about in your code and it's four in the morning and the program must be finished at nine; your girlfriend left you for your roommate and no companies on the west coast is willing to offer you a summer job between school years, it sure is nice to know that you accidently put an extra '*' before one of your pointers (a silly typo, I know) which will blow up and burn away the mainframe your working on. (And when your roommate is the sysman, WATCH OUT!) By the way, does anyone know if a public domain LINT exists? Or an inexpensive one for my little Macintosh here? Unprotected memory sure is a pain to find when you mess up the pointers. - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7970 for JMS@ARIZMIS; Wed, 30-APR-1986 23:47 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/01/86 at 01:32:09 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023334; 30 Apr 86 21:49 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a012352; 30 Apr 86 21:10 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA14539; Wed, 30 Apr 86 11:03:53 edt Date: Wed, 30 Apr 86 11:03:53 edt From: Root Boy Jim Message-Id: <8604301503.AA14539@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, warwick!kay@seismo.ARPA Subject: Re: questions from using lint > In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: > >After three years of C programming I'm just starting to use lint, so > >please no negative reinforcement by flaming about how stupid my questions > >are, lest I give up on it entirely :-). > > Mark, I'm not flaming you, but I *am* worried! If you've been programming > in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* > lint. You have my profound sympathy. OR 2) Nobody ever taught you about > using lint. I wonder why not? OR 3) You never realised that using lint > was important. You must have wasted many hours (that you could have spent > playing Rogue or whatever :-)) chasing problems down that lint might well > have indicated to you. > > People, what are *we* doing wrong when somebody can spend 3 years programming > in a particular language and only then start using one of the most important > development tools for it? > > It's got to the point when if I'm doing program surgery and someone comes up > saying that their program "doesn't work", if they haven't brought a > line-numbered listing of the source AND a lint output, I don't really want > to start looking for the problems. > Kay. > -- > "I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay You people fail to realize that some of us out here don't like lint. It complains too much about what I do. I refuse to go any further than generating no compiler warnings. I know what I'm doing. When I goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. Before you start flaming my style, let me say I am quite good. I am also quite philosophical and attentive to coding style. My outlook is just different. I program for myself. If it is applicable to you, fine. I have my own criteria which I rarely see embraced by others waving standardization flags. Most of the code I have written was intrinsically non-portable. I *do* appreciate portability as a spectrum concept, but not as a binary one. This is just me. I'm not sure I would recommend my methods to anyone else, especially novices. My experience was obtained with more than a few battle scars. There are probably easier ways. (Root Boy) Jim Cottrell "I'm alright, Jack, keep your hands off of my stack" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9435 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:05 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/01/86 at 23:47:44 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015005; 1 May 86 20:02 EDT Received: from USENET by SMOKE.BRL.ARPA id a004727; 1 May 86 19:49 EDT From: "Daniel R. Levy" Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <854@ttrdc.UUCP> Date: 29 Apr 86 23:50:24 GMT To: info-c@BRL-SMOKE.ARPA In article <140@toram.UUCP>, roe@toram.UUCP writes: >In article <577@ur-helheim.UUCP> badri@ur-helheim.UUCP (Badri Lokanathan) writes: >>My question is the following: is there any reason (other >>than personal preferance) why one would prefer to use any particular form? >>I personally prefer the while(1) form since it seems to make better reading. >>Even better, I sometimes define TRUE to be 1 and then use while(TRUE). >Unless you have a very unique optimizer, it is usually better to use the >for(;;) form rather than the while(1) form. Reason is: while(1) is >ALWAYS evaluated (ie. : is 1 TRUE? if so, continue) before each iteration, >whereas for(;;) compiles as a simple branch or jump instruction with no >test and no conditional branch. > Roe Peterson What very unique optimizer? Here's what I get (SysV 3B20, cc -S [note no -O]): $ cat > while1.c main() /* while1.c */ { register int a=0; while (1) a++; } ^D$ cc -S while1.c $ cat while1.s .file "while1.c" .data .text .align 4 .def main; .val main; .scl 2; .type 044; .endef .globl main main: save &.R1 addw2 &.F1,%sp movw &0,%r8 .L14: addw2 &1,%r8 jmp .L14 ^^^^^^^^^^^^ .L13: .L12: ret &.R1 .set .R1,1 .set .F1,0 .def main; .val .; .scl -1; .endef .data $ cc -c while1.s $ dis while1.o **** DISASSEMBLER **** disassembly for while1.o section .text main() 0: 7a10 save &0x1,&0x0 2: 346c 0000 0000 000b addw2 &0x00000,%sp a: 1508 movw &0x0,%r8 c: 1118 addw2 &0x1,%r8 e: 9002 br -0x2 ^^^^^^^^^^^^^^^^ 10: 7b10 ret &0x1 12: dede nop -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9478 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:05 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/01/86 at 23:55:09 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015036; 1 May 86 20:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a004596; 1 May 86 19:44 EDT From: Vicarious Oyster Newsgroups: net.lang.c Subject: Re: Why we don't use lint Message-ID: <2167@uwmacc.UUCP> Date: 30 Apr 86 15:12:51 GMT Followup-To: net.cse To: info-c@BRL-SMOKE.ARPA In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes: >In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >>After three years of C programming I'm just starting to use lint, so >>please no negative reinforcement by flaming about how stupid my questions >>are, lest I give up on it entirely :-). > >Mark, I'm not flaming you, but I *am* worried! If you've been programming >in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* >lint. You have my profound sympathy. OR 2) Nobody ever taught you about >using lint. I wonder why not? ... >People, what are *we* doing wrong when somebody can spend 3 years programming >in a particular language and only then start using one of the most important >development tools for it? Here's how getting a CS degree worked at the large state university I attended (no names, and no peeking at the message header :-): Course #1: "Oh, you're majoring in CS-- we'll teach you Simula." Course #2: "OK, now we'll teach you assembly language, but we won't spend much time on it 'cause you already know how to program." Course #3: "Well, I think it's about time you learn about data structures. Frankly, I don't know *how* you managed so long without them ! Incidentally, Simula is passe, do your assignments in Pascal. We'll spend 2-3 lectures teaching it to you." Course #4: "OK, time to write an OS/compiler/database. You'll be using C, the greatest language ever conceived. There'll be a 30 minute tutorial on C tomorrow night at 7:00." etc... So by the time one graduates, having barely enough time to get the languages straight, let alone finish assignments, is it any wonder that most CS degree holders ] have never even heard of lint? Of course, it may not be *quite* as bad as I made it seem, and it may have gotten better in the last 5 years (but then again, I didn't mention learning things like Modula and LISP, either). Of course, the people in the department will tell you, quite correctly, that universities do not teach programming, they teach Computer Science. However, I daresay most computer scientists will be earning their livelihood by programming. My opinion is that there should be *at least* a week-long workshop on programming in the real world, but this is getting a bit far afield from the C language, so I'll desist. Also, follow-ups have been directed somewhere else, just to keep the C readers happy. - Joel Plutchak uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster ARPA: uwvax!uwmacc!oyster@rsch.wisc.edu Can you say "opinion"? I *knew* you could! Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0627 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:06 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 01:50:09 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015115; 1 May 86 20:32 EDT Received: from USENET by SMOKE.BRL.ARPA id a004638; 1 May 86 19:45 EDT From: KW Heuer Newsgroups: net.lang.c,net.unix-wizards Subject: Re: arguments in registers Message-ID: <776@bentley.UUCP> Date: 30 Apr 86 15:44:33 GMT Xref: brl-sem net.lang.c:842 net.unix-wizards:1011 To: info-c@BRL-SMOKE.ARPA In article <1205@umcp-cs.UUCP> umcp-cs!chris (Chris Torek) writes: >Incidentally, I have not seen any optimising C compilers myself; >are there any available that would [inline expand]? Yes. I once got "caught" trying to time a call to nullf(). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0507 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:06 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015057; 1 May 86 20:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a005011; 1 May 86 20:00 EDT From: herndon%umn-cs.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <1700011@umn-cs.UUCP> Date: 25 Apr 86 03:27:00 GMT Nf-ID: #R:ur-helhe:-57700:umn-cs:1700011:000:120 Nf-From: umn-cs!herndon Apr 24 21:27:00 1986 To: info-c@BRL-SMOKE.ARPA For the infinite loop, I like the sequence #define ever ;; ... for(ever) { ... } Robert Herndon Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0421 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:06 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015046; 1 May 86 20:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a004929; 1 May 86 19:58 EDT From: KW Heuer Newsgroups: net.lang.c++,net.lang.c Subject: Re: System V preprocessor problem with Message-ID: <779@bentley.UUCP> Date: 30 Apr 86 19:50:41 GMT Xref: brl-sem net.lang.c++:163 net.lang.c:846 To: info-c@BRL-SMOKE.ARPA In article <3597@sun.uucp> sun!guy (Guy Harris) writes: >> #define name2(a,b) a/**/b >It has, however, two problems: > > 1) If you run your code through "lint", it won't work I tried this example with "cpp -C" and it worked fine. I'd guess that cpp strips all comments in preprocessor directives regardless of "-C". > 2) It is not a guaranteed property of the C language, but a > quirk of the implementation, so it will not work in > general. Agreed. Any application that depends on being able to do this is treading on thin ice. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0565 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:06 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015071; 1 May 86 20:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a005060; 1 May 86 20:02 EDT From: herndon%umn-cs.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: oops, corrupted memory again! Message-ID: <1700012@umn-cs.UUCP> Date: 29 Apr 86 21:05:00 GMT Nf-ID: #R:cbrma:-449500:umn-cs:1700012:000:614 Nf-From: umn-cs!herndon Apr 29 16:05:00 1986 To: info-c@BRL-SMOKE.ARPA You didn't post your address! A (partial) solution to the problem of not freeing/allocated memory was published in SIGPLAN Notices a few years back. Look in the May 1982 issue for "A Technique for Finding Storage Allocation Errors in C-language Programs", by David R. Barach, David H. Taenzer, and Robert E. Wells. The technique used in the article is fairly simple, and is more oriented towards finding allocation errors. Depending on the severity of your errors, their technique might be applicable. Robert Herndon ...!ihnp4!umn-cs!herndon herndon@umn-cs herndon.umn-cs@csnet-relay.ARPA Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0468 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:06 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015052; 1 May 86 20:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a005007; 1 May 86 20:00 EDT From: herndon%umn-cs.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <1700010@umn-cs.UUCP> Date: 25 Apr 86 03:19:00 GMT Nf-ID: #R:brl-smok:-252400:umn-cs:1700010:000:1259 Nf-From: umn-cs!herndon Apr 24 21:19:00 1986 To: info-c@BRL-SMOKE.ARPA I feel compelled to go on record as being VERY MUCH AGAINST having reserved procedure names in C. For those of us who have ever written stand-alone code for PDP-11s, VAXen, ..., it is a simple matter, as things stand, to compile our programs, and then have them linked with our own versions of 'putc', 'read', etc. stashed in stand-alone libraries. One of the (in my opinion) great strengths of the C language is that it does not have 'built-in' functions. As a result, it has somehow managed to avoid the imbroglio that Pascal has gotten into. If one user doesn't like the interface that 'printf' provides, or a whole bunch of users don't, they are free to write their own functions and use those instead. In addition, porting the C compiler to a different OS on the same machine only requires that the libraries be re-written (almost always). Building those functions into the language implies that there will be much code for special casing those functions. On the flip side, the language may not be as efficient. If the compiler writers want to allow these procedures to be built-in to allow in-line procedures, I think this should be an option (DEFAULT=OFF), and then the capabilities of the language will be compromised as little as possible. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0384 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:07 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 01:34:11 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015042; 1 May 86 20:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a004925; 1 May 86 19:57 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <778@bentley.UUCP> Date: 30 Apr 86 19:44:37 GMT To: info-c@BRL-SMOKE.ARPA In article <838@ihwpt.UUCP> ihwpt!knudsen writes: >(1) Found out this weekend that you can't say: > boolvar ||= boolean_expression An interesting expression. The left side of the assignment would have to be evaluated first, and if already set, do nothing. I presume the reason this is omitted is because it's normally written "if (v || e) v=1;" or "if (!v && e) v=1;" rather than "v = v || e". Btw, you can't have *all* operators extended with "=". How would you write "v = v < e;"? (Not that it's useful.) >(2) There isn't any ^^ (XOR) operator either, as in > if(divisor <0) ^^ (dividend <0) > quotient = -quotient; There is, but it's spelled "!=". (Presumably more efficient than "^", though I think either one should work with a smart compiler.) >(3) There is no boolean data type. No big gripe; >lots of us say "typedef short bool" in our .h files. I'd assume either "char" (for space) or "int" (for time). "short" probably gives you the worst of both worlds. However, a true boolean datatype would have a couple of advantages: o Multiple flag variables with local scope and no address operator (e.g. variables declared "register bool") could be packed into a single word. o "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--" would then be "test and (set|clear)". This would obviate such things as "if (!flag) { flag=1; printmsg(); }". Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4281 for JMS@ARIZMIS; Fri, 2-MAY-1986 09:07 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 09:19:50 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022045; 2 May 86 10:03 EDT Received: from USENET by SMOKE.BRL.ARPA id a005305; 2 May 86 9:42 EDT From: Landon Noll Newsgroups: net.lang.c Subject: Third International Obfuscated C Code Contest Rules Message-ID: <3529@nsc.UUCP> Date: 30 Apr 86 14:03:29 GMT Keywords: rules,1986,obfuscate,contest,oops To: info-c@BRL-SMOKE.ARPA GOAL: To write the most Obscure working C program following the rules below: RULES: 1) The source must be 1024 bytes or less. NO exceptions! 2) Include in your letter: a) Name (or anonymous), Company/School, City, State and Country. b) Your path from a major network site, if applicable. c) A brief statement of what the program should do. d) The Machine(s)/Operating system(s) on which it runs. e) Enclose your source between the following lines: ---start of program--- ---end of program--- 3) The entry should be written in common C. (K&R + common extensions) 4) The program must be of original work. All programs must be in the public domain. All copyrighted programs will be rejected. 5) Entries must be received between 31-Mar-86 and 30-May-86 0:00 GMT. Email your entries to: decwrl!nsc!obfuscate Entries sent by UUCP Email will be confirmed starting 1-May-86. People are encouraged to submit entries via Email, however one may mail entries the following address: International Obfuscated C Code Contest National Semiconductor Attn: Landon Noll Mail Stop: 7c266 1135 Kern Ave. Sunnyvale, CA 94086 U.S.A. AWARDS: Winners of each category and the best of Show will be posted to net.announce as well as being published in the May 86 issue of the "Micro/Systems Journal". Winners also get to receive international fame/flame for their efforts! JUDGING: Awards will be given to the best entry in a number of categories. The actual category list will vary depending on the types of entries we receive. At the moment, we are considering using the following: * The most obscure algorithm * The worst abuse of the C preprocessor * The strangest source layout * The best small one line program * The most useful program * Judging will be done by myself, Larry Bassel and other local people who are willing to help out. We will attempt to run each of them on a Vax 785/4.2BSD system. Don't let the lack of such a system stop you! Try to avoid operating system/machine specific code if you do not have such a system. Extra points will be given for programs which: a) pass lint without complaint b) do something quasi-interesting c) are portable A larger program size was selected to allow for a wider range of program ideas. However if you don't need 1024 bytes don't use them. Given two programs with similar techniques and similar levels of obfuscation, we will tend to favor the more concise entry. POLL: We want to know what you think is the most poorly coded utility released with 4.xBSD and/or Sys V. The top results plus the best flameage will be posted along with the contest results. To vote, please follow the guidelines below: 1) Include at the top of the letter: a) Name (or anonymous), Company/School, City, State and Country. b) Your path from a major network site, if applicable. c) the name of the poorly coded utility d) the name of the operating system on which it is found e) the line: <<>> f) up to 1024 bytes of flameage of the source g) the line: <<>> 2) Confine your vote to the standard set of commands. I.e., don't flame about local commands or user contributed software. 3) Submit your votes via Email to: for 4.xBSD: decwrl!nsc!bsd_util for Sys V: decwrl!nsc!sysV_util or, you may send your votes by letter to the same address used by the contest. Please place your votes on different sheets of paper. chongo /\cc/\ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8459 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:27 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 16:57:52 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002563; 2 May 86 16:59 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a017164; 2 May 86 16:48 EDT Date: Fri, 2 May 86 16:46:16 EDT From: Doug Gwyn (VLD/VMB) To: herndon%umn-cs.uucp@BRL.ARPA cc: info-c@BRL-SMOKE.ARPA Subject: Re: C Builtin Funxions X3J11 was not proposing to permit built-in functions in a stand-alone conforming C implementation. They would be permitted in a hosted implementation, however. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8107 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:28 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 13:23:39 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004876; 3 May 86 14:13 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a026443; 3 May 86 14:02 EDT Date: Sat, 3 May 86 13:52:52 EDT From: Doug Gwyn (VLD/VMB) To: Larry McVoy cc: info-c@BRL-SMOKE.ARPA Subject: Re: faster malloc anyone? Your new() function doesn't appear to do anything that the SVR2 malloc() doesn't, except fail to properly align storage. If the malloc() function in your C library has dismal performance, then fix it so that all programs can benefit. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7835 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:31 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 13:02:00 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004761; 3 May 86 13:57 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a025751; 3 May 86 13:20 EDT Date: Sat, 3 May 86 13:12:19 EDT From: Doug Gwyn (VLD/VMB) To: Root Boy Jim cc: gwyn@BRL.ARPA, rbj@ICST-CMR.ARPA, info-c@BRL-SMOKE.ARPA, warwick!kay@seismo.ARPA Subject: Re: questions from using lint Failure to examine the value returned by a function is probably an error; at the very least, a deliberate decision should be made to ignore it (which is the PROPER use of the (void) cast). This does not apply to assignments. "Lint" makes the proper distinction between these cases. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5872 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:44 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 09:47:00 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002615; 3 May 86 8:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a022623; 3 May 86 8:02 EDT From: Walter Bright Newsgroups: net.lang.c Subject: Re: A simple non-portable expression tha Message-ID: <972@dataioDataio.UUCP> Date: 28 Apr 86 17:23:26 GMT To: info-c@BRL-SMOKE.ARPA In article <2609@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >However, I tried this ( using 16-bit short ints for I1,I2 ) on our >native vax compiler and on our 68K compiler. Both produced identical code >for (L+I1)+I2 and L+(I1+I2) and L+I1+I2: specifically, ((long)I1+L)+(long)I2. >I guess the a+b+c is recognized as a special case, and all three are widened >to a common width regardless of the original associativityy Shorts in C are always converted to ints before they are used. On the vax and most 68k compilers, ints are the same as longs. Therefore, this isn't any 'special case' recognized by the compiler. Different code for (L+I1)+I2 and L+(I1+I2) will only be generated if ints are smaller than longs. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6201 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003511; 3 May 86 10:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a024259; 3 May 86 9:52 EDT From: Ray Butterworth Newsgroups: net.lang.c,net.lang.c++,net.arch Subject: Re: oops, corrupted memory again! Message-ID: <2393@watmath.UUCP> Date: 1 May 86 15:53:40 GMT Xref: seismo net.lang.c:8997 net.lang.c++:195 net.arch:3274 To: info-c@BRL-SMOKE.ARPA > You're probably better off with a language that compiles checks into > the code, and an option to turn off those checks once you're confident > (?!) of the program. With a capability-based architecture, you pay the > price all the time, whether you want to or not. Many years ago I worked with a language in which all arrays had to have dimensions that were a power of two (like 4.2 malloc). The code which indexed into the array simply anded the index with the appropriate bit mask. This was very fast, yet it guaranteed that any bad indexes wouldn't corrupt anything except the array being addressed. As a side-effect, one could use this feature to cycle continuously through an array or could even use negative indexes without any extra overhead. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6154 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:49 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003509; 3 May 86 10:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a024252; 3 May 86 9:52 EDT From: Eric Werme Newsgroups: net.lang.c Subject: Re: Who are Tartan Labs? Message-ID: <238@alliant.UUCP> Date: 1 May 86 05:11:24 GMT Keywords: C Reference Book To: info-c@BRL-SMOKE.ARPA In article <1415@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >I have seen bits and pieces of references to Tartan Labs. >Could somebody tell me what their product line is, etc. Apologies for not being super-specific, but Tartan Labs is a spinoff from Carnegie-Mellon University. The people include several compiler people who have much experience writing highly optimizing compilers (they designed and imlplemented BLISS). One is a C for VAXes. The reason I'm posting this is that they also produced a book entitled "The C Reference Manual" that is a wonderful compilation of information on C that any serious user or compiler writer should have next to K&R, especially if they are interested in portable code. The book covers all sorts of weird cases that you just can't answer from K&R. Available in better bookstores on the East and West coasts. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0664 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 20:33:52 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002761; 2 May 86 17:54 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a018008; 2 May 86 17:49 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA06467; Fri, 2 May 86 17:48:05 edt Date: Fri, 2 May 86 17:48:05 edt From: Root Boy Jim Message-Id: <8605022148.AA06467@icst-cmr.ARPA> To: bentley!kwh@ICST-CMR.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: void * > Actually, I don't think "void *" will start showing up in programs for > a while after it becomes "standard". Maybe someone will upgrade your > compiler in the meantime? > > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Don't bet on it. There are a *lot* of people just dying for ANSI C to hit the streets so they can sneer at people who don't have one :-) Hey, with computers you gotta take whatever status symbols you can get. (Root Boy) Jim Cottrell "One man gathers what another man spills" ~ P.S. I am in favor of ANSI C. Si si senor! See? Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8200 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:50 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002293; 2 May 86 16:23 EDT Received: from USENET by SMOKE.BRL.ARPA id a015899; 2 May 86 16:04 EDT From: Jan Steinman Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <7232@tekecs.UUCP> Date: 29 Apr 86 17:25:10 GMT Xref: brl-sem net.lang.c:858 net.lang.c++:167 To: info-c@BRL-SMOKE.ARPA In article <763@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Now, if only somebody would invent an architecture where all objects, >including dynamicly allocated objects, are isolated in memory, then any >subscript error would cause an immediate memory fault. You'd still be >vulnerable to completely wild pointers (but less likely in a huge address >space), and overflow of an array inside a structure might be untrappable, >but otherwise it sounds like a great machine to do your debugging on. > Sounds suspiciously like the Smalltalk virtual machine to me! :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 :::::: -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 :::::: Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6844 for JMS@ARIZMIS; Tue, 6-MAY-1986 12:53 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 11:10:48 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004151; 3 May 86 11:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a025182; 3 May 86 11:41 EDT From: Frank Adams Newsgroups: net.lang,net.lang.c Subject: Re: structured assembler (BASIC) [Really: C builtin functions?] Message-ID: <1354@mmintl.UUCP> Date: 30 Apr 86 23:19:36 GMT Xref: seismo net.lang:2483 net.lang.c:8999 To: info-c@BRL-SMOKE.ARPA In article <5341@alice.uUCp> ark@alice.UUCP writes: >The C definition of "function" is not the same as the mathematical >definition. A C function is a part of a program. A mathematical >function is a set of ordered pairs that meet certain conditions. > >That said, note that sizeof(i) is syntactically a constant. This >would not be true if sizeof were a function. Good grief! I am getting very tired of this. You can think of sizeof as a function if you want to, and you can think of it as not being a function if you want to. For some purposes (I haven't noticed any purpose in the discussion so far) one is more useful; for others, the other is. Now will everybody please SHUT UP about the subject? Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5916 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:02 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002732; 3 May 86 8:34 EDT Received: from USENET by SMOKE.BRL.ARPA id a023141; 3 May 86 8:21 EDT From: "Don E. Davis" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <219@aplvax.UUCP> Date: 2 May 86 16:22:36 GMT To: info-c@BRL-SMOKE.ARPA >You people fail to realize that some of us out here don't like lint. >It complains too much about what I do. I refuse to go any further >than generating no compiler warnings. I know what I'm doing. When I >goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > (Root Boy) Jim Cottrell (Root Boy) is not alone, though with a name like that he should be. ;-) I know several excellent programmers who never use lint. Personally, I use lint some, but it is not my religion. I do think programmers should be familiar with lint but I don't think we should run screaming into the sea because someone never heard of it. If they haven't heard of hack, now -- that's a different story! -- Don Davis JHU/APL ...decvax!harpo!seismo!umcp-cs!aplcen!aplvax!ded ...rlgvax!cvl!umcp-cs!aplcen!aplvax!ded Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8056 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 13:21:59 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004766; 3 May 86 13:59 EDT Received: from USENET by SMOKE.BRL.ARPA id a026090; 3 May 86 13:46 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: Array of pointers to functions Message-ID: <717@steinmetz.UUCP> Date: 1 May 86 21:04:36 GMT To: info-c@BRL-SMOKE.ARPA Another way to build unusual declarations is by repeated typedefs. The previous posting gave as an example "array of pointers to function returning integer", which is "int (*foo[])()". To build this up: typedef int fri(); /* function returning int */ typedef fri *pfri; /* prointer to function ret. int */ typedef pfri apfri[20]; /* array (size 20) of ... */ Then: apfri foo; /* declares the array */ -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4638 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:07 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 07:20:03 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002494; 3 May 86 8:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a022218; 3 May 86 7:47 EDT From: Steve Weil Newsgroups: net.unix-wizards,net.lang.c Subject: Need help with symbol table and relocation info in .o files Message-ID: <978@dataioDataio.UUCP> Date: 29 Apr 86 20:35:24 GMT Xref: seismo net.unix-wizards:18022 net.lang.c:8984 To: info-c@BRL-SMOKE.ARPA This is a sticky one. I am working on a large program with several sections supported by different people. It is too large to debug using DBX or CDB when the whole program is compiled with the -g option. I am trying to write a utility which will take a partial link (a .o file which is the result of ld -r) and will strip off the symbols which are there solely for the debugger, but which will leave the symbols needed for the final link. (This is to avoid recompiling everything without the -g flag.) I have written a program which will do this successfully for a plain .o file (from cc -c), but it does not work on partial links. When I load I get errors like "local symbol botch", or just core dumps. Apparently, there is some relocation information associated with some of the symbols I am removing. The manual pages and include files do not give me enough detail to understand what I need to do. Can anyone tell me a basic algorithm for keeping the relocation data consistent as I remove symbols? Specifically, does the r_address field in the relocation data correspond to the n_value field in the nlist structure? Any help of any sort would be greatly appreciated. Steve Weil entropy!dataio!weil Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6061 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:07 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003501; 3 May 86 10:02 EDT Received: from USENET by SMOKE.BRL.ARPA id a023979; 3 May 86 9:43 EDT From: Ben Cranston Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <942@umd5.UUCP> Date: 2 May 86 23:38:25 GMT To: info-c@BRL-SMOKE.ARPA In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: >In article <*> Root Boy Jim writes: >>You people fail to realize that some of us out here don't like lint. >>It complains too much about what I do. ... >I know several excellent programmers who never use lint. ... Hmm, I remember a certain Cobol compiler that had an 'E' option to generate error messages - because it generated such a quantity of informational diagnostics but its users wanted "clean compiles". I can see Cobol types complaining about this, but US? I'll be perfectly happy when I can understand what lint is saying to me, and convince myself that it is just being paranoid. Dare I suggest this: a filter for lint output that only lets the real bad errors through? Dare I suggest THIS: that it would be easier if every line from lint had an identification tag like this: BCD325I: Bad C construct at line 2543342 (No, No, anything but EBCDIC!) -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4604 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:10 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 07:18:28 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002483; 3 May 86 8:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a021942; 3 May 86 7:40 EDT From: Richard Harter Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <7595@cca.UUCP> Date: 30 Apr 86 06:54:20 GMT Keywords: Paranoia, malloc Xref: brl-sem net.lang.c:865 net.lang.c++:168 To: info-c@BRL-SMOKE.ARPA In article <> faustus@cad.UUCP (Wayne A. Christopher) writes: >In article <4495@cbrma.UUCP>, trl@cbrma.UUCP (Tom Lanning) writes: > >> Are there any "malloc" routines that check for modification of >> malloc's link pointers by the "user's" code? Close to 70% of by bugs >> are stack/memory problems were I use more space than I allocated. > >You could compile the 4.3 malloc() with the -DRCHECK flag, which checks >that you haven't modified the areas beyond your segment when you free it. >Also, if you're REALLY paranoid, write your own malloc that puts lots of >padding around the allocated areas and checks that none of the padding >areas has been changed every time you call malloc() or free(). > We wrote our own, partly out of paranoia an partly out of a probably misguided belief that we could write a more efficient allocator. The main thing that we did was to put all pointers and links in an entirely separate area from the space being allocated. This wins in that pointers never get overwritten -- it loses in that the program does not crash immediately on range errors. We added a one word pad on each end for overwrite testing (can be turned off) and legitimacy tests on all returns of space. We also put in a option to store where requests were coming from. (Hasn't been used in years.) The upshot is that space request/free problems are rare and easily found. However this doesn't avoid the problem of incorrectly dimensioned arrays which are handled by the system and can lead to very peculiar bugs. Richard Harter, SMDS Inc. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6108 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:13 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003507; 3 May 86 10:03 EDT Received: from USENET by SMOKE.BRL.ARPA id a024139; 3 May 86 9:48 EDT From: Ray Butterworth Newsgroups: net.lang.c Subject: Re: Lint Message-ID: <2376@watmath.UUCP> Date: 30 Apr 86 13:33:53 GMT To: info-c@BRL-SMOKE.ARPA > /* VARARGS */ and /*VARARGS0*/ both cause the first arg to be type-checked. > Another 'bug' is that /* VARARGS */ is used for all varargs functions in > llib-lc, where VARARGS1 should be used for printf, VARARGS2 for sprintf and > fprintf, etc. grumble, grumble. /*VARARGS*/ causes all the parameters in the function definition to be type-checked. This is nearly always what you want. The dummy definition for printf and fprintf in the lintlibrary file is something like: /*VARARGS*/ printf(fmt) char*fmt; {return 0;} /*VARARGS*/ fprintf(stream,fmt) FILE*stream; char*fmt; {return 0;} This causes LINT to compare the types of ALL the parameters with the supplied arguments. i.e. printf's first argument must be char*, and it can take any type of arguments after that. That /*VARARGS0*/ is treated the same as /*VARARGS*/ is in fact a bug in LINT (if there is a number, it is stored as its negative value in the 4.2 implementation, so -0 looks just like 0 which means that there wasn't any number given). One would almost never define a function with three parameters and tell lint to check only the type of the first one or two. There seems to be little point to ever doing such a thing. Unfortunately that is what LINT takes the # in /*VARARGS#*/ to mean. A much more useful meaning to the # would be to define the minimum number of arguments that the caller must supply. e.g. /*VARARGS1*/ func(n,a,b,c){return 0;} would check the types of all four parameters (if arguments were passed for them) and would complain if there wasn't at least one argument in the call. But as I said, this is NOT what LINT does. In fact one can call fprintf() with no arguments and get not a peep from LINT, regardless of whether fprintf() is defined with /*VARARGS*/ or /*VARARGS2*/ Anyway, I believe that under X3J11's version, there won't be any need for such a lint directive. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8309 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 13:47:21 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004900; 3 May 86 14:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a026097; 3 May 86 13:46 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: Re: structured assembler (BASIC) [R Message-ID: <718@steinmetz.UUCP> Date: 1 May 86 21:20:11 GMT To: info-c@BRL-SMOKE.ARPA In article <1700007@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I disagree. Sizeof is definitely NOT a function. It is a builtin >of the C language, but it is not and could not be written as a function >(well...), just as return is definitely not a function. Actually sizeof is a unary operator. It applies to the following object, when object is defined as: a variable name a variable type (including all struct and pointer types) the object of indirection of a pointer type Examples: int ka, kb[10], *kc; struct foo sa, *sb; All the same (part 1): sizeof int sizeof (int) sizeof ka sizeof (ka) sizeof *kc sizeof (*kc) (however, sizeof kb == 10*sizeof int) All the same (part 2): sizeof struct foo sizeof (struct foo) sizeof sa sizeof (sa) sizeof *sb sizeof (*sb) -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8268 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 13:46:15 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004898; 3 May 86 14:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a026044; 3 May 86 13:44 EDT From: "M.J.Shannon" Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <239@sfsup.UUCP> Date: 1 May 86 11:32:36 GMT To: info-c@BRL-SMOKE.ARPA In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I feel compelled to go on record as being VERY MUCH AGAINST >having reserved procedure names in C. For those of us who have >ever written stand-alone code for PDP-11s, VAXen, ..., it is >a simple matter, as things stand, to compile our programs, >and then have them linked with our own versions of 'putc', >'read', etc. stashed in stand-alone libraries. > ... >In addition, porting the C compiler to a different OS on the >same machine only requires that the libraries be re-written >(almost always). Building those functions into the language >implies that there will be much code for special casing those >functions. Nowhere is it required that the compiler have any special knowledge of the reserved names in the library. Yes, *some* compilers will undoubtedly have *some* special knowledge of *some* of those names, but the ANSI spec does *NOT* *require* the compiler to know anything about any reserved library names. Please, do NOT flame about statements that are not made in the spec. There are enough statements that ARE made in the spec that may be worth flaming about (although I hope that rational discusssion, rather than flames, result). If you don't have a copy of the current state of the proposed standard, GET ONE! I'm sure that any number of members of the committee (many of whom read this newsgroup) can either provide the proper procedure for obtaining it, and possibly an official copy. (I don't have this information, so please don't reply to me for it. Perhaps Larry Rosler can repost the appropriate information.) Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel -- Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7928 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:17 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 16:04:38 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a025536; 2 May 86 12:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a008701; 2 May 86 11:51 EDT From: John Owens Newsgroups: net.lang.c Subject: Re: goto jumps into loops Message-ID: <712@edison.UUCP> Date: 29 Apr 86 19:54:02 GMT To: info-c@BRL-SMOKE.ARPA In respose to the program by > Dave Harmon > dmh@mit-borax.arpa > dmh@borax.lcs.mit.edu where he asks for a way to avoid a goto in his loop (translated from Pascal). How about something like..... #include #include "/usr/dmh/nastydefs" #define MAX NUM_KEYWORDS /*The highest element in use by the application*/ wrtlist (listp) set *listp; { unsigned char i; set list; list = *listp; for (i=0; i <= MAX; i++) { if (in(i,&list)) { unsigned char save_i; printf(" %d",i); save_i = i; while (++i <= MAX && in(i,&list)) ; if (i > save_i + 1) printf("-%d",i-1); /* doesn't matter that we'll i++ here, since we know !in(i,&list) */ } } printf("\n"); return(0); } [No guarantees, but you get the idea.] John Owens edison!jso%virginia@CSNet-Relay.ARPA General Electric Company Phone: (804) 978-5726 Factory Automation Products Division Compuserve: 76317,2354 houxm!burl!icase!uvacs ...!{ decvax!mcnc!ncsu!uvacs }!edison!jso gatech!allegra!uvacs Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8970 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:22 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/06/86 at 14:36:13 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008994; 4 May 86 11:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a002792; 4 May 86 11:42 EDT From: Dan Gold Newsgroups: net.lang.c Subject: Re: Who are Tartan Labs? Message-ID: <312@ucdavis.UUCP> Date: 4 May 86 01:32:48 GMT To: info-c@BRL-SMOKE.ARPA > In article <1415@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: > >I have seen bits and pieces of references to Tartan Labs. > >Could somebody tell me what their product line is, etc. > > Apologies for not being super-specific, but Tartan Labs is a spinoff > from Carnegie-Mellon University. The people include several compiler > people who have much experience writing highly optimizing compilers > (they designed and imlplemented BLISS). One is a C for VAXes. > > The reason I'm posting this is that they also produced a book entitled > "The C Reference Manual" that is a wonderful compilation of information > on C that any serious user or compiler writer should have next to K&R, > especially if they are interested in portable code. The book covers > all sorts of weird cases that you just can't answer from K&R. Available > in better bookstores on the East and West coasts. Slight correction and more specifics on the book: Title: C: A REFERENCE MANUAL Authors: Samuel P. Harbison/Guy L. Steele Jr. of Tartan Laboratories Publisher: Prentice-Hall (Software Series) Cost: ~$20.00 The book offers a lot of useful information on the standard features of most C compiliers and points out potential pitfalls and improvements for portability. Dan Gold University of California, Davis UUCP: ...{ucbvax,lll-crg,lll-lcc,sdcsvax,dual}!ucdavis!minnie!ccrdan ARPA: ...ucdavis!minnie!ccrdan@ucbvax.BERKELEY.EDU Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8602 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:25 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/02/86 at 17:07:05 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002720; 2 May 86 17:32 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a017667; 2 May 86 17:27 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA06405; Fri, 2 May 86 17:26:28 edt Date: Fri, 2 May 86 17:26:28 edt From: Root Boy Jim Message-Id: <8605022126.AA06405@icst-cmr.ARPA> To: gwyn@BRL.ARPA, rbj@ICST-CMR.ARPA Subject: Re: questions from using lint Cc: info-c@BRL-SMOKE.ARPA, warwick!kay@seismo.ARPA Re: "lint" not being as smart as Root Boy Jim Gee, I hope not. After it's *only* a *program* (and I'm not? :-) That's really silly. I write C code such that I expect absolutely NO warnings from "lint" (except for malloc pointer type-cast, which is unavoidable at present); then if I get any "lint" warnings, they indicate BUGS that must be fixed. This is tremendously helpful. Not really. I will give you one good example of a technique that is NOT a bug, altho it may make you shudder somewhat. I have ranted about C using a one statement model for its control statements instead of an explicit end statement. Compound statements are bounded by braces instead. Yuk! Fortunately, there is the comma operator. This allows the following: Most People Your's Truly if (c) { if (c) w = y; w = x, y = z; y = z; } /* look ma, no brace */ Other things you will see in my code are: if (argc < 2) exit((printf("usage: foo bar\n"),1)); or even: exit(1,printf("usage: foo bar\n")); Sufficeth to say that I use a lot of commas in my code. Unfortunately, I cannot do this if either statement is a control struxure, *except* return. Most People Your's Truly if (c) { if (c) w = y; return w = x, return; } /* look ma, no brace */ When I want to return a *real* value, I use `return(exp)' using *explicit* parens. I only do this in void funxions of course. I cannot see *any* implementation doing either of the following: 1) barfing because I returned an *extra* value sometimes 2) barfing because I added an extra argument Now you may claim that this is `bad programming practice', but I claim that it is just a convention, just like #defines are usually capitalized. You may not like either one, but I claim this is portable. And, it is meaningful to me. I find that there are very few "inherently nonportable" applications. Even when an application is designed to use specific hardware, portable programming techniques contribute to better code quality. This is probably true. He who lives by the trick usually dies by it. On the other hand, I just tried to port the System V date to BSD, and it mumbled somthing about timezones not being defined. My point is that even the simplest things usually require *some* diddling. Lint-free coding comes naturally after a bit of practice. I find it no burden at all, and hardly have to think about it. Indeed, it helps organize my use of complicated data types so that I get the code right (and portable!) the first time. Yes, but it all depends on what you're willing to put up with. I find it terribly ugly having to cast printf's or close's to void. And as someone pointed out, assignments return a value too, so should we cast them to void as well? Oh yeah, assignment is `different'. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8251 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002296; 2 May 86 16:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a016232; 2 May 86 16:11 EDT From: Chuck Forsberg WA7KGX Newsgroups: net.micro,net.micro.pc,net.lang.c,net.unix-wizards Subject: Re: Help with C-kermit on SCO Xenix V Message-ID: <329@omen.UUCP> Date: 30 Apr 86 11:52:42 GMT Keywords: It isn't working Xref: brl-sem net.micro:619 net.micro.pc:950 net.lang.c:859 net.unix-wizards:1036 To: info-c@BRL-SMOKE.ARPA In article <294@catnip.UUCP> ben@catnip.UUCP (Bennett Broder) writes: >I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. >We have been using this version at work on a Perkin Elmer 3250XP and an >AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix. >Well the package compiles without error, and appears to work okay, until >you attempt to do a transfer. Then it can't even seem to get past the >header packet, and keeps printing SS%S%S%S%S% and the like on the screen. >Looking at the debugging output from both ends show that the Xenix machine >is computing the checksum incorrectly. Please, can anyone help??? > The Microsoft C compiler has a few problems with right shifts such as used in the Kermit CRC calculations. Here is something that should work better. (From Professional-YAM, the most powerful COMM program for the PC) /* C H K 1 -- Compute a type-1 Kermit 6-bit checksum. */ chk1(pkt) char *pkt; { register chk; chk = chk2(pkt); return((((chk & 0300) >> 6) + chk) & 077); } /* C H K 2 -- Compute the numeric sum of all the bytes in the packet. */ chk2(pkt) register char *pkt; { register chk; for (chk = 0; *pkt; ++pkt) chk += (kparity ? (*pkt & 0177) : (*pkt & 0377)); return chk; } /* C H K 3 -- Compute a type-3 Kermit block check. * * Calculate the 16-bit CRC of a null-terminated string using a byte-oriented * tableless algorithm invented by Andy Lowry (Columbia University). The * magic number 010201 is derived from the CRC-CCITT polynomial x^16+x^12+x^5+1. * Note - this function could be adapted for strings containing imbedded 0's * by including a length argument. */ chk3(s) char *s; { register unsigned int c, q; LONG crc = 0; while ((c = *s++) != '\0') { if (kparity) c &= 0177; else c &= 0377; q = (crc ^ c) & 017; /* Low-order nibble */ crc = (crc >> 4) ^ (q * 010201); q = (crc ^ (c >> 4)) & 017; /* High order nibble */ crc = (crc >> 4) ^ (q * 010201); } return(crc); } Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Author of Professional-YAM communications Tools for PCDOS and Unix Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen: omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6294 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:29 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 10:12:18 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003600; 3 May 86 10:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a024468; 3 May 86 10:00 EDT From: Larry McVoy Newsgroups: net.unix,net.unix-wizards,net.lang.c Subject: faster malloc anyone? Message-ID: <433@geowhiz.UUCP> Date: 2 May 86 22:54:25 GMT Xref: seismo net.unix:8148 net.unix-wizards:18032 net.lang.c:8998 To: info-c@BRL-SMOKE.ARPA [ munch. Does this bug still exist???? ] I was looking at the src for [cm]alloc() and came to the (hasty) conclusion that they take to long for little memory requests. It seems that they are leftover from the days of 256K unix systems where every byte counted. With workstations typically having gigabytes of vm and 2-4 megs of phys mem, it seems that we might sacrifice some memory for speed. In particular, if you want to save strings (5-80 bytes), it seems wasteful to do a lot of work for each call to strsav(). So, I wrote the following little chunks of code and am requesting comments. Can anyone point out why these are a *bad* idea (aside from the obvious upper bound problem)? Another problem is that free() won't work on these blocks... new.h: # define BLKSIZ 8096 char* new(); utils.c: /* utils.c -- strsav(), new() */ # include "new.h" char* strsav(s) register char* s; { char* strcpy(); register char* t; t = new(strlen(s) + 1); /* strings smaller than BLKSIZ */ return strcpy(t, s); } /*------------------------------------------------------------------02/May/86-* * new(size) - fast(??) memory allocator * * Inputs -> (int) * * Returns -> (char*) * * Results -> The memory is allocated in big contiguous blocks via calloc(3). * If the requst can fit in what's left of a block, then a block * of the size requested is returned. Otherwise, the rest of the * block is discarded & a new block is allocated. * * Warning -> This would seem to work great for little stuff. Don't use it * for big blocks. Absolute largest allocatable block is BLKSIZ. * For speed NO CHECK IS PERFORMED TO SEE IF THE REQUEST IS LESS * THAN BLKSIZ. BLKSIZ is guaranteed to be 1k or bigger (usually * much bigger). * Revisions: *----------------------------------------------------------------------larry-*/ char* new(size) register unsigned size; { register char* blk; static char* block = NULL; static unsigned bytes_left = 0; if (bytes_left < size) if (!(block = calloc(1, BLKSIZ))) syserr("calloc in new"); blk = block; block += size; bytes -= size; } -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry "Just remember, wherever you go -- there you are." -Buckaroo Banzai Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0281 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:31 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/05/86 at 17:37:35 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005335; 3 May 86 15:53 EDT Received: from USENET by SMOKE.BRL.ARPA id a027184; 3 May 86 15:41 EDT From: "J. Eric Roskos" Newsgroups: net.lang.c,net.lang.c++,net.arch Subject: Re: oops, corrupted memory again! Message-ID: <2129@peora.UUCP> Date: 2 May 86 13:09:37 GMT Xref: seismo net.lang.c:9008 net.lang.c++:196 net.arch:3278 To: info-c@BRL-SMOKE.ARPA > >Now, if only somebody would invent an architecture where all objects, > >including dynamicly allocated objects, are isolated in memory, then any > >subscript error would cause an immediate memory fault. > > If I'm not mistaken, this was done on the iAPX432, using a capability- > based addressing scheme. Dimmed the lights. You could probably construct > such an environment on the 80286, but no one does, probably for efficiency > reasons. One problem with the 432's approach was that it was very extreme; I don't think it's good to say "the 432 tried these approaches and it was too slow, therefore the checking can't be efficiently implemented." I posted some comments in here (net.arch) about a week ago on apparently the same subject, but nobody replied in net.arch to it (although I got a couple of replies by mail). Of the people who replied by mail, one (whose technical knowledge I have a high opinion of) pointed out that C compilers exist where subscript/pointer checking is done in software, and that thus it would seem likely that similar checking could be done in hardware. The way you could do it (which was a point the 2 people replying seemed to agree upon) was that, associated with all pointers, you should have a "minimum address" and "maximum address" for the object being pointed to. Bear in mind that in C array names are just constant pointers, so constructs like a[i] can use this method as well as plain pointer references such as *p. If p is a pointer of type t, then to use p you will have to first assign it a value by referencing an existing object, or by creating a new one: typedef t; t a[100]; t *p; p = a; (1) p = &a[40]; (2) p = (t *)malloc(300); (3) In case 1 and 2, you can easily set p.base to &a[0], and p.bound to &a[99], and set p.pointer to &a for (1) and to &a[40]. So p then carries around with it the range of valid addresses it can point to. (Note that nothing says anything about what a pointer in C has to look like, so p can easily be a 3-word struct-like object, and if you were building a new machine to support such things, you could make the machine have 3-word address registers). In case 3, you could have malloc set the base and bound -- though if malloc is written in C then you'd have to provide some way to reference the base and bound fields from within the language -- so things like malloc would also work. I had originally thought that some counterexamples existed, but one of the respondants (John Gilmore) pointed out that really the counterexamples involved essentially semantically inconsistent uses of the pointers (e.g., having 2 pointers around and changing the bounds on 1 of them). In any case, if you change p, e.g. p++, then you'd change what I called p.pointer above, and leave p.base and p.bound alone. If you generated an effective address which was outside [p.base .. p.bound], then you'd generate an addressing fault. I don't think this checking would be that slow, although on a machine with a narrow bus (especially those like the 8088 where you are already fetching pointers through multiple bus cycles) fetching the range attributes of the pointer would increase the bus time by a factor of 3. It would also reduce the number of register variables you could have, if you kept the bounds in registers also -- I think it would work best if you had a machine that had registers set aside specifically for pointer checking. On a machine such as the 3280*, which does quadword reads from memory because the data bus is very wide, the bus overhead would be much less. So the checking by this method would probably not be that bad (certainly not as bad as the 432, which I believe had to sometimes fetch several descriptor objects in order to validate references) at least on larger machines (and after all, microprocessors are getting larger all the time in terms of width of the bus, etc.). ----- *I cite this machine because I'm more familiar with it; I suspect probably other machines like Vaxes have similarly wide buses. -- E. Roskos Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5984 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:32 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002737; 3 May 86 8:35 EDT Received: from USENET by SMOKE.BRL.ARPA id a023255; 3 May 86 8:24 EDT From: Rex Ballard Newsgroups: net.lang.c,net.unix-wizards Subject: Stack vs register args. Re: varargs Message-ID: <395@ccird1.UUCP> Date: 2 May 86 18:09:01 GMT Xref: seismo net.lang.c:8991 net.unix-wizards:18027 To: info-c@BRL-SMOKE.ARPA In article <129@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: > >Microcomputers pass things in registers, rather than on the stack, because >stack operations are slow relative to register operations. This is also >typical of assembly language programming, rather than C language programming. >Not everybody is willing to pay the high-level language penalty. The reason I asked why people use registers rather than a vector (usually the stack) to pass arguments to the O.S. is because the typical High Level language interface "glue" is at least as costly as the low level version. Assuming that the typical "C call" is: push arg 1 push arg 2 . . call ; drop args ; add constant to sp For example, fd=open(fname,mode); calls open(fname,mode) /* just added the overhead of a frame call */ { fd=sys(OPEN,fname,mode); return(fd); } which calls the assembler routine sys: ; figure out how many arguments should be put into registers ; logic to do this (usually a case statement in assembler) ; has been deleted sysopn: mov 1(sp),r1 mov 2(sp),r2 mov 3(sp),r3 . . . trap ;result is in r0 the alternative would be fd=open(fname,mode); calls open(fname,mode); { fd=sys(OPEN,&fname); } calls assembler routine - sys: trap SYS ;arguments are already on the stack ;second argument is the vector pointing to the "real arguments" ;result is in r0. even more direct fd=open(fname,mode) calls assembler routine - open: ; just saved one level of "framing overhead" trap OPEN ; works exactly like this if there are enough ; trap vectors, otherwise would be a push/call macro ;result is in r0. ret in assembler, since fname and mode are usually constants somewhere, the "vector" could actually be static memory space. fname: db "file.name" mode: dw 2 openargs: dw fname dw mode The assembler routine could call "open" as follows. mov openargs,r0 push r0 trap OPEN One of the side benefits is that you have registers available to traverse the various transforms without corrupting the "frame". Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6941 for JMS@ARIZMIS; Tue, 6-MAY-1986 13:33 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/03/86 at 11:25:51 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004175; 3 May 86 11:59 EDT Received: from USENET by SMOKE.BRL.ARPA id a025227; 3 May 86 11:42 EDT From: Jim Williams Newsgroups: net.lang.c Subject: A good use of a bad feature Message-ID: <1298@umcp-cs.UUCP> Date: 3 May 86 04:26:28 GMT Keywords: case statement, tacky programs To: info-c@BRL-SMOKE.ARPA While discussing various features and miss-features of C with my friend Charley (mangoe) Wingate recently, we both agreed that the fall through case statement is among the least defensible of C's features. I submit the program below as the best use I have ever found for this feature. --------------- CUT HERE ------------ /* * xmas.c - a program to print The Twelve Days of Christmas * using the C fall thru case statement. * If this wasn't my idea, I appologize to whomever I * got the idea from, but I wrote the program 5 years * ago and I don't remember now. * * Jim Williams, jim@maryland, 2 May 1986 */ /* * If you have an ANSI compatible terminal then * #define ANSITTY. It makes the five Golden rings * especially tacky. */ #define ANSITTY #include char *day_name[] = { "", "first", "second", "third", "fourth", "fifth", "sixth", "seventh", "eighth", "ninth", "tenth", "eleventh", "twelfth" }; main() { int day; printf("The Twelve Days of Christmas.\n\n"); for (day=1; day<=12; day++) { printf("On the %s day of Christmas, my true love gave to me\n", day_name[day]); switch (day) { case 12: printf("\tTwelve drummers drumming,\n"); case 11: printf("\tEleven lords a leaping,\n"); case 10: printf("\tTen ladies dancing,\n"); case 9: printf("\tNine pipers piping,\n"); case 8: printf("\tEight maids a milking,\n"); case 7: printf("\tSeven swans a swimming,\n"); case 6: printf("\tSix geese a laying,\n"); case 5: #ifdef ANSITTY printf("\tFive [1;5;7mGolden[0m rings,\n"); #else printf("\tFive Golden rings,\n"); #endif case 4: printf("\tFour calling birds,\n"); case 3: printf("\tThree French hens,\n"); case 2: printf("\tTwo turtle doves, and\n"); case 1: printf("\tA partridge in a pear tree.\n\n"); } } } -- Jim \/\/illiams jim@mimsy.umd.edu umcp-cs!jim.UUCP Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2168 for JMS@ARIZMIS; Tue, 6-MAY-1986 18:22 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009080; 4 May 86 12:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a002810; 4 May 86 11:43 EDT From: George Robbins Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <183@cbmvax.cbmvax.cbm.UUCP> Date: 3 May 86 23:52:25 GMT To: info-c@BRL-SMOKE.ARPA In article <942@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: > >>In article <*> Root Boy Jim writes: >>>You people fail to realize that some of us out here don't like lint. >>>It complains too much about what I do. ... > >>I know several excellent programmers who never use lint. ... > >Hmm, I remember a certain Cobol compiler that had an 'E' option to generate >error messages - because it generated such a quantity of informational >diagnostics but its users wanted "clean compiles". I can see Cobol types >complaining about this, but US? > The whole lint/cc issue is probably one of those little misfeatures of unix that we just have to live with. Sure there are historical reasons, and nice efficiency arguments for keeping the two separate, but if lint was a default pass of the compiler that could be disabled, or diminished by a switch, then there would be a whole lot more people using lint, and generating more portable code than otherwise. One of the more traumatic things about being exposed to unix after working with numerous other systems was that the stupid c compiler refused to give me a nice clean listing with source, interspersed error messages, and optional object code. I'm not dumb, but trying to learn a debug a big program though a 24-line window and my memory just doesn't make it... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1990 for JMS@ARIZMIS; Tue, 6-MAY-1986 18:23 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/06/86 at 19:04:34 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008997; 4 May 86 11:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a002806; 4 May 86 11:42 EDT From: George Robbins Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <182@cbmvax.cbmvax.cbm.UUCP> Date: 3 May 86 23:18:37 GMT To: info-c@BRL-SMOKE.ARPA In article <498@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >X3J11 was not proposing to permit built-in functions in a >stand-alone conforming C implementation. They would be >permitted in a hosted implementation, however. Are you sure that the X3J11 committee hasn't been infiltrated by unsatiated ADA persons? :-) This business of including the runtime routines in the language standard brings out an awful log of worried frowns on the faces of knowledgeable c/unix people. Look at the problems that the Pascal and Modula2 people are having with their 'offical' runtime routines/libraries... To minimize this criticism, the committee seems to be making a big distinction between hosted and non-hosted environments that doesn't map well into the real world. Most of the people trying to develop compilers for non-unix microcomputer operating systems are trying to be as unix-like as possible, but just can't make all the way because of operating system brain damage. I would be much happier if there were two separate documents, so that a vendor could clearly say that his compiler is fully X3J11 conforming, and his runtime support conforms to XJXXX with the following exceptions. One of the better things to come out of the COBOL standards efforts was the notion of specifying a minimum core language, then defining optional modules that were pretty close to the way the big boys (IBM) had actually implemented their extensions. This makes it fairly easy for a vendor to communicate to a user just what his compiler supports. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2313 for JMS@ARIZMIS; Tue, 6-MAY-1986 18:24 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009083; 4 May 86 12:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a002889; 4 May 86 11:46 EDT From: "Gary M. Samuelson" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <633@bunkerb.UUCP> Date: 2 May 86 21:26:52 GMT To: info-c@BRL-SMOKE.ARPA In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes: >In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >>After three years of C programming I'm just starting to use lint, so >>please no negative reinforcement by flaming about how stupid my questions >>are, lest I give up on it entirely :-). >Mark, I'm not flaming you, but I *am* worried!... And well you should be. >People, what are *we* doing wrong when somebody can spend 3 years programming >in a particular language and only then start using one of the most important >development tools for it? Good question. I offer the following opinion: generally, even though most companies (and schools, for that matter) give lip service to "proper" development techniques, in reality they reward those who write sloppy, un-commented, ill-planned or un-planned code. Did you not read the discussion about the teaching of programming? Some, thank God, do pay some attention to issues such as style, but most still look only at the output. And many companies are worse than schools. Productivity is measured in lines of code -- which means that if you are actually trying to *design* before writing code, you aren't being productive. Some places don't require specifications; some do, supposedly, but any pile of paper with the word "specification" on the top sheet will apparently do. Fewer still understand the difference between a requirement (storing data) and design (let's use a hard disk). Some people -- in senior management positions, where they ought to know better -- actually believe that "we can't afford" to do things like impose coding standards, much less have design reviews or even code reviews. It is practically a proverb that "there's never time to do it right, but there's always time to do it over." Such short-sightedness -- the belief that having a program which does *anything* resembling what the user wants is better than waiting another week -- results in all sorts of trash being shipped Friday only to be junked Monday. Of course, part of the problem is that a lot of C programmers in particular learned C from the Unix (tm) source. I just picked 'rm.c', more or less at random, and found exactly one comment: all files following a null option are considered file names That's it. It isn't even obvious that 'rm.c' removes files (I suppose that one would eventually find that there is an 'unlink' call in there somewhere, and figure it out). >It's got to the point when if I'm doing program surgery and someone comes up >saying that their program "doesn't work", if they haven't brought a >line-numbered listing of the source AND a lint output, I don't really want >to start looking for the problems. > Kay. Good for you! That is the type of attitude required. In many cases, I would go even further and require that the line-numbered listing be part of a cross-reference. Also, when someone says, "This program doesn't work," it is often revealing to ask, "what's it supposed to do?" It is amazing -- and frustrating -- how often the person can give no clear answer. Gary Samuelson >"I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay At last! someone who appreciates my poetry! :-) Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7223 for JMS@ARIZMIS; Wed, 7-MAY-1986 02:25 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 04:18:53 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009088; 4 May 86 12:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a002997; 4 May 86 11:48 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: Re: Include the va_end! Message-ID: <5381@alice.uUCp> Date: 2 May 86 19:04:25 GMT To: info-c@BRL-SMOKE.ARPA > The implementation is on the Pyramid 90x machine, the System V > part of it (it runs both 4.2 and System V at the same time!), > where va_end is defined to be an '}'. That implementation is simply wrong. va_end is intended to be executed (to free memory possibly acquired by va_start). It is **not** intended to be a syntactic entity. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7355 for JMS@ARIZMIS; Wed, 7-MAY-1986 02:36 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009090; 4 May 86 12:12 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a002998; 4 May 86 11:48 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA09404; Sun, 4 May 86 11:48:04 edt Date: Sun, 4 May 86 11:48:04 edt From: "UNIX 4.2 BSD" Message-Id: <8605041548.AA09404@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, umcp-cs!jim@ICST-CMR.ARPA Subject: Re: A good use of a bad feature While discussing various features and miss-features of C with my friend Charley (mangoe) Wingate recently, we both agreed that the fall through case statement is among the least defensible of C's features. Jim \/\/illiams jim@mimsy.umd.edu umcp-cs!jim.UUCP You will find much disagreement on that point, I'm afraid. Fall thru is more flexible. You can always break, but often cases are related so that a particular case requires a superset of another case. It is to DMR's credit that he realized this feature. I sure wouldn't have thought of it. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7450 for JMS@ARIZMIS; Wed, 7-MAY-1986 02:42 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009092; 4 May 86 12:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a003037; 4 May 86 11:51 EDT From: Andrew Koenig Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <5388@alice.uUCp> Date: 2 May 86 21:14:00 GMT Xref: seismo net.lang.c:9020 net.unix-wizards:18048 To: info-c@BRL-SMOKE.ARPA I think people are confusing two different meanings for the same term: 1. the practice of writing programs that accept varying numbers of actual parameters by declaring a single formal parameter, taking its address, and incrementing that address in various devious ways. 2. the practice of writing programs that accept varying numbers of actual parameters and access them using ONLY the facilities provided by . The particular implementation of these facilities may differ from one machine to another. I said I don't know offhand of a machine that can't implement #2. I am being deluged by descriptions of machines that can't implement #1. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7512 for JMS@ARIZMIS; Wed, 7-MAY-1986 02:47 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009109; 4 May 86 12:26 EDT Received: from USENET by SMOKE.BRL.ARPA id a003082; 4 May 86 11:52 EDT From: Tom Stockfisch Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <210@sdchema.sdchem.UUCP> Date: 2 May 86 22:32:26 GMT To: info-c@BRL-SMOKE.ARPA In article <778@bentley.UUCP> kwh@bentley.UUCP writes: >In article <838@ihwpt.UUCP> ihwpt!knudsen writes: >>(2) There isn't any ^^ (XOR) operator either, as in > >There is, but it's spelled "!=". (Presumably more efficient than "^", though >I think either one should work with a smart compiler.) > Not quite the same. 3 ^^ 4 would evaluate as 0, 3 != 4 evaluates as 1. -- Tom Stockfisch, UCSD Chemistry Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7600 for JMS@ARIZMIS; Wed, 7-MAY-1986 02:57 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009111; 4 May 86 12:28 EDT Received: from USENET by SMOKE.BRL.ARPA id a003131; 4 May 86 11:55 EDT From: "R.B.Murray" Newsgroups: net.lang.c++,net.lang.c Subject: Re: System V preprocessor problem with Message-ID: <246@sfsup.UUCP> Date: 2 May 86 17:19:51 GMT Xref: seismo net.lang.c++:198 net.lang.c:9022 To: info-c@BRL-SMOKE.ARPA > In article <3597@sun.uucp> sun!guy (Guy Harris) writes: > >> #define name2(a,b) a/**/b > >It has, however, two problems: > > > > 1) If you run your code through "lint", it won't work > > I tried this example with "cpp -C" and it worked fine. I'd guess that > cpp strips all comments in preprocessor directives regardless of "-C". > > > 2) It is not a guaranteed property of the C language, but a > > quirk of the implementation, so it will not work in > > general. > > Agreed. Any application that depends on being able to do this is treading > on thin ice. > > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Agreed also. I also don't believe there is a standard and portable way to do this at the present time. However, the current draft of the ANSI C standard has an "offical" way to do this: #define name2(a,b) a##b The "##" is a (new) concatenation operator. Of course, this is only useful once a standard exists and everybody conforms to it. Also, ANSI may change their minds on the syntax of this feature. Rob Murray AT&T Summit, NJ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7670 for JMS@ARIZMIS; Wed, 7-MAY-1986 03:05 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009114; 4 May 86 12:28 EDT Received: from USENET by SMOKE.BRL.ARPA id a003198; 4 May 86 11:57 EDT From: Brad Templeton Newsgroups: net.micro,net.micro.pc,net.lang.c,net.unix-wizards Subject: Re: Help with C-kermit on SCO Xenix V Message-ID: <533@looking.UUCP> Date: 3 May 86 00:19:29 GMT Keywords: It isn't working Xref: seismo net.micro:15267 net.micro.pc:8583 net.lang.c:9024 net.unix-wizards:18049 To: info-c@BRL-SMOKE.ARPA In article <329@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >In article <294@catnip.UUCP> ben@catnip.UUCP (Bennett Broder) writes: >>I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. >>We have been using this version at work on a Perkin Elmer 3250XP and an >>AT&T 3B5, and so I wasn't expecting any problem bringing it up on Xenix. >>Well the package compiles without error, and appears to work okay, until >>you attempt to do a transfer. Then it can't even seem to get past the >>header packet, and keeps printing SS%S%S%S%S% and the like on the screen. >>Looking at the debugging output from both ends show that the Xenix machine >>is computing the checksum incorrectly. Please, can anyone help??? >> The problem is indeed a bug in the MSC compiler involving shifts of signed integers combined with ands. The fix for kermit is simple enough, make the int in CHK1 into an "unsigned int" We're lucky on this one. It turns out that the Kermit start packet just happens to have a checksum that triggers this bug. Even so it took me several hours to track it down. I'm going to report it to Microsoft as soon as I see it's not in the new Beta release I just got. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7889 for JMS@ARIZMIS; Wed, 7-MAY-1986 03:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009117; 4 May 86 12:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a003332; 4 May 86 12:03 EDT From: "Joseph S. D. Yao" Newsgroups: net.lang.c Subject: Re: A last word on arrays? Hah! Message-ID: <389@hadron.UUCP> Date: 3 May 86 14:44:46 GMT Keywords: array, reference, parameter, struct To: info-c@BRL-SMOKE.ARPA In article <310@dg_rtp.UUCP> throopw@dg_rtp.UUCP (Wayne Throop) writes: [attribution removed] >I do have comment on John Rose's proposals. ... >> (3) Interpret current C practice of converting array arguments >> to pointers as passing them by reference; make sizeof() >> work consistently. > >Well. Sizeof is indeed peculiar. For example, >sizeof(formal_array_name) yeilds your machine's pointer size. Ouch. First off (see that nit?), it took me two (admittedly fraction-of-a-second) passes to understand that you were talking about what sizeof yields [sp!] on an array declared as a formal a r g u m e n t . I spent at least half a sec wondering how you dressed your arrays to go formal! Second, though (if it's a nit, it's a MONSTER!), the reason it yields one of the pointer sizes of your machine is that there is no such thing, really, as an array argument. It's fairly clear that when you declare a formal argument to a function, the C compiler coerces it from array-of-X to pointer-to-X. You are therefore taking the size of a pointer, and it returns the size of that pointer (which size may depend on the type of the thing to which you are pointing). As usual, this has been discussed to death in earlier articles. If someone has a copy of my long-ish tutorial on this subject, please send it to me. I promise not to re-post it more often than every year or two, and flag it so you can junk it. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7951 for JMS@ARIZMIS; Wed, 7-MAY-1986 03:24 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009133; 4 May 86 12:30 EDT Received: from USENET by SMOKE.BRL.ARPA id a003336; 4 May 86 12:03 EDT From: "Joseph S. D. Yao" Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <390@hadron.UUCP> Date: 3 May 86 14:54:10 GMT To: info-c@BRL-SMOKE.ARPA In article <117@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >do ... while(1); >while(1) ... >for(;;) ... >are all widely-used idioms for unconditional looping in C. >I personally prefer the latter, but the choice is just a >matter of taste. Any reasonable compiler will generate >efficient code for all three constructs. Unfortunately, as I'm sure many readers of this group will agree, not all compilers are reasonable. The only one that consistently doesn't generate useless code is for (;;) {...}. BTW, given all these defines: here are some "cute" ones of mine: #define ever (;;) /* for ever ...; */ #define unless(x) if (!(x)) /* unless (x) ...; */ #define until(x) while (!(x)) /* until (x) ...; do ... until (x); */ and of course [ given #define OK 0 ] #define streq(a,b) (strcmp(a, b) == OK) #define strneq(a,b,n) (strncmp(a, b, n) == OK) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8012 for JMS@ARIZMIS; Wed, 7-MAY-1986 03:28 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 05:13:58 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009192; 4 May 86 12:31 EDT Received: from USENET by SMOKE.BRL.ARPA id a003340; 4 May 86 12:03 EDT From: "Joseph S. D. Yao" Newsgroups: net.lang.c Subject: Re: lint Message-ID: <391@hadron.UUCP> Date: 3 May 86 14:58:16 GMT To: info-c@BRL-SMOKE.ARPA In article <121@brl-smoke.ARPA> gwyn@brl.ARPA writes: >In article <119@brl-smoke.ARPA> art@ACC.ARPA writes: >> [attribution omitted] >>> There is really no justification for not using lint. >>Just remember that not all machines that have a C compiler also have lint. >>A full lint (or equivalent) implementation in the public domain would >>be very welcome. >Perhaps he should have said "There is really no justification >for doing C software development on a system other than UNIX"? For those poor sufferers who have to develop under other systems, there are many implementations of lint and make under MS-DOS: some were listed here a short time ago. I believe DEC has them under its VNX tools for VMS, too -- although if you are an all-DEC shop ... get Ultrix instead! Much better. "Better? Stronger ... faster ..." cheaper ... ($6M??) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8080 for JMS@ARIZMIS; Wed, 7-MAY-1986 03:36 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010067; 4 May 86 15:53 EDT Received: from USENET by SMOKE.BRL.ARPA id a004787; 4 May 86 15:40 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <203@brl-sem.ARPA> Date: 4 May 86 17:20:01 GMT To: info-c@BRL-SMOKE.ARPA In article <390@hadron.UUCP>, jsdy@hadron.UUCP (Joseph S. D. Yao) writes: > > Unfortunately, as I'm sure many readers of this group will agree, > not all compilers are reasonable. The only one that consistently > doesn't generate useless code is for (;;) {...}. Joe, it is exactly this second guessing of compilers that get people in trouble. It is bad to make sweeping statements as to what is more efficient because some compilers just do entirely unexpected, yet no more inefficient things with code generation. But the truth of the matter is, the PCC implementations get it right without any optimization whatsoever. Since most UNIX's use PCC as the base for their C compilers, that generally solves the problem. The original Ritchie compiler does miss it in the code generation, but the optimzer removes the silly test. Wait until the compiler comes out that does the following: for(;;) { included code ) L1: NOP / init L2: NOP / test INCLUDED CODE NOP / increment JUMP L2 Frankly, if your compiler is so bad that it can't perform routine constant elimination, than I doubt that you will really notice the extra performance loss. It's probably still multiplying out 60*60 for seconds in an hour and other definitions. -Ron Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9671 for JMS@ARIZMIS; Wed, 7-MAY-1986 06:08 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 07:43:34 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011221; 5 May 86 0:36 EDT Received: from USENET by SMOKE.BRL.ARPA id a006688; 4 May 86 23:50 EDT From: Doug Gwyn Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <530@brl-smoke.ARPA> Date: 5 May 86 03:50:17 GMT To: info-c@BRL-SMOKE.ARPA In article <182@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >To minimize this criticism, the committee seems to be making a >big distinction between hosted and non-hosted environments that >doesn't map well into the real world. Most of the people trying >to develop compilers for non-unix microcomputer operating systems >are trying to be as unix-like as possible, but just can't make >all the way because of operating system brain damage. Although based on a subset of the UNIX implementation, the X3J11 hosted C specification does not require support functions that cannot be implemented on almost any popular operating system. For example, I am sure that a conforming hosted implementation is possible on my Apple //e. There aren't many more primitive systems than that! >I would be much happier if there were two separate documents, so >that a vendor could clearly say that his compiler is fully X3J11 >conforming, and his runtime support conforms to XJXXX with the >following exceptions. "Exceptions" are pointless when the hosted runtime support is implementatble on essentially every system. All the library functions pertain to the hosted environment only. Only the "raw" C language is required in the stand-alone environment. It didn't take X3J11 long to agree that it was as important to standardize the hosted environment library functions as to standardize the raw language. I think that is essential; most C porting problems I've encountered have been library and header interface incompatibilities, not raw language problems. >One of the better things to come out of the COBOL standards efforts >was the notion of specifying a minimum core language, then defining >optional modules that were pretty close to the way the big boys (IBM) >had actually implemented their extensions. This makes it fairly >easy for a vendor to communicate to a user just what his compiler >supports. That is easier for a language with built-in I/O facilities. In the case of C, either an implementation is a conforming hosted ditto or it is a conforming stand-alone ditto (no library functions) or it is nonconforming. That's about the right number of levels as far as I am concerned. There's no need for more (although it would be nice to have standardized library additions for a variety of things; however, the X3J11 document describes the minimum useful language, not a superset of everybody's wish lists). Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9751 for JMS@ARIZMIS; Wed, 7-MAY-1986 06:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010335; 5 May 86 23:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a028529; 5 May 86 23:46 EDT From: Jim Carter Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <12329@ucla-cs.ARPA> Date: 2 May 86 23:20:39 GMT To: info-c@BRL-SMOKE.ARPA In article <778@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Btw, you can't have *all* operators extended with "=". How would you write >"v = v < e;"? (Not that it's useful.) I think it's useful! As written, of course, it's semantically invalid, but what you really mean is "v <= e" (sic) or, to demonstrate where it's really useful, array[horrendous] [subscript] [list] <= bigexpr; rather than if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; Now "<=" already means something else so this syntax is not acceptable. How about "v < = e" with a mandatory blank? This is atrocious human engineering but at least is parseable. Anybody have any better ideas? -- James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9801 for JMS@ARIZMIS; Wed, 7-MAY-1986 06:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018737; 5 May 86 10:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a012278; 5 May 86 9:51 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: C Builtin Functions Message-ID: <788@bentley.UUCP> Date: 4 May 86 22:20:14 GMT To: info-c@BRL-SMOKE.ARPA In article <1700010@umn-cs.UUCP> umn-cs!herndon writes: >I feel compelled to go on record as being VERY MUCH AGAINST having reserved >procedure names in C. For those of us who have ever written stand-alone >code for PDP-11s, VAXen, ..., it is a simple matter, as things stand, to >compile our programs, and then have them linked with our own versions of >'putc', 'read', etc. stashed in stand-alone libraries. Fine, if you replace *all* of libc. Otherwise you may find surprises (some of the stdio function behave as though they call each other, but have been optimized to use the system calls directly in some cases). >One of the (in my opinion) great strengths of the C language is that it >does not have 'built-in' functions. After rethinking this question, I've decided that it *does*. However, the builtins are all punctuation ("%"), whereas the library functions are all alphanumeric ("abs"). The only exception is "sizeof", which is something of a special case anyway. (Let's not quibble about "sizeof" again. And yes, I know "%" is an "operator", but doesn't that just mean "builtin function with builtin syntax"?) >If one user doesn't like the interface that 'printf' provides, or a whole >bunch of users don't, they are free to write their own functions and use >those instead. As has been mentioned before, if you're changing the semantics it's wise to change the name too. >Building those functions into the language implies that there will be much >code [within the compiler] for special casing those functions. But the standard doesn't *require* them to be special-cased; you could port the compiler by commenting out that code. >On the flip side, the language may not be as efficient. If the compiler >writers want to allow these procedures to be built-in to allow in-line >procedures, I think this should be an option (DEFAULT=OFF), and then the >capabilities of the language will be compromised as little as possible. If they make it an option, the default will probably be ON. Here's my opinion. Using punctuation for builtins (and alphanumerics for library functions) is a nice way to keep them straight; let's keep it that way. If certain functions are so trivial that it's worthwhile for them to be expanded inline (are there any besides abs(), min(), and max()?), then they should have non-alphanumeric spellings; i.e. they should be operators. I can feel the flames ("More operators? It's getting as bad as APL!"). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9861 for JMS@ARIZMIS; Wed, 7-MAY-1986 06:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011043; 6 May 86 4:02 EDT Received: from USENET by SMOKE.BRL.ARPA id a029545; 6 May 86 3:44 EDT From: Griff Smith Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <1250@ulysses.UUCP> Date: 5 May 86 21:14:16 GMT To: info-c@BRL-SMOKE.ARPA > In article <778@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: > >Btw, you can't have *all* operators extended with "=". How would you write > >"v = v < e;"? (Not that it's useful.) > I think it's useful! ... ... [ deleted usual arguments for "op-assign" operators ] > James F. Carter (213) 206-1306 > UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 > UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU I think the quality of suggestions is degenerating rapidly. This is a blatant type clash. The "op-assign" interpretation of " <= " is self-contradictory nonsense. The expression "v < e" has the (nonexistent) type "boolean", which implies that the destination is also boolean. But that implies that you are using a boolean variable in the " < " relation, which would be nonsense if "bool" were a real type. Instead of proposing yet another obfuscation of the language, why don't we discuss ways that we can simplify and improve the clarity of our coding style within the confines of the current language. Better yet; quit talking, and do something about it. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs ) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0026 for JMS@ARIZMIS; Wed, 7-MAY-1986 06:11 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018834; 5 May 86 10:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a012379; 5 May 86 9:54 EDT From: "M.F.C.F. Operators" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <2417@watmath.UUCP> Date: 3 May 86 20:22:08 GMT To: info-c@BRL-SMOKE.ARPA In article <453@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >Most of the code I have written was intrinsically non-portable. I *do* >appreciate portability as a spectrum concept, but not as a binary one. Good point. There seems to be a lot of people confusing "portability" and "machine-independance". Some years ago Malcolm and Rogers defined a measure they called the "portability index" of a program cost to modify the existing code for new environment index = ----------------------------------------------------- Cost to recode from scratch an equivalent program Where "cost" is appropriate function for your environment time, money etc. A machine independant program would have a portabily index of 0. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0088 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:38 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011047; 6 May 86 4:03 EDT Received: from USENET by SMOKE.BRL.ARPA id a029649; 6 May 86 3:47 EDT From: Brandon Allbery Newsgroups: net.micro,net.micro.pc,net.lang.c,net.unix-wizards Subject: C-Kermit: more problems (same version) Message-ID: <1171@ncoast.UUCP> Date: 4 May 86 15:10:30 GMT Followup-To: net.micro,net.micro.pc,net.lang.c Xref: seismo net.micro:15284 net.micro.pc:8606 net.lang.c:9056 net.unix-wizards:18066 To: info-c@BRL-SMOKE.ARPA Expires: Quoted from <329@omen.UUCP> ["Re: Help with C-kermit on SCO Xenix V"], by caf@omen.UUCP (Chuck Forsberg WA7KGX)... +--------------- | In article <294@catnip.UUCP> ben@catnip.UUCP (Bennett Broder) writes: | >I recent obtained a copy of C-kermit 4.2(030) PRERELEASE #2, 5 March 85. +--------------- We have the same version. The problem: On some binary files, uploading from a PC running MS-Kermit 2.27, a binary file will run into problems early on (sometimes packet 3, sometimes packet 5, sometimes others, but always early). The local (PC) Kermit times out with ``?Unable to receive acknowledge from host''; but the host is in fact sending acknowledge packets. I once ran debug on the C-Kermit and didn't see anything unuaual (then again, I am not a Kermit guru...). I don't know of any tests with other than MS-Kermit 2.27, so it's conceivable that the problem is on the PC end (but it works over long-distance lines to BBSes supporting Kermit). I will provide a debug output if it'll help. --Brandon -- decvax!cwruecmp!ncoast!allbery ncoast!allbery@Case.CSNET ncoast!tdi2!brandon (ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101 Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time) PC UNIX/UNIX PC - which do you like best? See <1129@ncoast.UUCP> in net.unix. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0191 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:38 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a019558; 5 May 86 10:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a012645; 5 May 86 10:01 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <1399@mmintl.UUCP> Date: 3 May 86 12:01:06 GMT To: info-c@BRL-SMOKE.ARPA In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > On the flip side, the language may not be as efficient. >If the compiler writers want to allow these procedures to >be built-in to allow in-line procedures, I think this should >be an option (DEFAULT=OFF), and then the capabilities of >the language will be compromised as little as possible. I agree that if one is going to consider certain functions as built-in, there should be an option to make them external calls, instead. I don't agree that the default should be to make them external. Most users are interested in the efficiency; the additional effort, however much it is, should be put on the smaller group. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0286 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:38 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011125; 6 May 86 4:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a029746; 6 May 86 3:52 EDT From: Don Libes Newsgroups: net.lang.c Subject: Re: multitasking in one process (4.2BSD) Message-ID: <281@nbs-amrf.UUCP> Date: 6 May 86 05:16:39 GMT To: info-c@BRL-SMOKE.ARPA > For efficiency, my only choice was to get the whole mess to run as > one UNIX process. The result is an operating system in a process. > ... > It's certainly free. Let me know if anyone is interested. If > there are enough requests, I might even document it and send it to > mod.sources. Ok, enough. I've gotten two dozen requests for this. I now feel very motivated to document this as promised and will do so over the next few weeks. I've also convinced my other half (Ed Barkmeyer) to write up a description of the standalone 68k OS that this was based on. (He wrote it from scratch. It's also free.) Don Libes {seismo,umcp-cs}!nbs-amrf!libes Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0335 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:38 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020103; 5 May 86 10:39 EDT Received: from USENET by SMOKE.BRL.ARPA id a012092; 5 May 86 9:48 EDT From: Barry Margolin Newsgroups: net.lang.c Subject: Re: A good use of a bad feature Message-ID: <1853@mit-eddie.MIT.EDU> Date: 4 May 86 06:48:32 GMT Keywords: case statement, tacky programs To: info-c@BRL-SMOKE.ARPA In article <1298@umcp-cs.UUCP> jim@umcp-cs.UUCP (Jim Williams) writes: >... the fall through case statement is among the least >defensible of C's features. The only defense I can think of it is that it is more easily transformed into the non-fall-thru version than the other way around. All you have to do is add lots of "break" statements. If you want the effect of the fall-thru style in a language that only executes one case, you must either duplicate code or use lots of gotos in many cases. Note that this would not be so for your "12 Days of Christmas" program, because it could easily be implemented as a for loop that invoked each appropriate case in turn. But in the cases where the alternatives are not indexed so nicely it would not work. However, I agree with you that it is not really a necesary feature. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9709 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011243; 5 May 86 0:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a006822; 5 May 86 0:46 EDT From: Doug Gwyn Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <531@brl-smoke.ARPA> Date: 5 May 86 04:46:38 GMT To: info-c@BRL-SMOKE.ARPA Barry, the point is, if you have a decent version of "lint", then ANYthing it warns you about really could be an error. It is not always obvious to the non-expert what the problem could be, but I haven't seen more than a few actual errors made by our SVR2+ "lint". Therefore, if you really do want your code to port without hassle, you should pay attention to what "lint" tells you about your code. Furthermore, for this approach to be maximally helpful, you want to reduce the not-really-a-problem messages so that real problems do not get buried among the non-problems. The main category of "lint" messages that do not indicate bugs or possible portability problems is the detection of unused variables, functions, parameters, and function values. Most of these are probable errors in the code. The one that seems to bother people most is the flagging of unused function values. The naive idea that one then sticks "(void)" in front of all such function invocations "just to shut lint up" indicates a misunderstanding of what lint is all about. If one's own functions do not return values, they should be declared of type void. If a function's value is sometimes important and sometimes not (good examples of this are fairly rare), then one should explicitly indicate discarding of the value, which is the proper use of (void). This shows whoever reads the code that the matter has been thought about and indeed the value is not needed in that invocation (it also forces you to think about the matter when you write the code). The final instance involves standard library functions; I claim that robust code really must check the majority of function returns (strcpy() is a notorious exception, since it doesn't tell one anything useful). I just finished writing an MDQS despooling slave both with and without using stdio for device output; in order to detect problems with the output device and perform appropriate error recovery, it was essential to test the return values from putchar(), fflush(), and other such functions that most programmers do not test. The fact that "lint" encourages one to program responsibly is good! If you follow my recommendation and try to make your code lint-free in the first place, then ANY noise from "lint" will necessarily call your attention to a bug. This is extremely helpful, but it only works well if the expectation is that there will be no "lint" output for correct code. Now, if you want to just "hack around", then "lint" is not for you; but if you're producing production-quality C code, there is no excuse for delivering unduly linty code. In answer to your question, yes, I think one has a right to expect C source code deliverables (pretty rare these days) to be lint-free. Every time we get code that hasn't been done that carefully, it doesn't work right and a lot of time has to be spent fixing it. This should be the vendor's responsibility, not the customer's; but a vendor that ships code like that probably won't be able to fix it properly either. P.S. Unless your malloc() has type (void *), "lint" warnings about incompatible pointer conversion will be unavoidable, since "lint" doesn't realize that malloc() arranges its (char *) return value to be maximally aligned. This is one of the few "lint" warnings that correct code should produce, and it is easy to spot. But beware the yo-yo who fails to declare the malloc() function, invokes it (as a default int-valued function), and casts the result to (char *); that's incorrect usage. P.P.S. Don't look to the UNIX sources for good examples of lint-free code; some of them are good, but most are horrible. P.P.P.S. I agree with the fellow who identified the major problem as poor programming management. C code quality is only a small part of overall software quality. All too often, one sees programmers writing code before a proper job of analysis and design has been done. I also believe that is partly because semi-running code makes it appear as though progress has been made, while a complete design doesn't convey the same impression. The only solution is to educate the management involved. There are many good books (mostly from Yourdon, Inc.) that can be used to help with this; my experience has been that such educational efforts are only partially successful, but that partially correct organization of the software development process is better than none. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0521 for JMS@ARIZMIS; Wed, 7-MAY-1986 07:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020270; 5 May 86 10:43 EDT Received: from USENET by SMOKE.BRL.ARPA id a012819; 5 May 86 10:07 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <1305@umcp-cs.UUCP> Date: 5 May 86 04:37:55 GMT To: info-c@BRL-SMOKE.ARPA In article <210@sdchema.sdchem.UUCP> tps@sdchema.UUCP (Tom Stockfisch) writes: [in reference to the `missing' ^^---boolean exclusive or---operator, and kwh@bentley.UUCP's suggestion, `!='] >Not quite the same. > 3 ^^ 4 >would evaluate as 0, > 3 != 4 >evaluates as 1. If the left and right hand sides are both already boolean, `!=' works; but the following macro always works: /* logical exclusive or */ #define lxor(a, b) (((a) != 0) != ((b) != 0)) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2035 for JMS@ARIZMIS; Wed, 7-MAY-1986 08:57 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 10:41:58 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020289; 5 May 86 10:44 EDT Received: from USENET by SMOKE.BRL.ARPA id a012836; 5 May 86 10:07 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: using lint on `commercial' code Message-ID: <1308@umcp-cs.UUCP> Date: 5 May 86 04:51:18 GMT To: info-c@BRL-SMOKE.ARPA In article <531@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes: >A more interesting idea: Would it be reasonable to run a vendor's >code you just bought through LINT and call their warranty dept if >there was any serious bitching by lint? The answer to that depends on the purpose for which the software was sold (and bought). In practice I suspect this would be entirely unproductive: You would spend all your time on the phone, and never have a chance to use the software. . . . Anecdote: We had some Imagen software that was working on a Vax. We moved the software to a Pyramid and it broke. I ran lint on the program in question. Among the several hundred lines of other errors, it pointed out the one that was causing the failure: struct foo { int i; } foo[128]; caller() { ... callee(foo[n]); ... } callee(i) int i; { /* do something with i */ } This works on most machines; since the structure contains no `holes', one member of that structure is the same size as one integer, and the two can be treated as equivalent. But the Pyramid has a register window architecture, and passes `simple' arguments in registers, reserving the data stack for `complex' arguments---such as (drum roll please) structures. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2177 for JMS@ARIZMIS; Wed, 7-MAY-1986 09:05 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020528; 5 May 86 10:49 EDT Received: from USENET by SMOKE.BRL.ARPA id a013016; 5 May 86 10:11 EDT From: "Robert L. Fair" Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Microsoft 'C' - Strange behaviour with doubles Message-ID: <200@pyuxv.UUCP> Date: 4 May 86 00:39:51 GMT Xref: brl-sem net.lang.c:918 net.micro.pc:987 net.unix:619 To: info-c@BRL-SMOKE.ARPA Consider an array of 15 pointers to arrays of doubles: double (*parray[15])[]; The following code to 'malloc' the actual double array barfs on Microsoft 'C', with a 'different levels of indirection' warning on the '='. The code passes through LINT, and compiles OK on UN*X 5.2 char *malloc(); parray[0] = (double*)malloc((unsigned)sizeof(double)*75); Microsoft produces the same error if the coercion is (double**), (double), or nothing at all ! Any ideas ? Rob. Fair {ihnp4|gamma|bambi}!pyuxv!cim2 Bell Communications Research Piscataway New Jersey Subject: Newsgroups: general Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2444 for JMS@ARIZMIS; Wed, 7-MAY-1986 09:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009579; 5 May 86 19:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a026487; 5 May 86 19:42 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <791@bentley.UUCP> Date: 5 May 86 13:37:54 GMT To: info-c@BRL-SMOKE.ARPA In article <778@bentley.UUCP> I wrote: >A true boolean datatype would have a couple of advantages: > >o Multiple flag variables with local scope and no address operator (e.g. > variables declared "register bool") could be packed into a single word. > >o "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--" > would then be "test and (set|clear)". This would obviate such things as > "if (!flag) { flag=1; printmsg(); }". I forgot to mention one other: o A function returning a bool could be implemented on some machines by setting the condition codes instead of storing a full integer value in the return register. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4824 for JMS@ARIZMIS; Wed, 7-MAY-1986 14:05 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 15:22:01 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020556; 5 May 86 10:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a013031; 5 May 86 10:11 EDT From: Griff Smith Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <1247@ulysses.UUCP> Date: 4 May 86 15:29:56 GMT To: info-c@BRL-SMOKE.ARPA > Most People Your's Truly > > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ ... > Sufficeth to say that I use a lot of commas in my code. Unfortunately, > I cannot do this if either statement is a control struxure, *except* return. > > Most People Your's Truly > > if (c) { if (c) > w = y; return w = x, > return; > } /* look ma, no brace */ > > When I want to return a *real* value, I use `return(exp)' using *explicit* > parens. I only do this in void funxions of course. I cannot see *any* > implementation doing either of the following: > > 1) barfing because I returned an *extra* value sometimes > 2) barfing because I added an extra argument > > Now you may claim that this is `bad programming practice', but I claim > that it is just a convention, ... ... > (Root Boy) Jim Cottrell "Thank you, Mr Cottrell. It is refreshing when job applicants are so candid during an interview; we will notify you of our decision in a few weeks..." -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs ) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5848 for JMS@ARIZMIS; Wed, 7-MAY-1986 16:28 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/07/86 at 17:28:21 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009598; 5 May 86 19:59 EDT Received: from USENET by SMOKE.BRL.ARPA id a026546; 5 May 86 19:44 EDT From: Dave Bloom Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <278@andromeda.RUTGERS.EDU> Date: 5 May 86 14:54:34 GMT To: info-c@BRL-SMOKE.ARPA >> People, what are *we* doing wrong when somebody can spend 3 years programming >> in a particular language and only then start using one of the most important >> development tools for it? > Good question. I offer the following opinion: generally, even though > most companies (and schools, for that matter) give lip service to > "proper" development techniques, in reality they reward those who > write sloppy, un-commented, ill-planned or un-planned code. Just because you don't always use lint, doesn't mean your code is sloppy or ill planned. Very often programs do *NOT* have to be portable... In fact, sometimes code is easier to read if you haven't gone out of your way to be portable. Further more, the Lint S/N ration is frustrating, to say the least. And many of us don't believe in muddling up code with void casts and the like to keep lint happy.... -- harvard\ pyramid\ Dave Bloom seismo \ pyrnj \ ut-sally >!topaz >!andromeda!dave Office: (201) 648-5083 allegra / caip / ihnp4!packard/ yogi/ "You're never alone with a schizophrenic...." Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5949 for JMS@ARIZMIS; Wed, 7-MAY-1986 16:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009756; 5 May 86 20:32 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a026946; 5 May 86 20:25 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA09939; Mon, 5 May 86 20:24:55 edt Date: Mon, 5 May 86 20:24:55 edt From: Root Boy Jim Message-Id: <8605060024.AA09939@icst-cmr.ARPA> To: cbmvax!grr@seismo.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint > In article <942@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: > >In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: > > > >>In article <*> Root Boy Jim writes: > >>>You people fail to realize that some of us out here don't like lint. > >>>It complains too much about what I do. ... > > > >>I know several excellent programmers who never use lint. ... > > > >Hmm, I remember a certain Cobol compiler that had an 'E' option to generate > >error messages - because it generated such a quantity of informational > >diagnostics but its users wanted "clean compiles". I can see Cobol types > >complaining about this, but US? > > > > The whole lint/cc issue is probably one of those little misfeatures of unix > that we just have to live with. Sure there are historical reasons, and nice > efficiency arguments for keeping the two separate, but if lint was a default > pass of the compiler that could be disabled, or diminished by a switch, then > there would be a whole lot more people using lint, and generating more > portable code than otherwise. > > One of the more traumatic things about being exposed to unix after working > with numerous other systems was that the stupid c compiler refused to give me > a nice clean listing with source, interspersed error messages, and optional > object code. I'm not dumb, but trying to learn a debug a big program though > a 24-line window and my memory just doesn't make it... > > -- > George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr > but no way officially representing arpa: cbmvax!grr@seismo.css.GOV > Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) BSD has a program called `error' that will insert the errors & then invoke `vi' on all the sources. EMACS will do that as well. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0473 for JMS@ARIZMIS; Thu, 8-MAY-1986 00:58 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 02:37:19 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010088; 5 May 86 22:02 EDT Received: from USENET by SMOKE.BRL.ARPA id a027639; 5 May 86 21:43 EDT From: Chris Torek Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Re: Microsoft 'C' - Strange behaviour with doubles Message-ID: <1314@umcp-cs.UUCP> Date: 5 May 86 15:10:22 GMT Xref: seismo net.lang.c:9046 net.micro.pc:8604 net.unix:8174 To: info-c@BRL-SMOKE.ARPA In article <200@pyuxv.UUCP> cim2@pyuxv.UUCP (Robert L. Fair) writes: [concerning Microsoft C's warning on the assignment below] > double (*parray[15])[]; > char *malloc(); > > parray[0] = (double*)malloc((unsigned)sizeof(double)*75); `parray' here is `array 15 of pointer to array of double'. Indirection (parray[0]) yields `pointer to array of double'; so the proper cast is parray[0] = (double (*)[]) malloc(...); but as cdecl says, Warning: Unsupported in C -- Pointer to array of unspecified dimension Most likely your intent here is to create a fifteen element vector of vectors, where the subsidiary vectors contain an unspecified number of objects of type `double'. (I am trying to avoid the words `array' and `pointer', if it is not obvious.) To accomplish this, try the following: double *vecvec[15]; vecvec[0] = (double *) malloc((unsigned) (j * sizeof (double))); You can then reference vecvec[0][0 .. j-1] (if you will pardon the Pascalesque notation), or *(vecvec[0]) through *(vecvec[0] + j - 1), if you prefer. More generally, given int i; /* loop index */ int *j; /* bounds on each vec[i] */ int n; /* bound on vec[] */ double **vecvec; /* vector of vectors of doubles */ /* create a vector of n objects of type t */ #define MAKEVEC(n, t) ((t *) malloc((unsigned) ((n) * sizeof (t)))) n = ...; j = MAKEVEC(n, int); for (i = 0; i < n; i++) j[i] = ...; vecvec = MAKEVEC(n, double *); for (i = 0; i < n; i++) vecvec[i] = MAKEVEC(j[i], double); you can then reference vecvec[i][0 .. j[i] - 1] for i in [0, n). Of course, all of the above needs to ensure that malloc() succeeds; if you leave out such tests, your program will work perfectly until the first time you demonstrate it to someone important, at which time it will bomb spectacularly. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1043 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 04:13:40 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010092; 5 May 86 22:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a027667; 5 May 86 21:44 EDT From: Brooks Gelfand Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <256@valid.UUCP> Date: 5 May 86 19:43:15 GMT To: info-c@BRL-SMOKE.ARPA > In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: > >After three years of C programming I'm just starting to use lint, so > >please no negative reinforcement by flaming about how stupid my questions > >are, lest I give up on it entirely :-). > > Mark, I'm not flaming you, but I *am* worried! If you've been programming > in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* > lint. You have my profound sympathy. OR 2) Nobody ever taught you about > using lint. I wonder why not? OR 3) You never realised that using lint > was important. You must have wasted many hours (that you could have spent > playing Rogue or whatever :-)) chasing problems down that lint might well > have indicated to you. > > People, what are *we* doing wrong when somebody can spend 3 years programming > in a particular language and only then start using one of the most important > development tools for it? > > Kay. > -- > "I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay I have been programming for many years (over 20) in many different languages, and C is the only language that I can remember that has a separate program (lint) to find and report compiler errors in source code. All of the other languages I have used have this function built into the compiler. Perhaps because UNIX is a programmers system rather than a production system this was felt to be unnecessary. In most production systems the programs spend more time executing than compiling; while in a development system most of the time is spent editing and compiling. Thus running lint each time would add to the load on the system. A suggestion, system adminstrators could replace the cc command with a script that would invoke lint before the C compiler. Then everyone would run lint and perhaps development time spent tracking down bugs would decrease. Brooks Gelfand Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1097 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010327; 5 May 86 23:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a028392; 5 May 86 23:41 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <2692@utcsri.UUCP> Date: 3 May 86 16:39:13 GMT To: info-c@BRL-SMOKE.ARPA In article <778@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <838@ihwpt.UUCP> ihwpt!knudsen writes: >>(1) Found out this weekend that you can't say: >> boolvar ||= boolean_expression > >An interesting expression. The left side of the assignment would have to be >evaluated first, and if already set, do nothing. I presume the reason this is >omitted is because it's normally written "if (v || e) v=1;" or "if (!v && e) >v=1;" rather than "v = v || e". > Interesting - I was going to suggest if(e)v=1; but that's not the same thing. I was surprised to find out recently that ` i >> = 1 ' is legal, as opposed to `>>='. I really think this should produce at least a warning. (4.2BSD) > >>(2) There isn't any ^^ (XOR) operator either, as in >> if(divisor <0) ^^ (dividend <0) >> quotient = -quotient; > >There is, but it's spelled "!=". (Presumably more efficient than "^", though >I think either one should work with a smart compiler.) If I had $0.02 for everything that people have said should be done by a smart compiler... :-) :-) I know, that's what compilers are for. But it's not quite the same thing. 2 ^^ 1 should be 0, and 2!=1 is 1, and 2^1 is 3. Of course, in the example given, that won't happen. In any case, you can always say !a != !b. On the subject of operators, someone said a while back that they had a compiler with commented-out code to support '/\' and '\/' ( max and min ) operators - and that they had qualms about activating it and then writing non-portable code. I suggest that they activate it, and then write #define min(a,b) ((a)\/(b)) #define max(a,b) ((a)/\(b)) in a header, to allow portability. Presumably, the code produced by these operators should be somewhat better than a>b?a:b. Of course, you still have to avoid writing min( array[atoi(x1)], i+cindex[getc(file)]) :-). -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1147 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010330; 5 May 86 23:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a028414; 5 May 86 23:42 EDT From: Gregory Smith Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <2694@utcsri.UUCP> Date: 3 May 86 17:01:05 GMT Xref: seismo net.lang.c:9051 net.unix-wizards:18063 To: info-c@BRL-SMOKE.ARPA In article <236@chronon.chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >In article <129@drilex.UUCP> dricej@drilex.UUCP writes: >> >>rb@ccird2 (Rex Ballard) wonders what kind of systems would not be able to >>handle varargs. ... >>... Therefore, a more proper question would be: is there any >>architecture which is suitable for a C compiler, but not for varargs? > >Yes! I can think of an example close to home... An architecture with >a large (LARGE) number of registers, a sliding window to allow reference >to a smaller register set locally within a procedure, and OS support >for using the register set as a stack (handling overflow/underflow). >The first arguments are passed in registers via the overlapped >sliding window, remaining have to be passed in memory. The problem >is that no choice of will be correct; you can only make arbitrarily >small the probability of it not being big enough... and at the cost of >additional expense elsewhere... >I assert that this architecture, and the rest of what goes with this >particular feature, is particularly well-suited for efficient execution >of programs written in C. > I agree with your assertion. If this machine supports pointers to registers, you could write a varargs. va_arg() would have to bump a pointer to the last register arg to a pointer to memory, maybe by calling a 'va_bump' function. If it doesn't support pointers to register args, then it is in a bit of trouble with C because this is supposed to be legal: f(a) int a; { wombat(&a); } -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1188 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:33 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010332; 5 May 86 23:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a028477; 5 May 86 23:44 EDT From: John Rose Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <5097@think.ARPA> Date: 5 May 86 14:52:47 GMT Xref: seismo net.lang.c:9052 net.lang.c++:202 To: info-c@BRL-SMOKE.ARPA In article <763@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <4495@cbrma.UUCP> cbrma!trl (Tom Lanning) writes: >> Are there any "malloc" routines that check for modification of >>malloc's link pointers by the "user's" code? Close to 70% of by bugs >>are stack/memory problems were I use more space than I allocated. > >As mentioned in the man page, the malloc() code has a compile-time option >for strict checks on the arena. (This is not too useful if you have no >source code, of course.) If you do have source code, here's another suggestion which has worked very well for me. Define an circular buffer which stores a record of the last few hundred records of malloc/free/morecore history. Make sure your symbolic debugger can dump it for you. This trick alone has saved me hours of debugging time on quite a few occasions. In my applications, someone would either (1) try to use freed storage, or (2) go off the end of allocated storage, and usually these errors occurred within a dozen history events after the call to (1) free or (2) malloc. >Now, if only somebody would invent an architecture where all objects, >including dynamicly allocated objects, are isolated in memory, then any >subscript error would cause an immediate memory fault. You'd still be >vulnerable to completely wild pointers (but less likely in a huge address >space), and overflow of an array inside a structure might be untrappable, >but otherwise it sounds like a great machine to do your debugging on. > >Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint It's called the "Lisp Machine". All storage is allocated and manipulated according to very strict typing rules, enforced in microcode. If you walk off the end of an array, you get an immediate break into the debugger, with options to (a) abort, (b) re-invoke any stack frame, (c) return from any stack frame, (d) extend the array in place, (e) anything else you can specify in Lisp (the debugger, command loop, and application all run in the same address space! This is safe because of the enforcement mentioned above). The C compiler I'm using (Zeta-C from Zeta-Soft, Ltd.) implements pointers (approximately) as ordered pairs of arrays and indexes. The bounds-checking can be done in macrocode on a conventional machine. The BCC compiler (from Delft Consulting?) does this by source-transforming a C program so that pointers turn into small records carrying bounds information. Both systems (as far as I know) model the C runtime memory as a collection of "floating" byte arrays. Part of the justification for this is found in K&R RefMan 7.6 "Pointer comparison is portable only when the pointers point to objects in the same array." [Disclaimer: I have no professional connection with the Zeta-C or BCC companies, although I do know the implementors of both products personally.] -- ---------------------------------------------------------- John R. Rose Thinking Machines Corporation 245 First St., Cambridge, MA 02142 (617) 876-1111 X270 rose@think.arpa ihnp4!think!rose Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1236 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:36 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011127; 6 May 86 4:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a029766; 6 May 86 3:52 EDT From: "D.B. Robinson " Newsgroups: net.wanted.sources,net.unix,net.lang.c Subject: Re: Complex Arithmetic Library Wanted Message-ID: <288@foxvax5.UUCP> Date: 5 May 86 17:34:40 GMT Keywords: Math, Complex, Library, Source, C++ Xref: seismo net.wanted.sources:2429 net.unix:8178 net.lang.c:9058 To: info-c@BRL-SMOKE.ARPA In article <665@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes: >In article <1032@cybvax0.UUCP> dbr@foxvax5.UUCP (Douglas Robinson) writes: >>I am interested in a set of "C" language functions, suitable for >>linking to analytical programs, which perform complex number >>operations. ..... > >Such libraries can be useful, but a much better approach is to get C++, >which allows you to define your own data types, and overload the >standard operators to work with them. Program development is a lot ... >Your programs also run faster because the complex functions can be >expanded in-line at compile time instead of using function calls. I have heard mixed reviews of C++. Yes it seems that it would be a great productivity tool PROVIDING you have a 32Bit CPU and a compiler with LARGE amounts of capacity (I've heard of people exhausting certain limits on the 4.2BSD compiler on a VAX...). Some of us still have to be able to live with 16Bit processors (INTEL 8088/86/286) and some of us even have to live in the small model domain (strictly 16 bit addressing with split I/D). Not everyone has a spare VAX in their basement (YET :->). Douglas Robinson jobs don't kill programmers, programmers kill jobs The Foxboro Company MS 04-3A cybvax0!foxvax5!dbr 38 Neponset Avenue Foxboro, MA 02035 617/543-8750 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1340 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:46 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028440; 6 May 86 10:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a004722; 6 May 86 9:40 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#1 Message-ID: <1023@hou2d.UUCP> Date: 4 May 86 16:21:26 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sun, 4 May 86 Volume 16 : Issue 1 Today's Topics: #import (4 msgs) /*/ ---------------------------------------------------------------------- Date: Mon, 21 Apr 86 11:37:49 pst From: sdcrdcf!trwrb!desint!geoff Subject: #import To: trwrb!sdcrdcf!cbosgd!std-c In article <1007@hou2d.UUCP> John Gilmore (hoptoad!gnu) writes: > > I suggest that the #import form *not* be implemented; I never > saw what was wrong with #include "file.h" since it will be found in the > standard directories anyway. (Anybody who puts "stdio.h" in their > current directory and then wants to include /usr/include/stdio.h is > begging for her code to break next year when somebody else maintains > it.) This sounds find when you use 'stdio.h' as your example, but unfortunately it requires that people be familiar with the names of *all* the include files on their system. Furthermore, if I'm writing code I hope to port to BSD, it prevents me from having a subdirectory named 'net' that has a bunch of include files that I don't even know the names of. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff ------------------------------ Date: Mon, 21 Apr 86 12:04:58 est From: ihnp4!mnetor!clewis (Chris Lewis) Subject: #import To: utcs!cbosgd!std-c I disagree [with gnu's comments]. Many times I've needed to differentiate between <...> and "..." include formats. In a cross-compilation environment it is frequently necessary to be able to differentiate between include files from the "host", and those of the "target". For example, trying to cross-compile "size" where you want stdio.h from the host (/usr/include/stdio.h), and a.out.h for the target (./a.out.h) - so you can build a version of "size" that runs on the one machine to analyse load modules for another machine. At least being able to use "..." and <...> forms allows you to document this fact - plus to ensure that you aren't picking up the target's ./stdio.h by accident. (you're going to say "but the a.out.h include files should be the same anyways" - they aren't - our host is BSDish, our target is SVR2ish) Wouldn't it be simpler just to ensure that the cpp's "#include" never picked up the same file twice? (rather than inventing a new keyword) I can't think of too many scenarios where you want to include the same file twice in one compilation. -- Chris Lewis, UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis BELL: (416)-475-8980 ext. 321 ------------------------------ Date: Wed, 23 Apr 86 10:18:59 MST From: utah-cs!utah-gr!thomas (Spencer W. Thomas) Subject: #import Problem is that "" means start searching on the directory where the file with the #include statement is found (at least for Reiser cpp). So, if you have a.h: .... #include "b.h" ... and you wish to redefine b.h, you must also copy a.h to your working directory. Working on the principal that only files being modified should be copied, this is a >bad thing<. If, on the other hand, a.h had #include you could just make a local copy of b.h and put -I. on your cc line. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) ------------------------------ Date: Tue, 22 Apr 86 12:47:39 est From: Davidsen Subject: #import To: std-c@cbosgd.uucp.arpa As much as I like the idea of "#import", I admit that I don't see the reason for not implementing the form. There are a number of system includes which include other things, and if I want to be *SURE* that the definitions I need are included, what better way to do it than by use of the #import ? Computers are so much better than people at that sort of thing. It also reduces the room for error when someone creates a file by the same name as a system include. Other than that, I feel that it is a very useful proposal. In that vein, how about a #cdef? Replace: #ifndef M_LIMIT #define M_LIMIT 407 /* default value */ #endif with: #cdef M_LIMIT 407 /* default if missing on cc line */ This seems to solve the same class of problem... ------------------------------ Date: Sun, 27 Apr 86 20:50:03 edt From: decvax!minow (Martin Minow) Subject: /*/ To: cbosgd!std-c A note in net.lang.c suggested that the three-character string "/*/" was a complete comment (containing both a comment start "/*" and comment end "*/"). This isn't the case on Ultrix-32 (prais be), and I wonder whether it would be in Draft standard. Hopefully not. Martin Minow decvax!minow ------------------------------ End of mod.std.c Digest - Sun, 4 May 86 12:17:48 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1381 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:47 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004661; 6 May 86 13:59 EDT Received: from USENET by SMOKE.BRL.ARPA id a013296; 6 May 86 13:44 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <5401@alice.uUCp> Date: 5 May 86 18:35:49 GMT To: info-c@BRL-SMOKE.ARPA >>Btw, you can't have *all* operators extended with "=". How would you write >>"v = v < e;"? (Not that it's useful.) > I think it's useful! As written, of course, it's semantically invalid, > but what you really mean is "v <= e" (sic) or, to demonstrate where it's > really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; > Now "<=" already means something else so this syntax is not acceptable. > How about "v < = e" with a mandatory blank? This is atrocious human > engineering but at least is parseable. Anybody have any better ideas? You have suggested that v < = e should mean if (v < e) v = e but this is not parallel to the other `=' operators. Instead, if it means anything at all it should mean v = v < e In other words, afterwards v is either 1 or 0 depending on the value of e and the previous value of v. But I can't imagine when I'd ever want to use this in practice. Maybe we should just leave the language alone. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1444 for JMS@ARIZMIS; Thu, 8-MAY-1986 02:57 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005217; 6 May 86 14:15 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a013637; 6 May 86 13:49 EDT Received: from juliet.caltech.edu by AOS.BRL.ARPA id a003813; 6 May 86 13:27 EDT Date: Tue, 6 May 86 10:27:29 PDT From: "William E. Woody" Message-Id: <860506102602.046@Juliet.Caltech.Edu> Subject: Obfuscated C To: info-c@juliet.caltech.edu Comment: None. I understand that it would be very useful to have /\, \/, #import, ^^, &#, and any other pair of non-alphanumeric character represent some special operation that would be useful (and even _important_) for some application or another. HOWEVER, as useful it would be to include other operators, Remember What Happened to PL/1. Because everyone in the design committee wanted something and no-one wanted to say no! we stop adding commands/functions/operators here, I have never seen a full implementation of PL/1 on any machine--the original language specifications are too bloody big to have a compiler fit on a single vax. I Like C to be reasonably easy to learn _and_ extremely powerful, as well. But if we tack on new commands and operators at will, then everyone's program will be a winner in the Obfuscated C contest! - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 Boy I can feel the flames now! :-) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1591 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:07 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005268; 6 May 86 14:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a013733; 6 May 86 13:52 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <794@bentley.UUCP> Date: 6 May 86 13:43:45 GMT To: info-c@BRL-SMOKE.ARPA In article <390@hadron.UUCP> hadron!jsdy (Joseph S. D. Yao) writes: >BTW, given all these defines: here are some "cute" ones of mine: ... >#define streq(a,b) (strcmp(a, b) == OK) A more general mechanism is #define strrel(a,R,b) (strcmp(a, b) R 0) which allows you to write strrel(a,==,b). Some consider this to be abuse of the preprocessor. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1658 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:14 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005314; 6 May 86 14:19 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a013830; 6 May 86 13:52 EDT Date: Tue, 6 May 86 13:46:06 EDT From: Doug Gwyn (VLD/VMB) To: Brooks Gelfand cc: info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint > C is the only language that I can remember that has a separate > program (lint) to find and report compiler errors in source code. First, the errors detected are not COMPILER errors but CODING errors. Second, I supose you never heard of the PL/I checkout compiler nor of "student Fortran compilers" such as WatFor? Separate compilers were used to generate production executable binary once the program was debugged. Third, "lint"ing is not necessary on every compilation. I often rebuild already de-linted software from source (e.g., when a library routine has been improved). Fourth, on small systems such as the PDP-11, making "lint" a separate program makes it possible to have both better compilation and better error checking without resorting to complicated multi-pass compilation. Fifth, "lint" is rather portable (I use the same version on three distinct architectures), whereas a code-generating compiler is inherently machine-dependent. In short, I see nothing wrong with the present set-up. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1762 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005389; 6 May 86 14:21 EDT Received: from USENET by SMOKE.BRL.ARPA id a013828; 6 May 86 13:52 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <795@bentley.UUCP> Date: 6 May 86 13:44:24 GMT To: info-c@BRL-SMOKE.ARPA In article <12329@ucla-cs.ARPA> jimc@ucla-cs.ARPA (Jim Carter) writes: >In article <778@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>Btw, you can't have *all* operators extended with "=". How would you write >>"v = v < e;"? (Not that it's useful.) > >I think it's useful! As written, of course, it's semantically invalid, Whoa! The operator I was referring to was "v = v < e", which is the clear generalization of "op=" on operator "<". This is meaningful in C, because the boolean result of "<" will be interpreted as an integer. But it is not generally useful, because one does not normally use a boolean argument to a comparison operator like "<". >but what you really mean is "v <= e" (sic) or, to demonstrate where it's >really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; Now we're discussing "if (v < e) v = e;" which means "v = max(v,e);". This is indeed a useful operation, but the operator is now "max" rather than "<". >Now "<=" already means something else so this syntax is not acceptable. >How about "v < = e" with a mandatory blank? This is atrocious human >engineering but at least is parseable. Anybody have any better ideas? Yes. I already mentioned this in the discussion about builtins, but I think it bears repeating. Introduce a new operator "<>" for max (and "><" for min). Add the corresponding assignment operator "<>=" (and "><=") with the above meaning. The symbol "<>" is currently meaningless in C, though basic and pascal users would have a fit. "|>" and "<|" may be better choices. "\/" and "/\" would mimic the mathematical notation, but there may be reasons to avoid the use of backslash in program source. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1846 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:36 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007089; 6 May 86 15:08 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a016454; 6 May 86 14:59 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29561; Tue, 6 May 86 14:59:14 edt Date: Tue, 6 May 86 14:59:14 edt From: Root Boy Jim Message-Id: <8605061859.AA29561@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Re: C Builtin Functions > >I can feel the flames ("More operators? It's getting as bad as APL!"). Hey, the more primitives, the better. I also like(d) TECO. Just because a language is terse, doesn't mean it's unreadable. In my opinion, people who laughed at the greek were just to lazy to learn the lingo. APL is quite readable once you get used to it, especially with direct definition. > Excuse me...in APL parlance (eg, the language used in the APL Draft Standard), > things like "+", "-",etc. are called functions, as are user-defined functions. > Operators are things which alter the effect of functions, such as "." in the > context of "+.x", which causes an inner matrix product to be evaluated. Interesting. Would the construct `+.FUNC' be legal also? > (No, this doesn't belong in net.lang.c, but YOU STARTED IT!) And I'm adding to it. > Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 > {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1919 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 05:22:31 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010515; 6 May 86 15:49 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a017358; 6 May 86 15:25 EDT Received: from icst-cmr.arpa by AOS.BRL.ARPA id a007213; 6 May 86 15:12 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29608; Tue, 6 May 86 15:12:39 edt Date: Tue, 6 May 86 15:12:39 edt From: Root Boy Jim Message-Id: <8605061912.AA29608@icst-cmr.ARPA> To: cbmvax!grr@seismo.ARPA Subject: Error Cc: info-c@BRL.ARPA > Hi Jim: Howdy. > Yeah, I've seen error - an amazing retrofit job! One of those deals > where the user has to do tricks to do a simple thing. Actually, it is a testamonial to UNIX that such a thing CAN be done. Many other systems wouldn't be able to coordinate such a task so efficiently. What, pipe two (or more) separate programs together? Shocking! > I should point out that my shock occured maybe 10 years ago, and > things a little better organized now. I've spent time before and since > working IBM stuff, and worse, so perhaps I'm permanantly brain damaged, but > there are a few things about unix that are primitive... > > 02:30; > George Robbins > ...!{ihnp4|seismo|caip}!cbmvax!grr I must admit that I was surprised when I found out there was no listing file generated. But they were right! Who needs it? (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1971 for JMS@ARIZMIS; Thu, 8-MAY-1986 03:45 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011838; 6 May 86 16:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a018675; 6 May 86 15:58 EDT From: Doug Gwyn Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <601@brl-smoke.ARPA> Date: 6 May 86 19:57:49 GMT To: info-c@BRL-SMOKE.ARPA In article <560@brl-smoke.ARPA> Root Boy Jim writes: >BSD has a program called `error' that will insert the errors ... Coals to Newcastle. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3152 for JMS@ARIZMIS; Thu, 8-MAY-1986 06:09 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 07:52:59 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012051; 6 May 86 16:26 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a019020; 6 May 86 16:11 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29705; Tue, 6 May 86 16:11:03 edt Date: Tue, 6 May 86 16:11:03 edt From: Root Boy Jim Message-Id: <8605062011.AA29705@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, ulysses!ggs@seismo.ARPA Subject: Re: Boolean Operators Slighted in C > > In article <778@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: > > >Btw, you can't have *all* operators extended with "=". How would you write > > >"v = v < e;"? (Not that it's useful.) > > I think it's useful! ... > ... [ deleted usual arguments for "op-assign" operators ] > > James F. Carter (213) 206-1306 > > UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 > > UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU > > I think the quality of suggestions is degenerating rapidly. This is a > blatant type clash. The "op-assign" interpretation of " <= " is > self-contradictory nonsense. The expression "v < e" has the > (nonexistent) type "boolean", which implies that the destination is > also boolean. But that implies that you are using a boolean variable > in the " < " relation, which would be nonsense if "bool" were a real type. It would be nonsense IF boolean was a real type. There is no need to make any distinction between them. It just gets in the way of coding. APL, the most mathematical language, treats booleans exactly like C. THERE IS NO SUCH THING AS A BOOLEAN DATA TYPE (to which Doug Gwyn will reply `there is no such thing as an integer either :-). There may be boolean OPERATORS, but their range and domain is integers. > Instead of proposing yet another obfuscation of the language, why don't > we discuss ways that we can simplify and improve the clarity of our > coding style within the confines of the current language. Better yet; > quit talking, and do something about it. Like what? Make it like Pascal :-) > Griff Smith AT&T (Bell Laboratories), Murray Hill > Phone: (201) 582-7736 > Internet: ggs@ulysses.uucp > UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs ) A couple of wild suggestions myself. In the tradition of APL one liners, 1) Chain Lvalues. I would like to be able to write: ((n *= 10) += (c -= '0'); instead of c -= '0'; n *= 10; n += c; 2) More of the same. We all know about *++p. But what if I want to jump more than one element? I can't write *(p += 2); Or maybe I want to write `p = &(i += 5). 3) Exchange operator. This has probably been discussed before, so pardon me if I blunder into that pit. BUT, DMR has stated that one of the reasons that exponentiation was left out was because no (or few, if any) machine could do it inline, and therefore all the compiler would be doing is a function call anyway. By the same reasoning, exchange CAN be done efficiently by some machines, and the hack of a temporary variable and three assignments is a rather stale idiom. The three statement XOR trick avoids the temporary, at the expense of execution time and clarity. 4) Allow complex statements to be considered as expressions so that the comma operator can be used to avoid braces, as in if (e) x = y, return z; 5) Allow immediate constants. Currently, there is only one special case, that of a character array. One can say char *p = "string"; and have the string squirreled away and the (magic) address stuffed into the pointer. Why not int *p = &5; where the integer five is whisked away and replaced by its address. Sure would eliminate a lot of housekeeping variables. 6) Eliminate arrays altogether! Well not exactly, but make all arrays vectored in all dimensions. This would show those quiche eaters what a real tough language C is :-). Array syntax would still be available of course, but would be translated into glorious pointer notation. And it wouldn't matter whether a variable was defined differently than it was declared (char x[] or char *x). 7) Negative Structure Offsets. After reading those last few, I don't expect anyone to take me seriously, but I am serious. These can be real useful for such things as communications, where each block is wrapped in another layer. We can even use the entry keyword for this (quick before ANSI takes it out :-). The advantage is real and twofold. First, all offsets are] known at compile time, and second, if the data is redone, only the code that uses it need be recompiled. This could be a win, especially if other programs used the same data. 8) Allow formal arguments to be declared AFTER the opening brace. This would allow prioritization of register variables. Well that should be enuf to chew on. I'm not really seriously suggesting munging the language. This is just a thought experiment in the art of the possible. I'm not even going to mention such radical changes as explicit end statements (gid rid of braces), an #include MACRO from FILE, or using backquotes as explicit substition characters (to allow concatenation of tokens, but it would break strings with backquotes in them, be them ever so few) as these would be major redefinitions. Now I will go on vacation until all the flames die out :-). (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4199 for JMS@ARIZMIS; Thu, 8-MAY-1986 07:56 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 09:47:06 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014808; 7 May 86 3:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a024704; 7 May 86 3:42 EDT From: Arthur David Olson Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <6092@elsie.UUCP> Date: 6 May 86 22:40:14 GMT To: info-c@BRL-SMOKE.ARPA > The. . .header file that I mentioned a few days ago. . . > contains the following: > > typedef int bool; /* boolean data */ > #define false 0 > #define true 1 My recommendation to folks would be to use the defines that appear in the 4.?bsd version of "curses.h"-- # define TRUE (1) # define FALSE (0) --on a conditional basis in any "nifty_header.h" file, a la: #ifndef TRUE #define TRUE (1) #define FALSE (0) #endif Using the "unnecessary" parentheses that appear in "curses.h" will prevent any "redefined to a different value" diagnostics if you both #include "curses.h" and #include "nifty_header.h" while conditionalizing the definitions as above will prevent "redefined (though not to a different value)" diagnostics if you include both files in the order shown above. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Shakespeare trademarks. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4291 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:01 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014865; 7 May 86 4:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a024700; 7 May 86 3:42 EDT From: Arthur David Olson Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <6091@elsie.UUCP> Date: 6 May 86 22:28:37 GMT To: info-c@BRL-SMOKE.ARPA > . . .All the PCC impementations I've checked don't test the ["1" in a > "while (1)"] even when you don't turn the optimizer on. Our old PDP-11 > Ritchie compiler does generate the test, but the standard -O optimizer > removes it. . . If I recall my ancient history aright, the Version 6 C compiler generated the constant test, and the Version 6 optimizer failed to remove it. -- PDP is a Digital Equipment Corporation trademark. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Shakespeare trademarks. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4360 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:09 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015233; 7 May 86 6:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a026413; 7 May 86 5:58 EDT From: G M Anderson Newsgroups: net.micro.pc,net.lang.c Subject: PC .COM files and memory resident code. Message-ID: <733@ssc-vax.UUCP> Date: 6 May 86 19:37:17 GMT Xref: seismo net.micro.pc:8619 net.lang.c:9073 To: info-c@BRL-SMOKE.ARPA I am interested in creating a resident interrupt driven process in C, and I don't really care if it is a .COM, .EXE, or whatever. I understand how to do it in assembly, but it appears very difficult to do in C because of the jumping around code, replacing addresses, getting addresses, and the sticky little stack segment problem. (By the way, if there is no defined stack segment, where does the stuff stack up?) If anyone knows how to: 1) Create interrupt driven code with C. 2) Make that code memory resident without assembly modification. 3) The proposed memory resident addressing agreements between MS, and the popup utility people. I would greatly appreciate your help. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4461 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:16 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015267; 7 May 86 6:27 EDT Received: from USENET by SMOKE.BRL.ARPA id a026203; 7 May 86 5:50 EDT From: "Wayne A. Christopher" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <277@cad.UUCP> Date: 6 May 86 04:10:41 GMT To: info-c@BRL-SMOKE.ARPA Hmm, so now we see from which soapbox Root Boy is speaking... I don't like to criticize people's personal preferences, but when you are writing code that other people have to maintain, strange coding practices like this are as bad as bugs... I almost wish that lint would catch non-standard style in addition to portability problems... Wayne Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4557 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:22 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015269; 7 May 86 6:27 EDT Received: from USENET by SMOKE.BRL.ARPA id a026285; 7 May 86 5:53 EDT From: "Wayne A. Christopher" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <276@cad.UUCP> Date: 6 May 86 03:52:52 GMT To: info-c@BRL-SMOKE.ARPA The thing that RBJ seems to be annoyed about is the fact that lint generates error messages whenever you ignore the return value of close(), unlink(), etc, and it is quite ugly to put (void) in everywhere. However, in my experience if you use the right flags these are the only sort of errors you should ignore (and malloc pointer problems, of course). I would say that the most useful messages lint gives you is argument type/number mismatches... Wayne Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4717 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:36 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa17043; 7 May 86 8:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a028136; 7 May 86 7:51 EDT From: Toby Gottfried Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <1138@felix.UUCP> Date: 5 May 86 20:09:25 GMT Xref: seismo net.lang.c:9074 net.lang.c++:204 To: info-c@BRL-SMOKE.ARPA In article <763@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Now, if only somebody would invent an architecture where all objects, >including dynamicly allocated objects, are isolated in memory, then any >subscript error would cause an immediate memory fault. Burroughs did exactly this in their Large Systems over 20 years ago. >You'd still be vulnerable to completely wild pointers (but less likely >in a huge address space), Not a problem - the address space isn't flat. >and overflow of an array inside a structure might be untrappable, >but otherwise it sounds like a great machine to do your debugging on. It is. -- Toby Gottfried FileNet Corp {ucbvax,ihnp4,decvax}!trwrb!felix!toby Costa Mesa, CA Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4873 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:59 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 10:30:50 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005911; 7 May 86 23:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a003473; 7 May 86 23:43 EDT From: "Sundar R. Iyengar" Newsgroups: net.lang.c,net.lang.c++,net.arch Subject: iAPX 432 Message-ID: <1474@cwruecmp.UUCP> Date: 6 May 86 13:50:37 GMT Xref: seismo net.lang.c:9075 net.lang.c++:205 net.arch:3295 To: info-c@BRL-SMOKE.ARPA >> >Now, if only somebody would invent an architecture where all objects, >> >including dynamicly allocated objects, are isolated in memory, then any >> >subscript error would cause an immediate memory fault. >> >> If I'm not mistaken, this was done on the iAPX432, using a capability- >> based addressing scheme. Dimmed the lights. You could probably construct >> such an environment on the 80286, but no one does, probably for efficiency >> reasons. > One problem with the 432's approach was that it was very extreme; I don't > think it's good to say "the 432 tried these approaches and it was too slow, > therefore the checking can't be efficiently implemented." If I remember correctly, iAPX 432 is a vertically microcoded machine. On top of that, the microcode is generated in one chip and then used in another. These two are some more reasons why iAPX is slow. -- sri Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4801 for JMS@ARIZMIS; Thu, 8-MAY-1986 08:59 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 05/08/86 at 10:27:20 CDT Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Tue 6 May 86 11:53:40-PDT Received: from (MANSFIEL)DHDEMBL5.BITNET by WISCVM.WISC.EDU on 05/06/86 at 12:08:58 CDT Date: Tue, 06 May 86 16:14:20 n To: info-vax@sri-kl.arpa From: Niall Mansfield Organisation: European Molecular Biology Laboratory Postal-address: Meyerhofstrasse 1, 6900 Heidelberg, W. Germany Phone: (6221)387-0 [switchboard] (6221)387-247 [direct] Subject: Problem with C and Link If the file T.C contains extern char *sto; main() { f("bongo"); printf("%s\n", sto); } and T2.C contains char sto[100] = 0; f(s) char *s; { strcpy(sto, s); printf("in func, sto is %s\n", sto); } and a program is made from the two by the commands $ cc t $ cc t2 $ link t,t2,sys$library:vaxcrtl/opt then running t gives the output in func, sto is bongo %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=676E6F62, PC =0000423B, PSL=0BC00005 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 0000423B 0000423B 00002941 00002941 T main 5 0000002B 0000042B As far as I can see, the linker is not correctly resolving T's reference to "sto". (c.f. what is printed if you insert the line printf("%d\n", sto); in both files). Is there something wrong? How do I do what I want, portably? Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6510 for JMS@ARIZMIS; Thu, 8-MAY-1986 11:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 13:11:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018549; 8 May 86 13:43 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a015628; 8 May 86 13:22 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA14418; Thu, 8 May 86 13:22:37 edt Date: Thu, 8 May 86 13:22:37 edt From: Root Boy Jim Message-Id: <8605081722.AA14418@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, sfsup!mjs@seismo.ARPA Subject: Re: C Builtin Funxions In article <1700010@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I feel compelled to go on record as being VERY MUCH AGAINST >having reserved procedure names in C. For those of us who have >ever written stand-alone code for PDP-11s, VAXen, ..., it is >a simple matter, as things stand, to compile our programs, >and then have them linked with our own versions of 'putc', >'read', etc. stashed in stand-alone libraries. > ... >In addition, porting the C compiler to a different OS on the >same machine only requires that the libraries be re-written >(almost always). Building those functions into the language >implies that there will be much code for special casing those >functions. Nowhere is it required that the compiler have any special knowledge of the reserved names in the library. Yes, *some* compilers will undoubtedly have *some* special knowledge of *some* of those names, but the ANSI spec does *NOT* *require* the compiler to know anything about any reserved library names. Please, do NOT flame about statements that are not made in the spec. There are enough statements that ARE made in the spec that may be worth flaming about (although I hope that rational discusssion, rather than flames, result). He didn't say it would be *required*. Neither did I. We don't want it even allowed, unless we can turn it off. I would even go one step further and require that you explicitly turn it on for each function. If you don't have a copy of the current state of the proposed standard, GET ONE! Yeah, fork over another $20 for an out-of-date copy. Possibly the one you already have. They should be free, posted to net.sources, and distributed by the NIC or some such. See quote at end of article. Marty Shannon UUCP: ihnp4!attunix!mjs Phone: +1 (201) 522 6063 Disclaimer: I speak for no one. "If I never loved, I never would have cried." -- Simon & Garfunkel "Well I've paid all the dues I want to pay" -- S & G (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6614 for JMS@ARIZMIS; Thu, 8-MAY-1986 11:51 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 13:16:01 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018825; 8 May 86 13:56 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a015983; 8 May 86 13:39 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA14458; Thu, 8 May 86 13:39:39 edt Date: Thu, 8 May 86 13:39:39 edt From: Root Boy Jim Message-Id: <8605081739.AA14458@icst-cmr.ARPA> To: gelfand%valid.uucp@BRL.ARPA, gwyn@BRL.ARPA Subject: Re: questions from using lint Cc: info-c@BRL-SMOKE.ARPA ????--> > C is the only language that I can remember that has a separate ????--> > program (lint) to find and report compiler errors in source code. GWYN--> [most of reply deleted] Because I agree with everything you said here. GWYN--> In short, I see nothing wrong with the present set-up. First off, let us remember that `cc' is NOT the C compiler. It is just the coordinator for all the phases that build programs. Therefore, I see no inconsistency with allowing `cc' to call lint if a given option is specified. This might encourage non-unix vendors to include lint with their products. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6774 for JMS@ARIZMIS; Thu, 8-MAY-1986 12:04 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/08/86 at 13:30:43 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018899; 8 May 86 13:57 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a016313; 8 May 86 13:44 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA14465; Thu, 8 May 86 13:43:46 edt Date: Thu, 8 May 86 13:43:46 edt From: Root Boy Jim Message-Id: <8605081743.AA14465@icst-cmr.ARPA> To: bentley!kwh@seismo.ARPA, info-c@BRL-SMOKE.ARPA Subject: String Compare A more general mechanism is #define strrel(a,R,b) (strcmp(a, b) R 0) which allows you to write strrel(a,==,b). I *like* it! In fact, I think this is sufficiently general enuf to be called simply `string'. Some consider this to be abuse of the preprocessor. Well, they're just a bunch of wimps! (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1108 for JMS@ARIZMIS; Thu, 8-MAY-1986 21:00 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 05/08/86 at 22:43:01 CDT Received: from CSNET-RELAY.ARPA by SRI-KL.ARPA with TCP; Thu 8 May 86 02:08:46-PDT Received: from umass-cs by csnet-relay.csnet id ar10380; 8 May 86 1:37 EDT Date: Tue, 6 May 86 12:02 EST From: Stride 440 User To: info-vax@SRI-KL.ARPA Subject: VAX11-C & the IV entry-mask bit. We have some 240 little access functions written in C which we want integer overflow to be caught by the hardware. Since these routines are called frequently we don't want to add the overhead of a call to LIB$INT_OVER() every time an one of these access functions is called. Instead we would like the IV bit set in the entry masks of these routines. VAX11C does not set this bit. Is there some way to either make VAX11C set this bit? Or some way of modifying the .OBJ or .EXE file later? We are building these functions into a shareable image file. Robert Heller (Heller@UMass-CS.CSNET) or James Burrill (Burrill@UMass-CS.CSNET) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1685 for JMS@ARIZMIS; Thu, 8-MAY-1986 22:15 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 00:06:58 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a027467; 8 May 86 22:42 EDT Received: from brl-tgr.arpa by SMOKE.BRL.ARPA id a024045; 8 May 86 22:30 EDT Received: from mitre-bedford.arpa by TGR.BRL.ARPA id a025504; 8 May 86 22:26 EDT Full-Name: James R. Vanzandt Message-Id: <8605090225.AA14975@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: info-c@BRL-TGR.ARPA, info-ibmpc@USC-ISIB.ARPA, delftcc!sam@NYU.ARPA Subject: lint Date: Thu, 08 May 86 22:25:34 -0500 From: "James R. Van Zandt" >> I'm aware of four lint-type programs for checking C code on an MS-DOS machine: >> >> PC-LINT Tecware $ 99 >> PC-Lint Gimpel Software $139 >> Pre-C Phoenix Computer Products Corp. $395 >> Lint Wizard Systems Software, Inc. $450 (bundled with compiler) >> >> Can anyone report experience with these or others, or point to >> published reviews? All the responses but one were requests for information. Here's the one: > We are using the Wizard C compiler and BSD 4.3 to develop a large > (~150,000 lines) system that will run under UNIX and MS-DOS. The Wizard > compiler reports intra-module errors and warnings. The lint option > will create a lint library and do inter-module checking. Overall the > Wizard system catches the same errors that the BSD lint catches and > often reports more warnings. The whole package is well worth the price > (especially since you get library sources and can get an update service > from Wizard). > > -- > Brad Davis {ihnp4, decvax, seismo}!utah-cs!b-davis > b-davis@utah-cs.ARPA Now I'm trying to decide whether (1) nobody else has buggy C code, (2) nobody else wants to ADMIT to having buggy C code, or (3) lint is hazardous, and few users survive :-). - Jim Van Zandt Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3222 for JMS@ARIZMIS; Fri, 9-MAY-1986 01:02 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 02:41:46 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a027941; 9 May 86 1:13 EDT Received: from wiscvm.wisc.edu by SMOKE.BRL.ARPA id a024845; 9 May 86 1:02 EDT Received: from (MAILER)UREGINA1.BITNET by WISCVM.WISC.EDU on 05/09/86 at 00:02:12 CDT Received: by UREGINA1 (Mailer X1.23b) id 6967; Thu, 08 May 86 23:00:23 CST Date: Thu, 8 May 1986 22:59 CST From: Craig Knelsen Subject: Aztec C compiler bug(?) To: INFO-C@BRL-SMOKE.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA #include #include #include main() { register ControlHandle p; f((*p)->contrlTitle); } ---- -? cc c.c c.c: line 9: error 29: illegal use of structure: Compiler: Aztec C 1.06G for the Macintosh The problem seems to result from the fact that Aztec changed the declaration of the member 'contrlTitle' in control.h: 1.06D release: char contrlTitle[1]; 1.06G release: Str255 contrlTitle; where Str255 is a typedef for: char * I have tried this example under the Vax 4.2bsd and Sun 2.0 compilers with no complaints from either. Changing the declaration back to what it was in the 1.06D release makes the problem disappear. Removing the register storage class declaration doesn't make a difference as far as the error is concerned. Craig Knelsen Dept. of Computer Science University of Regina Regina, Sk. UUCP: {ihnp4 | utcsri | alberta} !sask!regina!cknelsen Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3608 for JMS@ARIZMIS; Fri, 9-MAY-1986 01:33 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 05/09/86 at 03:17:14 CDT Received: from USC-ECLC.ARPA by SRI-KL.ARPA with TCP; Wed 7 May 86 18:33:19-PDT Received: from ECLD by ECLC with DECnet; Wed 7 May 86 18:30:01-PDT Date: Wed 7 May 86 18:29:55-PDT From: Christopher Ho Subject: Re: Problem with C and Link To: Mansfield%DHDEMBL5.Bitnet@WISCVM.WISC.EDU cc: Info-Vax@SRI-KL.ARPA Office: Ucc 178 (213)743-2957 Message-ID: <12204916720.60.CHRIS@USC-ECLD.Internet> > If the file T.C contains > extern char *sto; > ... How about using the correct declaration: extern char sto[]; ------- Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5476 for JMS@ARIZMIS; Fri, 9-MAY-1986 05:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 07:18:21 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000647; 9 May 86 8:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a027890; 9 May 86 7:48 EDT From: faustus%cad.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <287@cad.UUCP> Date: 6 May 86 18:08:34 GMT To: info-c@BRL-SMOKE.ARPA In article <256@valid.UUCP>, gelfand@valid.UUCP writes: > I have been programming for many years (over 20) in many different > languages, and C is the only language that I can remember that > has a separate program (lint) to find and report compiler errors in > source code. First, lint doesn't report ERRORS -- it reports possible problems. Second, there is no other way you can check things like argument types (except for prototyping, which will make lint much less useful), since you generally compile only one .c file at a time. Wayne Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5616 for JMS@ARIZMIS; Fri, 9-MAY-1986 05:52 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 07:36:16 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001009; 9 May 86 8:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a027766; 9 May 86 7:45 EDT From: Rob McMahon Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <147@daisy.warwick.UUCP> Date: 7 May 86 10:22:04 GMT To: info-c@BRL-SMOKE.ARPA In article <412@brl-smoke.ARPA> gwyn@brl.ARPA writes: >typedef int bool; /* boolean data */ >#define false 0 >#define true 1 What about typedef enum { false, true } bool; ? -- UUCP: ...!mcvax!ukc!warwick!cudcv JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk PHONE: +44 204 523037 Rob McMahon, Computer Unit, Warwick University, Coventry CV4 7AL, England Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5715 for JMS@ARIZMIS; Fri, 9-MAY-1986 06:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 07:39:42 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001157; 9 May 86 8:23 EDT Received: from USENET by SMOKE.BRL.ARPA id a028062; 9 May 86 7:54 EDT From: "John R. Levine" Newsgroups: net.lang.c,net.unix-wizards Subject: Re: arguments in registers Message-ID: <109@ima.UUCP> Date: 6 May 86 15:36:51 GMT Xref: seismo net.lang.c:9080 net.unix-wizards:18103 To: info-c@BRL-SMOKE.ARPA In article <1205@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >In article <155@cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>[Passing arguments in registers] would be fine if C had nested >>procedures or inlines or something, but a disaster otherwise. > >In fact, a compiler is free to optimise any function into inline code, Actually, you can always pass arguments in registers if you're smart about it. The compiler for the IBM RT/PC does. (A clever idea added after I stopped working on it.) The first few arguments to a procedure are always passed in registers, but space is left for them in the stack frame. If they aren't declared register in the routine, the routine's prolog saves them. Note that this saves code space, since you have one set of store instructions in the routine's prolog rather than replicating the code at each call. If the arguments are declared register, well, they're already in registers. As far as passing args to system calls in registers goes, the big win there is that the kernel's job of validating the arguments is made easier. If the args are in memory, the kernel has to make sure the address is valid, go through some address mapping calculations, possibly take page faults, and so forth. It's much easier if the user program puts the args in registers, since then the validation is done for free by hardware. -- John R. Levine, {ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl Levine@YALE.EDU The opinions expressed above are those of a 12-year-old hacker who has broken into my account and not those of any person or organization. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5905 for JMS@ARIZMIS; Fri, 9-MAY-1986 06:06 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 07:59:33 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001647; 9 May 86 8:37 EDT Received: from USENET by SMOKE.BRL.ARPA id a027851; 9 May 86 7:47 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: Signed Characters Message-ID: <724@steinmetz.UUCP> Date: 6 May 86 19:07:51 GMT To: info-c@BRL-SMOKE.ARPA In article <570@tjalk.UUCP> dick@vu44.UUCP (Dick Grune) writes: >I just dropped into this, and it may have been said before, but if there >is char and unsigned char, I expect the char to be signed. X3J11 (ANSI C committee) added "signed char". If you assume that your char is signed your code is highly non-portable. -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5830 for JMS@ARIZMIS; Fri, 9-MAY-1986 06:08 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 07:51:01 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001191; 9 May 86 8:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a028275; 9 May 86 7:58 EDT From: "Daniel R. Levy" Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <857@ttrdc.UUCP> Date: 6 May 86 09:55:39 GMT To: info-c@BRL-SMOKE.ARPA In article <12329@ucla-cs.ARPA>, jimc@ucla-cs.ARPA (Jim Carter) writes: >I think it's useful! As written, of course, it's semantically invalid, >but what you really mean is "v <= e" (sic) or, to demonstrate where it's >really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; >Now "<=" already means something else so this syntax is not acceptable. >How about "v < = e" with a mandatory blank? This is atrocious human >engineering but at least is parseable. Anybody have any better ideas? >-- >James F. Carter (213) 206-1306 >UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 >UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU First, one could use the preprocessor to help: #define UPMAX(i,j) if ((i) < (j)) (i) = (j) ... UPMAX(array[h][s][l],bigexpr); While the output of cpp would look real messy, comp would handle this just fine. Of course, you lose (as with any macro which uses an argument more than once) if the arguments have side effects such as ++ (but that isn't the case here, right?). Or if you know that the optimizer is not smart enough to catch this and will evaluate the entire array[h][s][l] including subscripts twice (as well as bigexpr), you can force temp variables: FOO array[I][J][K]; ... FOO *atmp; FOO btmp; ... atmp = &(array[h][s][l]); btmp = bigexpr; UPMAX(*atmp,btmp); As for the lousy human engineering in requiring extra blanks in certain expressions, don't we have that already in C, e.g.: a = b/*c; /* did this mean divide b by *c, or to start a comment? */ ; a=*b; /* compiler complains about "ambiguous assignment" here */ -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6173 for JMS@ARIZMIS; Fri, 9-MAY-1986 06:27 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 08:11:50 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001671; 9 May 86 8:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a027856; 9 May 86 7:48 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <725@steinmetz.UUCP> Date: 6 May 86 19:22:29 GMT To: info-c@BRL-SMOKE.ARPA In article <116@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <117@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >> >>do ... while(1); >>while(1) ... >>for(;;) ... >> >>are all widely-used idioms for unconditional looping in C. >>I personally prefer the latter, but the choice is just a >>matter of taste. Any reasonable compiler will generate >>efficient code for all three constructs. > >#define loop for(;;) > >This is a clean way to do it, but be aware that there is no obvious stopping >point, and soon C purists will soon be declaring that your code has been tainted >by exposure to noxious influences from Algol 68 or worse... > You could change the definition(s) to: #define loop for(;;){ #define endloop } Or, as I have seen in a few programs: #define ever (;;) -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6672 for JMS@ARIZMIS; Fri, 9-MAY-1986 07:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 09:18:34 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004540; 9 May 86 10:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a001526; 9 May 86 9:50 EDT From: Frank Adams Newsgroups: net.lang.c,net.lang.apl Subject: Re: C Builtin Functions Message-ID: <1418@mmintl.UUCP> Date: 6 May 86 19:03:38 GMT Xref: seismo net.lang.c:9082 net.lang.apl:199 To: info-c@BRL-SMOKE.ARPA In article <788@bentley.UUCP> kwh@bentley.UUCP writes: >I can feel the flames ("More operators? It's getting as bad as APL!"). > >Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint "More operators? It's getting as good as APL!" -- except that it still falls way short in this respect. I'm serious; APL does *not* have too many operators. It does have too little structure. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6770 for JMS@ARIZMIS; Fri, 9-MAY-1986 07:33 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 09:21:16 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004610; 9 May 86 10:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a001539; 9 May 86 9:51 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <1419@mmintl.UUCP> Date: 6 May 86 20:17:25 GMT To: info-c@BRL-SMOKE.ARPA In article <12329@ucla-cs.ARPA> jimc@ucla-cs.UUCP (Jim Carter) writes: >I think it's useful! As written, of course, it's semantically invalid, >but what you really mean is "v <= e" (sic) or, to demonstrate where it's >really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; >Now "<=" already means something else so this syntax is not acceptable. >How about "v < = e" with a mandatory blank? This is atrocious human >engineering but at least is parseable. Anybody have any better ideas? What you talking about isn't "<=". It's "\/=" (to use a notation which showed up here recently). I.e., v = min(v,e), not v = v < e. The latter really is pretty useless. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6996 for JMS@ARIZMIS; Fri, 9-MAY-1986 08:30 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 09:41:16 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004752; 9 May 86 10:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a001634; 9 May 86 9:53 EDT From: Gregory Smith Newsgroups: net.unix,net.unix-wizards,net.lang.c Subject: Re: faster malloc anyone? Message-ID: <2699@utcsri.UUCP> Date: 4 May 86 18:19:43 GMT Xref: seismo net.unix:8192 net.unix-wizards:18105 net.lang.c:9084 To: info-c@BRL-SMOKE.ARPA In article <433@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >each call to strsav(). So, I wrote the following little chunks of code and >am requesting comments. Can anyone point out why these are a *bad* idea >(aside from the obvious upper bound problem)? Another problem is that >free() won't work on these blocks... stay tuned... > >new.h: ># define BLKSIZ 8096 >char* new(); > >utils.c: >/* utils.c -- strsav(), new() */ ># include "new.h" > > char* >strsav(s) > register char* s; >{ > char* strcpy(); > register char* t; > > t = new(strlen(s) + 1); /* strings smaller than BLKSIZ */ > return strcpy(t, s); >} > > >/*------------------------------------------------------------------02/May/86-* > * new(size) - fast(??) memory allocator > * > * Inputs -> (int) > * > * Returns -> (char*) > * > * Results ->The memory is allocated in big contiguous blocks via calloc(3). > * If the requst can fit in what's left of a block, then a block > * of the size requested is returned. Otherwise, the rest of the > * block is discarded & a new block is allocated. > * > * Warning -> This would seem to work great for little stuff. Don't use it > * for big blocks. Absolute largest allocatable block is BLKSIZ. > * For speed NO CHECK IS PERFORMED TO SEE IF THE REQUEST IS LESS > * THAN BLKSIZ. BLKSIZ is guaranteed to be 1k or bigger (usually > * much bigger). > * Revisions: > *-----------------------------------------------------------------larry-*/ > char* >new(size) > register unsigned size; >{ > register char* blk; > static char* block = NULL; > static unsigned bytes_left = 0; > > if (bytes_left < size) /* bytes_left should be set to BLKSIZ here */ > if (!(block = calloc(1, BLKSIZ))) > syserr("calloc in new"); > > blk = block; > block += size; > bytes -= size; return blk; :-) >} >-- If the storage occupied by these strings can be released all at once, the following 'new' can be used: struct str_block{ struct str_block *sb_link; char sb_chars[ BLKSIZ ]; } *allocated = NULL; unsigned bytes_left = 0; char* block; char *new(size) register unsigned size; { register char* blk; register struct str_block *new_blk; if (bytes_left < size){ if ((new_blk =(struct str_block*) malloc(sizeof( struct str_block))) == NULL) syserr("malloc in new"); bytes_left = BLKSIZ; new_blk->sb_link = allocated; allocated = new_blk; block = new_blk->sb_chars; } blk = block; block += size; bytes_left -= size; return blk; } /* * this subroutine frees up all allocated memory */ forget(){ register struct str_block *p; while( (p = allocated) != NULL ){ allocated = p->sb_link; free(p); } bytes_left = 0; } I used a similar approach on a program I wrote recently - many small structs needed to be allocated and reused during a certain phase of execution, and then they were all released at once. So I got them from malloc in blocks of about 200, and handled them on linked lists. When I was done, I released all the blocks, which were kept on another linked list. An enhancement: maintain separate 'allocated, bytes_left, block' triplets for independent storage categories - then each category can be 'forgotten' independently of the others. -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9804 for JMS@ARIZMIS; Fri, 9-MAY-1986 13:43 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 14:18:48 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005087; 9 May 86 10:27 EDT Received: from USENET by SMOKE.BRL.ARPA id a001673; 9 May 86 9:54 EDT From: Ray Butterworth Newsgroups: net.lang.c Subject: Re: LINT Message-ID: <2452@watmath.UUCP> Date: 6 May 86 14:26:16 GMT To: info-c@BRL-SMOKE.ARPA > From rbj@icst-cmr (Root Boy Jim) Fri May 2 17:28:02 1986 > Yes, but it all depends on what you're willing to put up with. I find it > terribly ugly having to cast printf's or close's to void. Not only is it ugly, it's wrong. Didn't you read in the man page where it says that these functions return ERROR STATUSES? Do you believe that nothing will ever go wrong? What if programs such as cat(1) didn't check these error statuses, think what a mess the world would be in. I mean if one ran cat from a tape and an I/O error occured, it would probably just treat it as end-of-file and not tell you that the rest of the file couldn't be read, and if your file-quota was exhaused cat wouldn't notice that it couldn't flush its buffers properly and there you would be with an empty file and cat telling you that everything ran fine. > From: woody@juliet.caltech.edu (William E. Woody) > Here here! Though (whenever possible) I try to run my code through lint, > I think I only use about a fifth of what lint complains (screams, shouts, > moans, groans) about. I too used to think that most of what lint complained about was crap. I also noticed an awful lot of things that it didn't complain about but should have. So I took the source and turned on all the options that normally make it shut up about certain things, and then added even more checks than lint ever had before. Then I looked at all the crap in the output and gradually taught lint which one's really were crap and shouldn't be issued. Now I have a version of lint with which I use four fifths of what it complains about. For instance, int i; long l; short s; char *a,*b; i=l; s=i; /* these both generate warnings */ i=(int)l; s=(short)i; /* NO warnings */ l=i<<100; /* warning */ open("file",0); /* warning */ (void)open("file",0); /* (optional) warning */ strcpy(a,b); /* NO warning */ If you assign something that is larger to something that is smaller lint warns you, but if you explicitly cast it to indicate that you know it isn't a mistake you get no warning. There is also an /*OPTRESULT*/ directive which is used like the /*VARARGS*/ directive in the function definition. strcpy() is so defined, and so lint doesn't care whether you look at its result or not. But open() is not defined with this directive, so lint does expect you to look at its return value. With things set up this way, it is almost always an error to cast any function to (void), so lint warns about this too (only as an optional summary, once per function, not per call). Too many times I've seen people try to make code lint cleanly by simply casting all the ignored function returns to (void) and by using lots of options to tell lint not to complain about certain things. Lint really can be useful. I don't know why the people who support it don't try to improve it. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0855 for JMS@ARIZMIS; Fri, 9-MAY-1986 14:08 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 15:54:40 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018079; 9 May 86 16:46 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id aa14367; 9 May 86 16:31 EDT Date: Fri, 9 May 86 16:26:01 EDT From: Doug Gwyn (VLD/VMB) To: Rob McMahon cc: info-c@BRL-SMOKE.ARPA Subject: Re: Boolean Operators Slighted in C One can define "bool" to be a variety of things, including an enumeration type, but as C was designed the result of a relational expression (for example) is an int; that's what Boolean data in C really "is". Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1185 for JMS@ARIZMIS; Fri, 9-MAY-1986 14:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 16:30:37 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005113; 9 May 86 10:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a001865; 9 May 86 10:00 EDT From: Greg Noel Newsgroups: net.lang.c Subject: Re: C Builtin Functions Message-ID: <479@ncr-sd.UUCP> Date: 8 May 86 03:46:03 GMT To: info-c@BRL-SMOKE.ARPA I'm surprised that with all this discussion on built-ins, nobody has pointed out how the C standard specifies that it should work. My copy of the standard is pretty old and has been stolen, so perhaps it was removed in a later specification? In article <788@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <1700010@umn-cs.UUCP> umn-cs!herndon writes: >>I feel compelled to go on record as being VERY MUCH AGAINST having reserved >>procedure names in C. ...... >>One of the (in my opinion) great strengths of the C language is that it >>does not have 'built-in' functions. > >After rethinking this question, I've decided that it *does*. However, the >builtins are all punctuation ("%"), whereas the library functions are all >alphanumeric ("abs"). > ....... >Here's my opinion. Using punctuation for builtins (and alphanumerics for >library functions) is a nice way to keep them straight; let's keep it that >way. If certain functions are so trivial that it's worthwhile for them to >be expanded inline (are there any besides abs(), min(), and max()?), then >they should have non-alphanumeric spellings; i.e. they should be operators. No, what the standard does (did?) is reserve all names that begin with one or two underscores. There is some difference in meaning between the two, but it's not important here. Pick one of these names, say, __OPEN, and build it in to the compiler (i.e., it produces in-line code). Then you simply act as if there were an implicit "#define open __OPEN" at the head of each program so that under normal circumstances the built-in version is used. If you want to provide your own "open" routine, all you have to do is have an "#undef open" in your program and the external semantics we all know and love are used instead. This seems to solve both of your needs without turning C into APL. If this technique is still in the standard, this debate is moot. If it's not, then I, for one, would like to know why it was removed. Aside: I think that all of the machine-specific names should be in a file somewhere and the preprocessor should implicitly read it, as if there were a "#include " (or equivalent) as the first line of every program. This would have the #defines for the machine, architecture, OS, and whatever else it takes to describe the environment. The header for the standalone environment simply wouldn't have the #defines for whichever syscalls are built-in (like __OPEN above) but might have #defines for, say, abs, l3tol/lto3l, or memcpy if it made sense. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1283 for JMS@ARIZMIS; Fri, 9-MAY-1986 15:04 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 16:42:04 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005947; 9 May 86 10:35 EDT Received: from USENET by SMOKE.BRL.ARPA id a002247; 9 May 86 10:10 EDT From: Steve Schlaifer x3171 156/224 Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <778@jplgodo.UUCP> Date: 6 May 86 17:01:38 GMT To: info-c@BRL-SMOKE.ARPA In article <256@valid.UUCP>, gelfand@valid.UUCP (Brooks Gelfand) writes: > > I have been programming for many years (over 20) in many different > languages, and C is the only language that I can remember that > has a separate program (lint) to find and report compiler errors in > source code. All of the other languages I have used have this function > built into the compiler. Perhaps because UNIX is a programmers > system rather than a production system this was felt to be unnecessary. > In most production systems the programs spend more time executing than > compiling; while in a development system most of the time is spent editing > and compiling. Thus running lint each time would add to the load > on the system. Actually, having lint be a seperate program fits nicely with the original software tools philosophy of unix. That is, a program should do one thing and do it well. A compiler within this philosophy should compile whatever you give it so long as it can make sense of it. A seperate tool (lint in this case) should exist to point out things that you are doing which are questionable. The idea here is that the programs are then simpler to build, maintain and debug since they each have a simpler function to perform. For a better discussion of this than I can give see the AT&T Bell Laboratories Technical Journal of October 1984 (Vol 63, No. 8, Part 2) article by R. Pike and B. W. Kernighan (Program Design in the Unix Environment). -- ...smeagol\ Steve Schlaifer ......wlbr->!jplgodo!steve Advance Projects Group, Jet Propulsion Labs ....group3/ 4800 Oak Grove Drive, M/S 156/204 Pasadena, California, 91109 +1 818 354 3171 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1551 for JMS@ARIZMIS; Fri, 9-MAY-1986 15:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007073; 9 May 86 10:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a002588; 9 May 86 10:19 EDT From: Eric Black Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <250@chronon.chronon.UUCP> Date: 8 May 86 17:31:00 GMT Keywords: Taking address of register Xref: seismo net.lang.c:9090 net.unix-wizards:18110 To: info-c@BRL-SMOKE.ARPA Yes, this is slightly to the side of the original question as to whether it is POSSIBLE to write a varargs() handler (a la 4.2 manpage) for any given machine architecture, but the discussion is legitimately moving around that target... In article <2694@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <236@chronon.chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >>In article <129@drilex.UUCP> dricej@drilex.UUCP writes: >>>rb@ccird2 (Rex Ballard) wonders what kind of systems would not be able to >>>handle varargs. ... >>>... Therefore, a more proper question would be: is there any >>>architecture which is suitable for a C compiler, but not for varargs? [I guess I answered a slightly different question here:] >>Yes! I can think of an example close to home... An architecture with >>a large (LARGE) number of registers, a sliding window to allow reference >> [... description of register stack machine ...] >>I assert that this architecture, and the rest of what goes with this >>particular feature, is particularly well-suited for efficient execution >>of programs written in C. >> >I agree with your assertion. If this machine supports pointers to registers, >you could write a varargs. va_arg() would have to bump a pointer to the last >register arg to a pointer to memory, maybe by calling a 'va_bump' function. >If it doesn't support pointers to register args, then it is in a bit of >trouble with C because this is supposed to be legal: > > f(a) int a; > { wombat(&a); > } >-- Yup. This is legal, and is permitted. This machine DOES allow you to take the address of a register, but it's an expensive feature to support, and we'd like to get rid of it. Other systems take care of this at the compiler level, and it crops up with register variables, not just arguments -- if you take the address of a variable, it can't reside in a register, but must be copied into memory. Possible aliasing with pointer arithmetic gets quite hairy, but that's a dangerous [and generally non-portable] thing to do in an undisciplined manner. This brings me back to my point (sort of). This is the same problem that other machines have with register variables and getting at them in two different ways (by name and at the other end of a pointer). In the case of varargs, the "by name" is as a formal parameter, the pointer is the usual varargs method. Accessing varargs directly is just as sloppy as doing something like this: foo() { int a, b, *intp; intp = &a; *intp = 1; /* set a to 1 */ intp++; *intp = 2; /* of course, this sets b to 2, doesn't it? */ } If you think this is good coding practice, I don't want you working for me! If you object to this technique, why is direct accessing of varargs items OK? Again, I realize this is not answering the precise question in the original posting, but it's worth discussing. Thanks for putting up with me... -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1417 for JMS@ARIZMIS; Fri, 9-MAY-1986 15:29 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 16:54:40 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006236; 9 May 86 10:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a002454; 9 May 86 10:15 EDT From: Steven Brian McKechnie Sargent Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <268@valid.UUCP> Date: 8 May 86 11:39:00 GMT To: info-c@BRL-SMOKE.ARPA This group has lately been besieged with a variety of odd C features, namely * boolean operators and data types * builtin functions * New operators like "< =" * Arguments passed in registers All these have the same effect of reducing simplicity for doubtful gain. ** A Boolean data type distinct from integers clutters the language with another (moderately useless) type and removes handy idioms like foo[x == 0] = bar; (Vide the "enum" type, which doesn't participate in address arithemtic either.) Arguments that boolean functions make for more efficient implementations are pretty puny: > o A function returning a bool could be implemented on some machines by > setting the condition codes instead of storing a full integer value in > the return register. If the caller wants to use the result of the function as a value, rather than as input to a branching decision, then it must write branches anyway to set the value appropriately. Result: bigger slower code. > >o Multiple flag variables with local scope and no address operator (e.g. > > variables declared "register bool") could be packed into a single word. Last I checked, (flags&BOOLEAN_VALUE_OF_MERIT) did what you want. Packing and unpacking don't come for free, in space or time. ** Builtin functions confuse language implementation with programming environment implementation; C lives in enough different environments that this is just plain bad planning. "Inline functions," a la those of C++, are another matter entirely (although they have been mentioned repeatedly in discussions of builtin functions). The benefits that inline functions offer over CPP macros are: simpler cleaner syntax, more flexibility because they admit arbitrary control structure within, and avoidance of horrible botches like putchar(*p++). The disadvantage, at least in my mind, is uncertainty as to what happens to the free variables of an inline function. Are they bound lexically where the inline is declared, or are they bound at the point where the inline is used, assuming the nearest enclosing scope? Consider: int oddval; // Not odd, as in = 1 (mod 2), but "odd" inline max(x, y) { ++oddval; return (x > y)? x: y; } foo(oddval) { int n = max(oddval, 0); oddval = max(4, oddval); return max(oddval, oddval); } bar(x) { ... return max(x, 4); } The question that leaps to mind is "what the hell does this code hope to achieve?" You can of course write just as silly code using the C preprocessor; but then the question becomes: Why provide redundant ways to write this unsafely? ** New operators like "< =", in addition to being hard to spell and understand, facilitate usages that just aren't that common. I hardly ever want to say x = (x < y), and I don't mind typing the extra characters. I'm not interested in paying compiler vendors money for supporting this (or any other dubious misfeature pounded into the language for "completeness' sake.") ** There's also been a discussion about arguments passed in registers, with one fellow (sorry I forget the name) noting that "microcomputer people pass arguments in registers." Well, big computer people do the same thing, and in both cases the disease is one of not thinking through to the consequences of your actions. Suppose you pass arguments in registers. Well, if you're like me, you have a lot of variables in registers. So in order to pass your arguments, you have to save those registers somewhere. Where do you do it? Put them on the stack, of course. Well, suppose that you "know" that %3 and %4 are reserved for parameter passing: then those registers are unavailable to the caller, whose code gets correspondingly bigger and slower. Well, suppose you're keeping the arguments in %3 and %4, and the callee can use them "in place" because caller and callee have agreed to do that (in order to avoid the overhead of explicit parameter moving). Now, you're writing spaghetti code, full of "special" communication among routines, with all the attendant side effects and untraceable bugs. And why for? The speed gain from non-standard calling sequences seems marginal at best: one recent posting discussed at great length the most efficient way to present arguments to the UNIX open(2) call -- which executes hundreds or thousands of instructions inside namei, involving perhaps multiple waits for the disk in order to fetch the inode for the file! Put the arguments on a linked list of bit-wide elements and force the kernel to chase them down, if you want: it won't make much of a difference in how fast your programs run. ** It's lots of fun to talk about wonderful "features" we'd like to see, but somebody (ANSI?) might be listening and do something about it. So, for my $.02 worth: * Always strive to separate language from libraries, libraries from host environment, and host environment from development environment. These are all separate entities; make their interactions as clean as possible. * Keep implementations simple. This means: eschew oddball calling sequences that are hard for debuggers to follow. This means: minimize the number of compile-time options -- the user needs to determine the meaning of his program from the source code; don't confuse the process by throwing in options that invisibly change this meaning. * Be EXTREMELY conservative about adding features. I have yet to see a feature proposed that fixes a crippling problem of the language. Quite the opposite: many proposed features, such as unary + to denote evaluation ordering, help a min- ority of users while making the language more baroque for everybody. I do go on, don't I? Oh, well; enjoy, flame back, or whatever. Blessed be, S. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1862 for JMS@ARIZMIS; Fri, 9-MAY-1986 15:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 17:34:18 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007374; 9 May 86 11:00 EDT Received: from USENET by SMOKE.BRL.ARPA id a003296; 9 May 86 10:35 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <2713@utcsri.UUCP> Date: 6 May 86 14:45:14 GMT Keywords: :-) To: info-c@BRL-SMOKE.ARPA In <183@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >... I'm not dumb, but trying to learn a debug a big program though >a 24-line window and my memory just doesn't make it... > Get EMACS. -- "Canabee be said2b or not2b anin tire b, if half thabee isnotabee, due2 somain chunt injury?" - Eric's Dilemma ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1747 for JMS@ARIZMIS; Fri, 9-MAY-1986 15:50 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007200; 9 May 86 10:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a002645; 9 May 86 10:20 EDT From: Wendy Thrash Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C (Really arguments in registers) Message-ID: <357@pyramid.UUCP> Date: 8 May 86 18:30:20 GMT To: info-c@BRL-SMOKE.ARPA WARNING: This article discusses compiler issues, not specifically C language issues. In article <268@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: >* Arguments passed in registers... >... have the same effect of reducing simplicity for doubtful gain. I don't want to quote too much of the original article -- it was rather long. The thrust of it was that passing parameters in registers doesn't make things run faster. This does not fit with my experience. When we implemented parameter passing in registers at Zilog, it was a big win. The argument that register variables must be pushed on the stack in order to pass parameters in registers seems tenuous. If you have only one set of registers available for variables, you have to save them sometime, unless the routine you are calling has no register variables itself. More commonly, registers used for parameter passing are not used for register variables; they may be used for temporaries. It is true that this may cut down on the number of available registers, but our work showed that we had enough registers remaining to allow good code generation for most programs. We did, indeed, allow the callee to use its arguments in place. Mr. Sargent's statements about "spaghetti code" make no sense at all to me -- this was a COMPILER; it was designed to produce efficient assembly language, not readable assembly language. When the compiler functioned correctly (as it usually did) there were no "attendant side effects and untraceable bugs." I will admit that this parameter passing caused difficulties. In particular, varargs code was messy, and debuggers more difficult to implement. Was it worth it? I believe so. Our emphasis was on speed, and that we had. Of course, this is all moot on RISC machines with sliding register windows. The concept of parameter passing in registers is then wired into the architecture, and there are plenty of registers left for register variables. --- Disclaimer: My opinions have obviously been influenced by the parameter passing in registers of my former employer (Zilog) and the sliding windows of my current employer (Pyramid). -- Wendy Thrash {allegra,cmcl2,decwrl,hplabs,topaz,ut-sally}!pyramid!wendyt Pyramid Technology Corp, Mountain View, CA +1 415 965 7200 ext. 3001 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1953 for JMS@ARIZMIS; Fri, 9-MAY-1986 16:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 17:42:54 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007424; 9 May 86 11:01 EDT Received: from USENET by SMOKE.BRL.ARPA id a003301; 9 May 86 10:36 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Infinite loops Message-ID: <2717@utcsri.UUCP> Date: 6 May 86 15:27:45 GMT To: info-c@BRL-SMOKE.ARPA In article <203@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie ) writes: >In article <390@hadron.UUCP>, jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >> >> Unfortunately, as I'm sure many readers of this group will agree, >> not all compilers are reasonable. The only one that consistently >> doesn't generate useless code is for (;;) {...}. >Joe, it is exactly this second guessing of compilers that get people in >trouble. It is bad to make sweeping statements as to what is more efficient >because some compilers just do entirely unexpected, yet no more inefficient >things with code generation. ... >Wait until the compiler comes out that does the following: > > for(;;) { included code ) > > L1: NOP / init > L2: NOP / test > INCLUDED CODE > NOP / increment > JUMP L2 > Well, it's even worse... Consider C/80, a subset C compiler for 8080's [ no floats, longs, structs, unions, **s, :-( ]: for( e1;e2; e3 ){ becomes f0: JZ f3 JMP f2 f1: JMP f0 f2: JMP f1 f3: So for(;;) just reduces to f0: JMP f2 f1: JMP f0 f2: JMP f1 Really! The compiler apparently cannot save until later; it doesn't build trees. It also pushes function args left-to-right ( another story ). while(1), on the other hand, becomes w0: LXI H,1 ; evaluate 1 ( in 16-bit reg HL ) MOV A,H ; test HL by ORing the upper ORA L ; and lower bytes to the ACC JZ w1 ; ( standard 8080 idiom ) JMP w0 w1: >Frankly, if your compiler is so bad that it can't perform routine constant >elimination, than I doubt that you will really notice the extra performance >loss. It's probably still multiplying out 60*60 for seconds in an hour >and other definitions. C/80 is ( using a 'mult' subroutine, of course. a Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <6658@utzoo.UUCP> Date: 6 May 86 19:04:18 GMT To: info-c@BRL-SMOKE.ARPA > One of the better things to come out of the COBOL standards efforts > was the notion of specifying a minimum core language, then defining > optional modules that were pretty close to the way the big boys (IBM) > had actually implemented their extensions... Whether this is a good idea or not is very much a matter of opinion. As I recall, X3J11 representatives said at the very beginning that they had explicitly renounced this approach, because there are something like 4096 distinct languages that meet the COBOL "standard", and this is a real obstacle to portability. In practice, of course, what happens is that implementations converge on a few widely-agreed preferred points in this large space of possibilities. So why not identify those points in advance? Maybe one could even... pick just one of them! This is what X3J11 is trying to do, although it looks like it's ending up as 1.5 rather than 1.0. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4438 for JMS@ARIZMIS; Fri, 9-MAY-1986 21:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/09/86 at 22:50:26 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007552; 9 May 86 11:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a003413; 9 May 86 10:38 EDT From: Mark DeWitt Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <7706@cca.UUCP> Date: 7 May 86 14:34:37 GMT To: info-c@BRL-SMOKE.ARPA In article <> garys@bunkerb.UUCP (Gary M. Samuelson) writes: >In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes: >>In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >>>After three years of C programming I'm just starting to use lint, so >>>please no negative reinforcement by flaming about how stupid my questions >>>are, lest I give up on it entirely :-). > >>Mark, I'm not flaming you, but I *am* worried!... > >And well you should be. I would like to thank the above and other contributors who have kept this discussion on a non-judgmental, rational plane. I would also like to point out that there is more than one way to learn portable coding style. Using lint and avoiding the messages it produces is one way. Having to (gasp!) port other people's code yourself is another way. Of my first six months of C programming, a good four months were spent porting "working" C code from the IBM PC to the Apple II+ / IIe, including graphics and floating point applications. Blech! It was painful, but I sure as hell learned a lot of what NOT to do if you want to write portable code. Most of my trouble with lint has not been with having to change my coding style, only with getting it to shut up. -- "We like your attitude, but what are you doing?" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4595 for JMS@ARIZMIS; Fri, 9-MAY-1986 21:19 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a019055; 9 May 86 20:21 EDT Received: from USENET by SMOKE.BRL.ARPA id a016118; 9 May 86 19:45 EDT From: #Bill_Stewart Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <674@ho95e.UUCP> Date: 8 May 86 02:22:43 GMT To: info-c@BRL-SMOKE.ARPA In article <183@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >One of the more traumatic things about being exposed to unix after working >with numerous other systems was that the stupid c compiler refused to give me >a nice clean listing with source, interspersed error messages, and optional >object code. I'm not dumb, but trying to learn a debug a big program though >a 24-line window and my memory just doesn't make it... One of the more traumatic things about programming an IBM System-34 in RPG2 was that you got the listing whether you liked it or not. We had the slow printer, so my 10-page program took 45 minutes to compile, including cross-references, overlay maps, .... If we'd had the fast printer it would have taken about 20. Then we got the box of cheap paper which jammed the printer a lot, and I almost wanted my keypunch back..... (The system 34 was a desk-sized beast with 48K of core and a 13 Meg disk. Can you say "wimp!"?) If you get a fancy enough emacs package, you can have your C listing on-screen; otherwise you'll have to use somebody's pretty-printer, and hack in error message support. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4505 for JMS@ARIZMIS; Fri, 9-MAY-1986 21:24 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018169; 9 May 86 17:08 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a014633; 9 May 86 16:52 EDT Date: Fri, 9 May 86 16:46:38 EDT From: Doug Gwyn (VLD/VMB) To: Steven Brian McKechnie Sargent cc: info-c@BRL-SMOKE.ARPA Subject: Re: Boolean Operators Slighted in C Steven Brian McKechnie Sargent says ("> ..."): > A Boolean data type distinct from integers clutters the language with > another (moderately useless) type and removes handy idioms like > foo[x == 0] = bar; Boolean quantities form an important abstract data type distinct from counters, sets, real numbers, etc. By not making the distinction, the language encourages usage errors, the most notorious being if ( a = b ) stuff; Sure, one can make integers do double (or triple, or ...) duty, but by now every programmer should realize the value of data abstraction. > New operators like "< =", in addition to being hard to spell and understand, > facilitate usages that just aren't that common. I hardly ever want to > say x = (x < y), and I don't mind typing the extra characters. I'm not > interested in paying compiler vendors money for supporting this (or any > other dubious misfeature pounded into the language for "completeness' > sake.") Here is an example where proper use of Boolean data would be violated. A statement like x = x < y; should NEVER be used, since it assigns a Boolean result to an arithmetic variable. This means that a "< =" operator is not a good idea. I find data abstraction to be a Good Thing, and have produced much better code since defining a Boolean data type and using it in a strictly type-correct manner. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9700 for JMS@ARIZMIS; Sat, 10-MAY-1986 06:49 MST Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 05/10/86 at 08:32:28 CDT Received: from yale.ARPA (YALE-VENUS.ARPA.#Internet) by SRI-KL.ARPA with TCP; Thu 8 May 86 09:15:24-PDT Date: 8 MAY 1986 12:13:50 EST From: To: MANSFIELD%DHDEMBL5.BITNET@WISCVM.WISC.EDU cc: info-vax@sri-kl.arpa Subject: Re: Problem with C and Link Reply-To: File T.C contains: | File T2.C contains: | extern char *sto; | char sto[100] = 0; main() | f(s) { f("bongo"); | char *s; printf("%s\n", sto); | { strcpy(sto, s); } | printf("in func, sto = %s\n",sto); | } [Compiling T and T2, linking with the shareable VAX C library, and running the result produces:] in func, sto is bongo %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=676E6F62, PC=0000423B, PSL=0BC00005 ...[traceback information] [The author goes on to blame the linker for incorrectly resolving the references to sto.] One of the first thing I always teach students is: Before you start blaming the compiler, the operating system, the hardware - and before you blast your question at hundreds of people on INFO-VAX - do make sure that you've checked your program, and your understanding of your programming language, for bugs. The C compiler and linker are behaving exactly as they should; your program is incorrect. extern char *sto; declares that sto, storage for which is allocated elsewhere, contains a (4-byte) address that POINTS TO some memory that contains a single character. char sto[100] = 0; allocates a hundred bytes of memory filled with zero's - actually, the "=0" is a no-op - and declares that sto IS the address of those hundred bytes of memory. printf("%s\n", sto); takes the first four of those hundred bytes - which now contain the byte codes 'b', 'o', 'n', 'g', or hex 62, 6F, 6E, 67; see the virtual address in the error message, and keep in mind that the VAX orders bytes in a word from least to most significant - and interprets them as the address of a character. This does nothing particularly useful. char *x and char x[] are VERY DIFFERENT THINGS. The ONLY context in which they are the same is the declaration of formal parameters. The "equivalence" of these two forms is a widely-made misreading of some unfortunate comments in K&R. K&R is absolutely correct in what it says, but the emphasis misleads many people. -- Jerry ------- Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0066 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:13 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 19:34:07 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000990; 11 May 86 20:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a003515; 11 May 86 19:57 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: C builtin functions? Message-ID: <802@bentley.UUCP> Date: 9 May 86 13:50:55 GMT To: info-c@BRL-SMOKE.ARPA In article <716@steinmetz.UUCP> steinmetz!davidsen (Davidsen) writes: >At that point, given that we were talking about an "advisory" keyword, >and that obviously you couldn't take the address of an intrinsic >function, one of us suggested that the term "register" be used, since >it may be ignored by the compiler, and prevents taking the address of a >variable. I thought of that too! However, I think the meaning is sufficiently different from a register variable that it's better to use a new keyword. >register foo() { ... } >register foo(); You seem to be using the former to mean "inline" and the latter to mean "builtin". These are not the same concept! Also, why should the user have to know which functions are (or might be) builtins? They should be automatically recognized by the compiler unless explicitly disabled. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8877 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:13 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 16:26:29 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029696; 11 May 86 17:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a001245; 11 May 86 16:16 EDT From: Jerry Schwarz Newsgroups: net.lang.c Subject: Re: C Builtin Functions Message-ID: <1253@ulysses.UUCP> Date: 8 May 86 21:42:25 GMT To: info-c@BRL-SMOKE.ARPA > I'm surprised that with all this discussion on built-ins, nobody has pointed > out how the C standard specifies that it should work. My copy of the standard > is pretty old and has been stolen, so perhaps it was removed in a later > specification? > It was about the 3rd item posted in the discussion. But here it is again (Februray 1986 draft) D.1.2 Headers ... All external identifiers declared in any of the headers [i.e. as specified in the standard] are reserved, whether or not the associated header is included. All external identifiers and macro names that begin with an underscore are also reserved. If the program redefines a reserved external identifier, even with a semantically equivalent form the behavior is implementation defined. ... D.1.3 Use of library functions ... Any function declared in a header may be implemented as a macro defined in the header, so a library function should not be declared explicitly if its header is included. ... The use of #undef to remove any macro definition will also ensure that an actual function is referenced. To me this seems perfectly reasonable. Note in particular that a vendor is required to tell you what will happen if you try to redefine one of the reserved identifiers. Jerry Schwarz Bell Labs, MH ulysses!jss Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0027 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 19:31:20 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000988; 11 May 86 20:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a003420; 11 May 86 19:54 EDT From: KW Heuer Newsgroups: net.lang.c,net.lang.c++ Subject: Re: oops, corrupted memory again! Message-ID: <801@bentley.UUCP> Date: 9 May 86 13:39:03 GMT Xref: brl-sem net.lang.c:994 net.lang.c++:183 To: info-c@BRL-SMOKE.ARPA In article <5097@think.ARPA> rose@think.ARPA (John Rose) writes: >If you do have source code, here's another suggestion which has worked >very well for me. Define an circular buffer which stores a record of >the last few hundred records of malloc/free/morecore history. Make >sure your symbolic debugger can dump it for you. This trick alone >has saved me hours of debugging time on quite a few occasions. I've found the following front-end* to be very useful: char *Dalloc(n) unsigned n; { register char *p = malloc(n); fprintf(stderr, "+%8x\n", p); return (p); } void Dfree(p) char *p; { fprintf(stderr, "-%8x\n", p); free(p); } char *Drealloc(p, n) char *p; unsigned n; { fprintf(stderr, "-%8x\n", p); p = realloc(p, n); fprintf(stderr, "+%8x\n", p); return (p); } When the program terminates (normal exit or core dump), I run a consistency check on the log file to cancel out "+xxx" and "-xxx". Any unbalanced "-" is a bug. I consider an unbalanced "+" to be a bug, too, unless there are a bounded number of them and I can account for them all. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint *It can also be built into malloc.c if you have source; this allows it to log the calls within stdio. For some applications, a special log file should be used instead of stderr. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9825 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 19:15:29 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000974; 11 May 86 20:03 EDT Received: from USENET by SMOKE.BRL.ARPA id a003183; 11 May 86 19:46 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: A good use of a bad feature Message-ID: <800@bentley.UUCP> Date: 9 May 86 04:18:07 GMT To: info-c@BRL-SMOKE.ARPA In article <528@brl-smoke.ARPA> root@icst-cmr ((Root Boy) Jim Cottrell) writes: [concerning the fall-through case feature] >You will find much disagreement on that point, I'm afraid. Fall thru is >more flexible. You can always break, but often cases are related so that >a particular case requires a superset of another case. It is to DMR's >credit that he realized this feature. I sure wouldn't have thought of it. An alternate implementation would have been for cases to be distinct by default, but "continue" at the bottom of a case would cause a fall-thru. (In this model, "break" would be meaningless inside a switch and "continue" would be meaningful, instead of the opposite.) Given that most use of the switch statement *does* have distinct cases, and the exceptions are often explicitly labeled /* no break */, I think this would've been better. (I would *almost* accept a model with automatic break and no keyword for fall-thru, and suffer the occasional goto.) One special instance is where the superset is actually an equivalence, i.e. two or more labels on the same code: case ' ': case '\t': case '\n': white(); break; This would be ugly with the auto-break model, but the solution is to allow case ' ','\t','\n': white(); which I think looks neater anyway. (Btw, I find case '0': ... case '9': digit(); annoyingly verbose in the current model, and often use "if" rather than "switch" because of it.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0187 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 19:54:48 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001020; 11 May 86 20:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a003179; 11 May 86 19:45 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: More on BOOLEAN vs. boolean Message-ID: <799@bentley.UUCP> Date: 9 May 86 03:57:05 GMT To: info-c@BRL-SMOKE.ARPA In article <559@brl-smoke.ARPA> HARGED%ti-eg.csnet@CSNET-RELAY.ARPA writes: >>o Multiple flag variables with local scope and no address operator (e.g. >> variables declared "register bool") could be packed into a single word. > >*IF* packing bits is feasible on your host machine. (Whether you like it or >not) there are many C implementations that can't afford the overhead of bit >packing. The bits don't need to be explicitly packed and unpacked except to convert between bool and int. Otherwise a bit-test, bit-set, and bit-clear will do, I think; these are just "&", "|", and "&~", and are very common instructions. (Anyway, an implementation is free to NOT pack the bits, just as it can put a char in a 32-bit word if the alternative is too much trouble.) >>o "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--" >> would then be "test and (set|clear)". This would obviate such things as >> "if (!flag) { flag=1; printmsg(); }". > >I think the same problems with doing that now (on integers of whatever size) >would plague the boolean type. The code that would have to generated to avoid >giving a boolean variable an undefined value would probably match the size >of the code currently generated when the user explicitly controls a flag's >value. Actually, I was introducing "x++" for the user's benefit, not the machine's. I wouldn't mind if it generated the same code as in the explicit case; after all, it's only two instructions (test, followed by store-constant). However, I'd expect a machine with an efficient test-and-set instruction to use it. >However, (~x) for "toggle" would be useful. The lack of an efficient >toggle operation on integer BOOLEAN's is sometimes a pain. I see no reason to change it from "!" to "~". The only case where it's inefficient now is with "x = !x", which could indeed be optimized if "x" is known to be boolean rather than int. (Of course you can write "x ^= 1".) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8815 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 16:20:14 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029686; 11 May 86 17:07 EDT Received: from USENET by SMOKE.BRL.ARPA id a000636; 11 May 86 12:26 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <797@bentley.UUCP> Date: 9 May 86 02:54:50 GMT To: info-c@BRL-SMOKE.ARPA In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >I have ranted about C using a one statement model for its control >statements instead of an explicit end statement. Compound statements are >bounded by braces instead. Yuk! Ah yes, there are two major types of language in the structured family; f77 with "endif" (some members use "end" for all of "endif", "endwhile", etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I presume this is what you dislike. (If it's the spelling that bothers you, I'm sure you're aware that you can define "begin" and "end" as macros.) Yet another convention, not endorsed by any language I know, is to dispense with the braces and let the indentation alone tell the compiler how to interpret the program. (I came up with this idea after an argument on the "correct" place to put the braces.) >Fortunately, there is the comma operator. This allows the following: > Most People Your's Truly > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ I can hardly flame you for this, since I've used it myself when in a hurry. (But I write it on one line, "if (c) w=x, y=z"). I usually end up rewriting it with braces, though. >Other things you will see in my code are: > exit((printf("usage: foo bar\n"),1)); >or even: exit(1,printf("usage: foo bar\n")); What's wrong with printf("usage: foo bar\n"), exit(1); as above? >Sufficeth to say that I use a lot of commas in my code. Unfortunately, >I cannot do this if either statement is a control struxure, *except* return. > Most People Your's Truly > if (c) { if (c) > w = y; return w = x, > return; > } /* look ma, no brace */ You're introducing a minor inefficiency, since the compiler will have to copy the result of the last expression into the return register. I presume you don't bother to declare void functions "void", either, or this wouldn't make it past the compiler. >I cannot see *any* implementation doing either of the following: > 1) barfing because I returned an *extra* value sometimes > 2) barfing because I added an extra argument You're probably correct in that all implementations that accept your code will produce correct results; however, I can easily imagine a compiler that would refuse to compile such an "obvious bug". >Now you may claim that this is `bad programming practice', but I claim >that it is just a convention, just like #defines are usually capitalized. >You may not like either one, but I claim this is portable. And, it is >meaningful to me. But it *is* bad practice, in a measurable sense: you are using a style which is indistinguishable from a bug. As a result, you cannot easily use lint to find *real* bugs, because you've introduced so much noise in the lint output. You're throwing away a useful tool unnecessarily. >I find it terribly ugly having to cast printf's or close's to void. Me too. But let's not lump all the cases together: [0] strcpy() returns a value that can be safely ignored. (Although I often find that I can use it in the next statement anyway.) [1] printf() returns a number which is normally pretty useless. It does also have an error return, but if you're writing to the terminal it's pretty safe to ignore that too. (Especially fprintf(stderr). What can you do if it fails, print an error message?) [2] close(), as near as I can tell, can only fail by being handed a number that does not denote an open file. I usually assume that this error would have been caught earlier. [3] unlink() and most other system calls should be checked! (It's too bad lint can't tell whether you've tested the return value of open(), etc.) My "solution" for [0]-[2] is simply to check the bottom of the lint output for "result ignored" messages, and decide which ones are serious. ("lint returns an error which is always ignored" :-) >And as someone pointed out, assignments return a value too, so should we >cast them to void as well? Oh yeah, assignment is `different'. Actually, this does bother me somewhat. I think I prefer the idea that values should be used or explicitly discarded, as in forth. (Not that forth has any error checking!) No, I'm not suggesting that lint should complain about assignments, or that C should have a different notation for assignments that are being pipelined into another expression. Just waiting for the next generation of languages. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8732 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 16:07:23 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029531; 11 May 86 16:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a000608; 11 May 86 12:18 EDT From: Landon Noll Newsgroups: net.lang.c Subject: 1984 winners Message-ID: <3551@nsc.UUCP> Date: 9 May 86 00:27:49 GMT Keywords: obfuscate,1984,winners To: info-c@BRL-SMOKE.ARPA A number of people have requested the winners from two years ago. *sigh* O.K. folks, here it is once again. Grab it now because it would be sent out for a while... BTW, the 1986 contest ends 30-May. Send in your programs now... 1984 awards: honorable mention: ------------------------------------------------------------------------------ int i;main(){for(;i["]>1) ;for(h= 0;h*h<= g;++h); --h;c=( (h+=g>h *(h+1)) -1)>>1; while(d <=g){ ++O;for (f=0;f< O&&d<=g ;++f)a[ b<<5|c] =d++,b+ =e;for( f=0;f Second place award: --------------------------------------------------------------------------- #define x = #define double(a,b) int #define char k['a'] #define union static struct extern int floor; double (x1, y1) b, char x {sizeof( double(%s,%D)(*)()) ,}; struct tag{int x0,*xO;} *main(i, dup, signal) { { for(signal=0;*k * x * __FILE__ *i;) do { (printf(&*"'\",x); /*\n\\", (*((double(tag,u)(*)())&floor))(i))); goto _0; _O: while (!(char < xO));/*} ; } */}}} ------------------------------------------------------------------------------- By: Dave Decot hplabs!hpda!hpdsd!decot First place award goes to: ------------------------------------------------------------------------ /* Portable between VAX11 && PDP11 */ short main[] = { 277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800, -113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004, 14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9, 4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419, 0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0, 4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#', 0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712, 'p', 072163, 'r', 29303, 29801, 'e' }; ------------------------------------------------------------------------------ Sjoerd Mullender Robbert van Renesse Both @ Vrije Universiteit, Amsterdam, the Netherlands. ..!decvax!mcvax!vu44!{sjoerd,cogito} chongo <> /\oo/\ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0440 for JMS@ARIZMIS; Sun, 11-MAY-1986 18:31 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/11/86 at 20:07:17 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001037; 11 May 86 20:32 EDT Received: from USENET by SMOKE.BRL.ARPA id a003976; 11 May 86 20:17 EDT From: Rex Ballard Newsgroups: net.lang.c Subject: LINT as documentation Message-ID: <411@ccird1.UUCP> Date: 9 May 86 19:16:40 GMT To: info-c@BRL-SMOKE.ARPA This is just one more argument for lint. True, lint often burps over "trivial" little problems like passing a *int to a function that expects *char, among others, but there are some real good reasons for using lint. Frequently, after working on a project for several months and coming up with a working system, it gets passed to someone else. That someone else then has to make a small enhancement that affects only one module out of 100. This second person might not understand that this *int is not really a pointer to integers, but is in fact a pointer to some more complex type. By putting the casts, VARARGS, NOSTRICTS, et al, the new guy at least gets a warning that something is not what it appears to be. This is particularly important if I do something like us an int as a pointer to char (yuckkk!!! :-). Now, if either he or I induce a new bug, or something that might need explanation, lint is there finding that "1/5" of the wierdness that might have gone wrong. Even more important is when we switch compilers, go to cross-tools, or use some other change in the environment. If the thing has been linted, casted, and cleaned up, we can ASK it to tell us about "dubious casts", or whatever and have a better idea of why things don't work as well. When someone comes up with the "lint cramps my style" arguments, I tend to get worried. When I get handed some code that has to be "ported" or enhanced, I run lint on it before I do anything. If lint goes crazy, I know I will have to read ALL of the code before I can do anything. There are a lot of cute "tricks" you can do with C, like setting "pointers" that are really integers. But if you want to do this, you should be explicit in defining "(char *)0x2300ffff". Believe it or not, I have actually seen code that legitimately calls address location 0 (useful on the 8085). This is guarenteed to drive a programmer crazy if he tries to port this to another machine. I also expect a programmer to run code through lint before he gets my help. I have spent too many hours with people who insist the compiler is broken because they have tried to, in effect, build an array in the operating system vector space :-). If he really WANTS to build an array in the operating system vector space, he should SAY SO, not just to me, but to lint. I find it amazing that an employer would pay a programmer for three days worth of debugging using ODT (octal debugging toy) to test and debug code when all but one hours worth could be found in a 2 hour session of lint/vi. Real Programmers CAN use the "front panal", but they won't if there is a faster easier way! If you are programming on your own time, and don't have any plans for releasing your code to anyone, then don't use lint. But if you want to "publish" your little gem, the $95 for lint on a "PC" will easily offset the $20/hr*20 or thirty hours someone might spend getting it to run on their "not quite compatible". This is especially true on 68K machines where Ints can be short and pointers can be long and (*char)i can do some really nasty things. Sure it's possible to use the "long int switch", but then the program runs 150% slower. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5483 for JMS@ARIZMIS; Wed, 14-MAY-1986 02:31 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008766; 13 May 86 21:18 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a014489; 13 May 86 20:17 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA01366; Tue, 13 May 86 20:17:10 edt Date: Tue, 13 May 86 20:17:10 edt From: Root Boy Jim Message-Id: <8605140017.AA01366@icst-cmr.ARPA> To: bentley!kwh@ICST-CMR.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: oops, corrupted memory again! > ...I consider an unbalanced "+" to be a bug, too, unless there are > a bounded number of them and I can account for them all. There always is :-) (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5380 for JMS@ARIZMIS; Wed, 14-MAY-1986 02:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/14/86 at 04:14:22 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008723; 13 May 86 20:55 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a014464; 13 May 86 20:11 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA00837; Tue, 13 May 86 20:10:16 edt Date: Tue, 13 May 86 20:10:16 edt From: Root Boy Jim Message-Id: <8605140010.AA00837@icst-cmr.ARPA> To: bentley!kwh@seismo.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint > In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > >I have ranted about C using a one statement model for its control > >statements instead of an explicit end statement. Compound statements are > >bounded by braces instead. Yuk! > > Ah yes, there are two major types of language in the structured family; > f77 with "endif" (some members use "end" for all of "endif", "endwhile", > etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I > presume this is what you dislike. (If it's the spelling that bothers you, > I'm sure you're aware that you can define "begin" and "end" as macros.) Well C certainly makes the spelling less verbose, but that is not my complaint. The first structured language I came across (SIMPL-T at U of Md) used the notation `IF THEN { ELSE } END'. This has become my personal favorite paradigm for if statements. In fact, the syntax of all control statements was almost entirely similar to that used by the Bourne shell, except that END ended any kind of block. This is superior to the `one statement' (braces, BEGIN-END, etc) style because it explicitly delimits where the else statement goes. It is also easier to parse. > Yet another convention, not endorsed by any language I know, is to dispense > with the braces and let the indentation alone tell the compiler how to > interpret the program. (I came up with this idea after an argument on the > "correct" place to put the braces.) This is too scary, even for a scofflaw like myself. I don't trust white space, and you give up the ability to `cb' or `indent' it. > >Fortunately, there is the comma operator. This allows the following: > > Most People Your's Truly > > if (c) { if (c) > > w = y; w = x, > > y = z; y = z; > > } /* look ma, no brace */ > > I can hardly flame you for this, since I've used it myself when in a hurry. > (But I write it on one line, "if (c) w=x, y=z"). I usually end up rewriting > it with braces, though. I often do myself. EMACS C-mode adds them for you automatically, so I guess it's not much of an issue for some people. > >Other things you will see in my code are: > > exit((printf("usage: foo bar\n"),1)); > >or even: exit(1,printf("usage: foo bar\n")); > > What's wrong with > printf("usage: foo bar\n"), exit(1); > as above? Oops, I goofed royally. BTW, I didn't notice that I needed the extra parens in the first example until I posted it. Another example of why not to use tricks. Silly rabbit :-) > >Sufficeth to say that I use a lot of commas in my code. Unfortunately, > >I cannot do this if either statement is a control struxure, *except* return. > > Most People Your's Truly > > if (c) { if (c) > > w = y; return w = x, > > return; > > } /* look ma, no brace */ > > You're introducing a minor inefficiency, since the compiler will have to > copy the result of the last expression into the return register. I presume > you don't bother to declare void functions "void", either, or this wouldn't > make it past the compiler. I hadn't even thought of that. In my defense I will have to mention that 1) the expression may have already been computed in R0 anyway, 2) `tis a small matter, & 3) the attempt is to optimize cranial time rather than execution time. The statements of the left side are starting to get verbose, while the ones on the right side, especially if written on one lline, are simple and to he point. It might take you a bit to get used to the convention, but it's not that difficult. As for void, it didn't exist on the compiler I first used. Even BSD has problems with pointers to functions returning voids (did I get it right?) so I avoid them. It is easier just to default it to int, never return anything (or use my convention), and ignore the value. That's right, easier, not better. I'm lazy. Generally, tho, I find that I don't make *that* kind of mistake too often, so why bother? It all comes down to what you gain versus what you put out, and have to read for all eternity. > >I cannot see *any* implementation doing either of the following: > > 1) barfing because I returned an *extra* value sometimes > > 2) barfing because I added an extra argument >> > You're probably correct in that all implementations that accept your code > will produce correct results; however, I can easily imagine a compiler that > would refuse to compile such an "obvious bug". Not true. The first case is required to be supported so that I can ignore a value (strcpy, eg) if I choose. The second is required to support printf. > >Now you may claim that this is `bad programming practice', but I claim > >that it is just a convention, just like #defines are usually capitalized. > >You may not like either one, but I claim this is portable. And, it is > >meaningful to me. > > But it *is* bad practice, in a measurable sense: you are using a style which > is indistinguishable from a bug. As a result, you cannot easily use lint to > find *real* bugs, because you've introduced so much noise in the lint output. > You're throwing away a useful tool unnecessarily. I see your point. I first ran lint after I had a few thousand lines of code written, and it barfed unmercifully. Before that, I had attempted to run it but the permission bits were set wrong for some files. Only root could run it. By the time I figured out why, I had a bad taste in my mouth. Also, reading the documentation left me unexcited. Maybe I will give it another try someday. I'll probably point it at net.sources. I find I can get along okay without it. That is my whole point. It's not lint that bothers me, it's the people that think it's a panacea for everything. Actually, I am pleased by the mixed reaction I received. About half of the articles I've seen make this point as well. I do prefer the way it fits into the language tho. It's there when you need it but not shoved down your throat by run-time or compile-time checks. > >I find it terribly ugly having to cast printf's or close's to void. > > Me too. But let's not lump all the cases together: > > [0] strcpy() returns a value that can be safely ignored. (Although I often > find that I can use it in the next statement anyway.) > > [1] printf() returns a number which is normally pretty useless. It does also > have an error return, but if you're writing to the terminal it's pretty > safe to ignore that too. (Especially fprintf(stderr). What can you do > if it fails, print an error message?) > > [2] close(), as near as I can tell, can only fail by being handed a number > that does not denote an open file. I usually assume that this error > would have been caught earlier. I meant to say `fclose', which can write data and thus barf too. > [3] unlink() and most other system calls should be checked! (It's too bad > lint can't tell whether you've tested the return value of open(), etc.) Mostly. But sometimes you don't care if the file you are trying to unlink or the descriptor you are trying to close doesn't exist. > My "solution" for [0]-[2] is simply to check the bottom of the lint output > for "result ignored" messages, and decide which ones are serious. ("lint > returns an error which is always ignored" :-) Right. Grep -v helps here too. > >And as someone pointed out, assignments return a value too, so should we > >cast them to void as well? Oh yeah, assignment is `different'. > > Actually, this does bother me somewhat. I think I prefer the idea that > values should be used or explicitly discarded, as in forth. (Not that forth > has any error checking!) No, I'm not suggesting that lint should complain > about assignments, or that C should have a different notation for assignments > that are being pipelined into another expression. Just waiting for the next > generation of languages. The explicitness comes in the source code. Why do you find it so hard to believe that I meant what I said? > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Root Boy) Jim Cottrell The Sitting Lint Maker Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5572 for JMS@ARIZMIS; Wed, 14-MAY-1986 02:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008984; 13 May 86 22:02 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a014813; 13 May 86 21:08 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA04870; Tue, 13 May 86 21:08:03 edt Date: Tue, 13 May 86 21:08:03 edt From: Root Boy Jim Message-Id: <8605140108.AA04870@icst-cmr.ARPA> To: gwyn@BRL.ARPA, sbs%valid.uucp@BRL.ARPA Subject: Re: Boolean Operators Slighted in C Cc: info-c@BRL-SMOKE.ARPA Doug Gwyn responds: Steven Brian McKechnie Sargent says ("> ..."): > A Boolean data type distinct from integers clutters the language with > another (moderately useless) type and removes handy idioms like > foo[x == 0] = bar; Boolean quantities form an important abstract data type distinct from counters, sets, real numbers, etc. By not making the distinction, the language encourages usage errors, the most notorious being if ( a = b ) stuff; True. It is easily found tho. Sure, one can make integers do double (or triple, or ...) duty, but by now every programmer should realize the value of data abstraction. Or lack of it. I find that the Boolean/Integer schism in Fortran caused me lots of headaches long ago. > New operators like "< =", in addition to being hard to spell and > understand, > facilitate usages that just aren't that common. I hardly ever want to > say x = (x < y), and I don't mind typing the extra characters. I'm not > interested in paying compiler vendors money for supporting this > (or any other dubious misfeature pounded into the language for > "completeness'sake.") Here is an example where proper use of Boolean data would be violated. A statement like x = x < y; should NEVER be used, since it assigns a Boolean result to an arithmetic variable. This means that a "< =" operator is not a good idea. Wrong you are, Doug. You have been thinking in this Boolean paradigm for so long that you are missing another Good thing. Implication! Given that P and Q are `Boolean' variables (0 or 1), the Logical Implication is described by the operator `<='. Thus, the statement `x = p <= q;' sets the `boolean' value x to a `boolean' expression. Since there are no such things as booleans :-), x, p, & q are integers. It's all a matter of interpretation. APL has no `boolean exclusive or' operator because the operator `!=' does the same thing (when given only zero's or one's). There are sixteen different boolean functions with two inputs and one output. They all fit nicely into C operators: p 0 0 1 1 q 0 1 0 1 Name Symbol --------- ---- ------ 0 0 0 0 False 0 0 0 0 1 And & 0 0 1 0 Doesn't Imply > 0 0 1 1 Alpha p 0 1 0 0 Not Implied By < 0 1 0 1 Omega q 0 1 1 0 Diff != or ^ 0 1 1 1 Or | 1 0 0 0 Nor !(p | q) 1 0 0 1 Same == 1 0 1 0 Not Omega !q 1 0 1 1 Is Implied By >= 1 1 0 0 Not Alpha !p 1 1 0 1 Implies <= 1 1 1 0 Nand !(p & q) 1 1 1 1 True 1 Neat! I never thought I'd get to use my engineering switching theory again! I find data abstraction to be a Good Thing, and have produced much better code since defining a Boolean data type and using it in a strictly type-correct manner. This fact doesn't bother people who write in APL, widely considered to be the most mathematical language. Why does it bother you? (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6034 for JMS@ARIZMIS; Wed, 14-MAY-1986 04:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/14/86 at 06:18:37 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009274; 13 May 86 23:07 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a015399; 13 May 86 22:15 EDT Date: Tue, 13 May 86 22:11:57 EDT From: Doug Gwyn (VLD/VMB) To: Root Boy Jim cc: sbs%valid.uucp@BRL.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: Boolean Operators Slighted in C Index to participants: >>> Steven Brian McKechnie Sargent >> Doug Gwyn > Jim Cottrell >>> New operators like "< =", in addition to being hard to spell and >>> understand, >>> facilitate usages that just aren't that common. I hardly ever want to >>> say x = (x < y), and I don't mind typing the extra characters. I'm not >>> interested in paying compiler vendors money for supporting this >>> (or any other dubious misfeature pounded into the language for >>> "completeness'sake.") >> >> Here is an example where proper use of Boolean data would be violated. >> A statement like >> x = x < y; >> should NEVER be used, since it assigns a Boolean result to an >> arithmetic variable. This means that a "< =" operator is not >> a good idea. > > Wrong you are, Doug. You have been thinking in this Boolean paradigm > for so long that you are missing another Good thing. Implication! > Given that P and Q are `Boolean' variables (0 or 1), the Logical > Implication is described by the operator `<='. Thus, the statement > `x = p <= q;' sets the `boolean' value x to a `boolean' expression. > Since there are no such things as booleans :-), x, p, & q are integers. > It's all a matter of interpretation. APL has no `boolean exclusive or' > operator because the operator `!=' does the same thing (when given > only zero's or one's). There are sixteen different boolean functions > with two inputs and one output. They all fit nicely into C operators: > [table omitted] Even Boole knew that Boolean operations can be performed by appropriate arithmetic on {0,1} operands; that is irrelevant. The original example, x "< =" y;, interpreted as you suggest, would mean `set x to "x is not implied by y"', if and only if x and y were Boolean in the first place. Not only is this of negligible practical value, but that meaning of the operator differs from its meaning when applied to non-Boolean values (the general case, and the one I had in mind when I argued that it was a bad idea). >> I find data abstraction to be a Good Thing, and have produced >> much better code since defining a Boolean data type and using >> it in a strictly type-correct manner. > > This fact doesn't bother people who write in APL, widely considered > to be the most mathematical language. APL doesn't offer real facilities for data abstraction. > Why does it bother you? Because as a conscientious software engineer I have to produce reliable and maintainable systems for people to use. This requires quality standards well beyond what hackers might feel to be necessary. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2148 for JMS@ARIZMIS; Fri, 16-MAY-1986 16:18 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/15/86 at 21:31:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016276; 15 May 86 21:43 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a006738; 15 May 86 21:00 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA20738; Thu, 15 May 86 21:00:59 edt Date: Thu, 15 May 86 21:00:59 edt From: Root Boy Jim Message-Id: <8605160100.AA20738@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Design Process > All too often, one sees programmers writing code before > a proper job of analysis and design has been done. I > also believe that is partly because semi-running code > makes it appear as though progress has been made, > while a complete design doesn't convey the same impression. Sorry, Doug, I can't let that one go by. Me neither. It has also been said that programs should be written twice: once to find out what the specs are, then that program should be thrown away and the job done right. TPC seems to have followed that philosophy, as System V looks nothing at all like UNIX :-) (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8362 for JMS@ARIZMIS; Fri, 16-MAY-1986 16:19 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/15/86 at 13:01:27 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021676; 14 May 86 13:58 EDT Received: from USENET by SMOKE.BRL.ARPA id a026379; 14 May 86 13:42 EDT From: Wayne Throop Newsgroups: net.lang.c Subject: "formals" and "actuals" Message-ID: <347@dg_rtp.UUCP> Date: 9 May 86 00:46:04 GMT To: info-c@BRL-SMOKE.ARPA >>Well. Sizeof is indeed peculiar. For example, >>sizeof(formal_array_name) yeilds your machine's pointer size. > > Ouch. First off (see that nit?), it took me two (admittedly > fraction-of-a-second) passes to understand that you were talking > about what sizeof yields [sp!] on an array declared as a formal > a r g u m e n t . Hmpf. I thought that the term "formal" used to mean "an argument to a function" was quite wide-spread in talking about algol-derived languages, and others besides. The value passed to a formal is normally called an "actual" or an "actual argument". Sorry about the confusion. I suppose I could have said "formal_argument_array_name". Using "formal_argument" rather than "argument" is, of course, intended to get around the ambiguity of whether I'm talking about something I'm passing to a function, or something that the function expects to be passed. Is there anybody (besides Joe) who thinks this abreviated usage ("formal" meaning "formal argument") is unclear? I'm not sure but what I'm tempted to continue using "formal" to refer to a formal argument, since it is so convenient. On the other hand, I don't want to confuse folks. > It's fairly clear that when you declare a formal > argument to a function, the C compiler coerces it from array-of-X > to pointer-to-X. You are therefore taking the size of a pointer, > and it returns the size of that pointer (which size may depend on > the type of the thing to which you are pointing). Yes, fine, wonderful, I agree, great. *BUT*. The formal was defined to be an array, by gar. It's sizeof should be array-like. Take this example, for example. void f(a,c,s,i) int a[10]; char c; short s; int i; { printf( "%d %d %d %d\n", sizeof a, sizeof c, sizeof s, sizeof i ); } void main(){ int a[10]; char c; short s; int i; f( a, c, s, i ); printf( "%d %d %d %d\n", sizeof a, sizeof c, sizeof s, sizeof i ); } This program produces the output 4 1 2 4 40 1 2 4 Now, by your theory, since "char" and "short" are promoted to int in the context of a call, it "ought to" have printed 4 4 4 4 40 1 2 4 Clearly, my way of having it print 40 1 2 4 40 1 2 4 is a smaller change to the language, and is thus preferable to yours. :-) More seriously, if one can say "f's formal is an array", the dratted thing should *behave* like an array, just like a char formal behaves like a char despite the actual being promoted to an int. Compilers do handstands now to see that char and short formals behave properly despite being transformed by the calling conventions. I think arrays should do the same. And before you say that "well, the coersion of array to pointer happens before the call", let me reply that that is irrelevant. The point is that the formal declaration is a white lie, and for some types this white lie is well hidden and for others it is not. I wish it to be equally well hidden for all types where this is possible. > As usual, this has been discussed to death in earlier articles. > If someone has a copy of my long-ish tutorial on this subject, > please send it to me. I promise not to re-post it more often than > every year or two, and flag it so you can junk it. Sadly, I don't have it. I remember it as being quite good, though. So it goes. > Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9092 for JMS@ARIZMIS; Sun, 18-MAY-1986 23:27 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 01:15:36 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000297; 19 May 86 1:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a010141; 16 May 86 5:53 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <1469@umcp-cs.UUCP> Date: 12 May 86 14:05:55 GMT To: info-c@BRL-SMOKE.ARPA In article <989@dataioDataio.UUCP>, bjorn@dataio.UUCP writes: >... I notice this (odd) fact: the compiler on the PC is better than >the one on the VAX! It's faster, it produces better code, and it >catches errors that the UNIX C does not. So I'm curious: > The state-of-the-art in compilers has progressed on PCs, > so why hasn't anyone come up with a better compiler for > UNIX, or have I just not heard of it? 1. Your company gets paid for improving your compiler. Is not that so? 2. The 4.3BSD C compiler has a number of improvements in both compilation speed and code generation. (Nothing major, just little fixes, but then *we* are *not* paid to do this sort of thing....) 3. I believe there are several optimising compilers for Vax Unix (which version(s), I do not know) on the market. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 9187 for JMS@ARIZMIS; Sun, 18-MAY-1986 23:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 01:30:11 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id ab00297; 19 May 86 1:52 EDT Received: from USENET by SMOKE.BRL.ARPA id a008371; 16 May 86 0:28 EDT From: Doug Gwyn Newsgroups: net.lang.c,net.micro.pc,net.unix-wizards Subject: Re: Varargs, portability Message-ID: <916@brl-smoke.ARPA> Date: 16 May 86 04:28:15 GMT To: info-c@BRL-SMOKE.ARPA > No, because you have exceeded the VAX's 255-byte argument limit. Oops, the VAX allows 255 longwords, not 255 bytes. Sorry! However, this is a problem to watch out for, if you pass structs by value. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9546 for JMS@ARIZMIS; Mon, 19-MAY-1986 00:50 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 02:45:41 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023343; 14 May 86 14:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a026361; 14 May 86 13:42 EDT From: Wayne Throop Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <345@dg_rtp.UUCP> Date: 8 May 86 20:36:34 GMT To: info-c@BRL-SMOKE.ARPA > jimc@ucla-cs.ARPA (Jim Carter) >> kwh@bentley.UUCP (KW Heuer) >>Btw, you can't have *all* operators extended with "=". How would you write >>"v = v < e;"? (Not that it's useful.) > I think it's useful! As written, of course, it's semantically invalid, > but what you really mean is "v <= e" (sic) or, to demonstrate where it's > really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; The point is not that it isn't useful to collapse multiple array (or other clumsy) references. The point is that in "e1 = e1 < e2", the "<" operator assumes arguments with numeric semantics and yeilds a value with boolean semantics. Since e1 is both an argument and a result, this expression isn't very meaningful. The fact that C overloads the numeric types with boolean meaning doesn't make this a useful thing to do. Interestingly, if e2 also has boolean semantics, the "e1 < e2" gives the same result as "!e1 && e2" (ignoring side effects). Doesn't seem like a primitive to clammor for in the language, nor does "<" seem like a good symbol for it if it were a primitive. Now, I know what all you hackers are saying. You're saying "But Wayne, how did you become a LOVE GOD?" (What's that? net.lang.c? Not net.panting.singles? Sorry, I mean) "But Wayne, I just don't care diddly about numeric vs boolean type safety debates. I just want something that'll WORK." Ok. Fine. But you'll probably be looking for subtle and disgusting bugs in programs that contain oddities like "e1 = e1 < e2" long after others are happily using working programs that don't. So there. -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9590 for JMS@ARIZMIS; Mon, 19-MAY-1986 00:56 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 02:48:21 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a026857; 14 May 86 19:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a003691; 14 May 86 19:41 EDT From: Svante Lindahl Newsgroups: net.lang.c Subject: Re: A good use of a bad feature Message-ID: <812@duvan.UUCP> Date: 10 May 86 04:37:24 GMT Keywords: tacky programs, algol 68 To: info-c@BRL-SMOKE.ARPA In article <1298@umcp-cs.UUCP> jim@umcp-cs.UUCP writes: >/* > * xmas.c - a program to print The Twelve Days of Christmas > * using the C fall thru case statement. > * If this wasn't my idea, I appologize to whomever I > * got the idea from, but I wrote the program 5 years > * ago and I don't remember now. [...] Sorry this isnt' C, but I can't resist posting this... though I realize this is probably not a very apropriate newsgroup. It isn't my work, but I've lost track of who wrote it. Anyway it is an amusing piece of Algol-68-code. Example of execution under the TOPS-10 OS included after the code. BEGIN PROC readint = INT: (INT i; read(i); i); INT one=1, two=2, three=3, four=4, five=5, six=6, seven=7, eight=8, nine=9, ten=10, eleven=11, twelve=12; INT a=one; PRIO ME=5, LOVE=7, MY=7, LORDS=7, LADIES=7, PIPERS=7, DRUMMERS=7, MAIDS=7, SWANS=7, GEESE=7, GOLD=7, COLLY=7, FRENCH=7, TURTLE=7, PARTRIDGE=6; BOOL sent to=TRUE; OP THE = (BOOL a)BOOL:a, TWELFTH = (INT a)BOOL: a=twelve, ELEVENTH = (INT a)BOOL: a=eleven, TENTH = (INT a)BOOL: a=ten, NINTH = (INT a)BOOL: a=nine, EIGHTH = (INT a)BOOL: a=eight, SEVENTH = (INT a)BOOL: a=seven, SIXTH = (INT a)BOOL: a=six, FIFTH = (INT a)BOOL: a=five, FOURTH = (INT a)BOOL: a=four, THIRD = (INT a)BOOL: a=three, SECOND = (INT a)BOOL: a=two, FIRST = (INT a)BOOL: a=one; OP ME = (BOOL a, INT b)VOID: (IF a THEN print(b) FI), LOVE = (BOOL a, b)BOOL: (IF a THEN b ELSE FALSE FI), MY = (BOOL a, b)BOOL: a LOVE b, AND = (INT a)INT: a; MODE DATE = STRUCT(INT day, month); DATE christmas := (25, 12); OP LORDS = (INT a, b)INT: a*b, LADIES = (INT a, b)INT: a*b, PIPERS = (INT a, b)INT: a*b, DRUMMERS = (INT a, b)INT: a*b, MAIDS = (INT a, b)INT: a*b, SWANS = (INT a, b)INT: a*b, GEESE = (INT a, b)INT: a*b, GOLD = (INT a, b)INT: a*b, COLLY = (INT a, b)INT: a*b, FRENCH = (INT a, b)INT: a*b, TURTLE = (INT a, b)INT: a*b; OP LEAPING = (INT a)INT: a, DANCING = (INT a)INT: a, PIPING = (INT a)INT: a, DRUMMING = (INT a)INT: a, MILKING = (INT a)INT: a, SWIMMING = (INT a)INT: a, LAYING = (INT a)INT: a, RINGS = (INT a)INT: a, BIRDS = (INT a)INT: a, HENS = (INT a)INT: a, DOVES = (INT a)INT: a; OP PARTRIDGE = (INT a, b)INT: a+b; INT in a pear tree = 0; print("Factorial of "); print(day OF christmas := readint); print(" is "); IF day OF christmas > 12 THEN print("too big for this program."); stop FI; # Now we are ready.. # THE FIRST day OF christmas MY TRUE LOVE sent to ME a PARTRIDGE in a pear tree; THE SECOND day OF christmas MY TRUE LOVE sent to ME two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE THIRD day OF christmas MY TRUE LOVE sent to ME three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE FOURTH day OF christmas MY TRUE LOVE sent to ME four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE FIFTH day OF christmas MY TRUE LOVE sent to ME five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE SIXTH day OF christmas MY TRUE LOVE sent to ME six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE SEVENTH day OF christmas MY TRUE LOVE sent to ME seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE EIGHTH day OF christmas MY TRUE LOVE sent to ME eight MAIDS MILKING seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE NINTH day OF christmas MY TRUE LOVE sent to ME nine DRUMMERS DRUMMING eight MAIDS MILKING seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE TENTH day OF christmas MY TRUE LOVE sent to ME ten PIPERS PIPING nine DRUMMERS DRUMMING eight MAIDS MILKING seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE ELEVENTH day OF christmas MY TRUE LOVE sent to ME eleven LADIES DANCING ten PIPERS PIPING nine DRUMMERS DRUMMING eight MAIDS MILKING seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree; THE TWELFTH day OF christmas MY TRUE LOVE sent to ME twelve LORDS LEAPING eleven LADIES DANCING ten PIPERS PIPING nine DRUMMERS DRUMMING eight MAIDS MILKING seven SWANS SWIMMING six GEESE LAYING five GOLD RINGS four COLLY BIRDS three FRENCH HENS two TURTLE DOVES AND a PARTRIDGE in a pear tree END .execut xmas A68: XMAS ALGOL68C Release 1.271 Unused space 991 Code generated 8r2271 LINK: Loading [LNKXCT A68 execution] 7 Factorial of +7 is +5040 Svante Lindahl, NADA, KTH Numerical Analysis & Computer Science UUCP: {seismo,mcvax}!enea!ttds!zap Royal Institute of Technology, Sweden ARPA: enea!ttds!zap@seismo.CSS.GOV EAN: zap@cs.kth.sunet Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9701 for JMS@ARIZMIS; Mon, 19-MAY-1986 01:03 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 02:52:22 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a027992; 15 May 86 0:07 EDT Received: from USENET by SMOKE.BRL.ARPA id a006081; 14 May 86 23:54 EDT From: Mark Patrick Newsgroups: net.lang.c,net.micro.pc,net.unix-wizards Subject: Varargs, portability Message-ID: <279@vecpyr.UUCP> Date: 9 May 86 22:55:04 GMT Xref: brl-sem net.lang.c:1009 net.micro.pc:1084 net.unix-wizards:1176 To: info-c@BRL-SMOKE.ARPA Is the following program portable to any machine which provides a (reasonable) implementation of C. #include fred(ap) va_list ap ; { int i ; for ( i=0; i < 52 ; i++ ) { if ( (i%2) == 0 ) printf("%d\n",va_arg(ap, int)) ; else printf("%f\n", va_arg(ap, double)) ; } } joe(va_alist) va_dcl { va_list ap ; va_start(ap) ; fred(ap) ; va_end(ap) ; } main() { joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17, 18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5, 37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ; } -- Mark Patrick ...{lll-crg, amd, dual}!vecpyr!markl Visual Engineering Corp, San Jose, CA Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0339 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id af00297; 19 May 86 2:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a022831; 16 May 86 15:48 EDT From: Andrew Koenig Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <5430@alice.uUCp> Date: 10 May 86 16:37:11 GMT Xref: brl-sem net.lang.c:1072 net.unix-wizards:1194 To: info-c@BRL-SMOKE.ARPA > Hypothetical but quite beleivable: On a 68000, pass the first N > 32-bit integer (int, long, etc.) arguements in data regisers and the > first M (32-bit) pointer arguments in address registers. There isn't > a typeof operator, and the hack of determining the data type by doing > string manipulations on the quoted type, besides preprocessor > replacements in quoted strings being a pcc oddity, breaks when faced > with typedefs. (I think argument quoting via a different meathod is > proposed in the current ansi C draft.) > > This is true of any architecture with different register types with > identical size. (Otherwise the type could be determined by sizeof, > which I do in the varargs.h implementation I wrote.) Any proposted > solutions, other than not having such a compiler on such a machine? If a pointer argument is passed in a different place from an integer argument of the same size, then implementing varargs requires some help from the compiler. But such an implementation is going to have trouble in any event because even today there are sometimes programs that forget to, say, declare the type of an argument. This is especially true when that argument is merely passed to some other function. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0378 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:23 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id ah00297; 19 May 86 2:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a022909; 16 May 86 15:49 EDT From: Ray Butterworth Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <2496@watmath.UUCP> Date: 9 May 86 13:16:30 GMT To: info-c@BRL-SMOKE.ARPA > > lots of us say "typedef short bool" in our .h files. > typedef char bool; uses less space on some machines. And on some machines it uses more space. Some machines can reference an int with a single instruction, but checking the value of a byte might take several. The one I am using now does the "if(integer)" test in 4 bytes of machine instructions, but "if(character)" takes 12 bytes. So defining it as short or char instead of int might save you 1 or 3 bytes of storage, but it also might cost you several times this amount EVERY time you reference the variable. In general you should always use int (or long). short (or char) should only be used for structures read in from an external source or for large arrays where the saving in space for the data is significantly large. Of course if you aren't worried about portable efficiencies do whatever is best for your machine. On the other hand, I'd like to think that at least some of the software I write now will still be running in 10 years, but I have my doubts about whether or not some of the machines I am using now will still be here then. (I can think of some wonderful code I wrote for an IBM1620 not much more than 10 years ago.) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0421 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:27 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id aj00297; 19 May 86 2:10 EDT Received: from USENET by SMOKE.BRL.ARPA id a022941; 16 May 86 15:50 EDT From: bright%dataio.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Greenleaf Function Library Message-ID: <992@dataioDataio.UUCP> Date: 9 May 86 15:18:09 GMT To: info-c@BRL-SMOKE.ARPA In article <479@brl-smoke.ARPA> C90562JM%WUVMD.BITNET@wiscvm.ARPA writes: >I have been using the Greenleaf Functions general library for >over 2 years and have in general been quite happy with it and have >recommended it to others as a reasonable general purpose library >for PC-DOS environments. I now must modify that recommendation >as it appears that the vendor is unwilling to support the code >which they distribute. > [description of bug] >I sent a fix to them. This was over two >weeks ago and the greenleaf folks have neither acknowledged what >I sent them nor fixed the routine. >Since source is supplied with the Greenleaf Functions, I can fix >it for myself, but other potential buyers should be aware of the >apparent lack of support by Greenleaf for their library. I think you should give the people at Greenleaf a break. Expecting them to fall over dead when a minor bug is found in their code is unreasonable. All significant software has bugs. Normal practice for a company is to wait until a sufficient number of bugs have been found to warrant issuing an update. If a company released revised versions of their software every time a bug was reported, and worked overtime to release it as soon as possible, they would go out of business. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0478 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:31 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id ai00297; 19 May 86 2:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a023014; 16 May 86 15:53 EDT From: flaps%utcs.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: builtins and automatic defines Message-ID: <1232@utcs.uucp> Date: 11 May 86 07:12:52 GMT To: info-c@BRL-SMOKE.ARPA Well I sure hope no one sticks in such a thing without telling me! Any such #include or #define things should not only be optional, they should have to be explicit. So perhaps instead of merely beginning every program with #include , you can also have #include . *I* won't #include it, though... Alan J Rosenthal {linus|decvax}!utzoo!utcs!flaps, {ihnp4|allegra}!cbosgd!utcs!flaps Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0545 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:37 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id ak00297; 19 May 86 2:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a023335; 16 May 86 16:00 EDT From: "Daniel R. Levy" Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <880@ttrdc.UUCP> Date: 11 May 86 22:27:43 GMT To: info-c@BRL-SMOKE.ARPA In article <732@steinmetz.UUCP>, davidsen@steinmetz.UUCP (Davidsen) writes: >XOR can be defined as an (ugly) macro, I believe. > >#define XOR(a,b) (((a) != 0) != ((b) != 0) >/* or if you like small better than readable */ >#define XOR(a,b) (!!(a) != !!(b)) >-- > -bill davidsen or even #define XOR(a,b) (!(a) != !(b)) since XOR(not-a,not-b) == XOR(a,b) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 0664 for JMS@ARIZMIS; Mon, 19-MAY-1986 02:48 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id al00297; 19 May 86 2:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a023485; 16 May 86 16:03 EDT From: Maurice Lampell Newsgroups: net.lang.c,net.micro.68k,net.micro.cpm Subject: Reposting: need Z80 cross-compiler for 68000-based 4.2 BSD UNIX Message-ID: <111@sabre.UUCP> Date: 12 May 86 15:33:27 GMT Xref: brl-sem net.lang.c:1077 net.micro.68k:166 net.micro.cpm:296 To: info-c@BRL-SMOKE.ARPA I am in need of Z80 cross-compiler tools to run on my Integrated Solutions Unix System. The I.S. system is a 68020 4.2 BSD with a Green Hills Compiler (with 4-byte ints). I need a full set of tools: compiler, linker, assembler and library functions; the target is a Z80-based SBC. We are willing to buy this product if it is available. Maurice Lampell Bell Communications Research (201) 758-2592 Please send any replies to: ...!bellcore!nvuxd!ml or ...inhp4!nvuxd!ml Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1030 for JMS@ARIZMIS; Mon, 19-MAY-1986 03:17 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 05:03:47 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028006; 15 May 86 0:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a005834; 14 May 86 23:46 EDT From: Dick Dunn Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <754@nbires.UUCP> Date: 9 May 86 05:31:54 GMT To: info-c@BRL-SMOKE.ARPA > >Btw, you can't have *all* operators extended with "=". How would you write > >"v = v < e;"? (Not that it's useful.) A more precisely stated rule, for C, would be that you can extend any dyadic operator whose result type is the same as the type of the first operand, but... > I think it's useful! As written, of course, it's semantically invalid, > but what you really mean is "v <= e" (sic) or, to demonstrate where it's > really useful, > array[horrendous] [subscript] [list] <= bigexpr; > rather than > if (array[h][s][l] < bigexpr) array[h][s][l] = bigexpr; Cf. Icon, in which the success/failure of a conditional is separate from its value. Icon's <= operator (as all of its relational operators) yields the value of its right operand if it succeeds; otherwise it fails (meaning no result is produced). The semantics described above in ">" is just that of Icon's <:= operator. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator! Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1106 for JMS@ARIZMIS; Mon, 19-MAY-1986 03:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 05:12:11 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028065; 15 May 86 0:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a006355; 15 May 86 0:11 EDT From: Doug Gwyn Newsgroups: net.lang.c,net.micro.pc,net.unix-wizards Subject: Re: Varargs, portability Message-ID: <862@brl-smoke.ARPA> Date: 15 May 86 04:11:38 GMT To: info-c@BRL-SMOKE.ARPA In article <279@vecpyr.UUCP> markl@vecpyr.UUCP (Mark Patrick) writes: >Is the following program portable to any machine which provides a >(reasonable) implementation of C. > ... > joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17, >18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5, >37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ; No, because you have exceeded the VAX's 255-byte argument limit. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1284 for JMS@ARIZMIS; Mon, 19-MAY-1986 03:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028735; 15 May 86 4:02 EDT Received: from USENET by SMOKE.BRL.ARPA id a007686; 15 May 86 3:50 EDT From: "Daniel R. Levy" Newsgroups: net.lang.c Subject: Re: questions from using lint (also, malloc()) Message-ID: <866@ttrdc.UUCP> Date: 9 May 86 23:41:17 GMT To: info-c@BRL-SMOKE.ARPA In article <798@bentley.UUCP>, kwh@bentley.UUCP (KW Heuer) writes: >In article <592@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >>> C is the only language that I can remember that has a separate >>> program (lint) to find and report compiler errors in source code. >>First, the errors detected are not COMPILER errors but CODING errors. >>Second, [examples of other languages] >>Third, "lint"ing is not necessary on every compilation. >>Fourth, on small systems ... [it's better than] complicated multi-pass. >>Fifth, "lint" is rather portable, [but cc] is inherently machine-dependent. >Moreover, because lint is an optional pass which doesn't produce code, it's >safe for it to be overly conservative and flag "errors" which might be okay. >For example, the "possible pointer alignment problem" which results from any >nontrivial cast of malloc(). >Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint While I also think that 'lint' is best standalone or at least not default when compiling, I wish to note that cc as it stands now sometimes produces warnings about things which are not fatal but which usually indicate sleazy or nonportable code. Y'know--while I'm thinking about it, why IS malloc() set up to return a (char *) pointer at all, if that IS inviting a potential (or at least to lint's little mind) pointer alignment problem? Since malloc() is supposed to return a maximally aligned pointer, seems to me that it should have been set up to return a (double *). Yes, yes, before flames of misunder- standing start, I _KNOW_ that the convention for malloc() is to return a (char *) and that it returns a maximally aligned pointer just the same because of the way it has been written. It just seems that the methodology was back-a**wards, that at least returning a (double *) would indicate an implicit promise to the user (and to lint-like checking) that the return value WAS maximally aligned. The only problem I could see with this kind of scheme is that some systems might not support double. But that could be gotten around by #defining a malloc_t type that would represent the maximally aligned data type of the machine at hand. Of course malloc() is now cast in stone, so I doubt seriously whether it would be worth the trouble to implement a new memory-allocating interface in C now. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2190 for JMS@ARIZMIS; Mon, 19-MAY-1986 05:24 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 07:15:58 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002366; 19 May 86 4:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a001893; 19 May 86 3:48 EDT From: John Mashey Newsgroups: net.lang.c,net.unix-wizards Subject: Re: arguments in registers [a Good Thing] Message-ID: <476@mips.UUCP> Date: 12 May 86 05:07:14 GMT Xref: brl-sem net.lang.c:1080 net.unix-wizards:1199 To: info-c@BRL-SMOKE.ARPA In article <109@ima.UUCP> johnl@ima.UUCP (John R. Levine) writes: >In article <1205@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >>In article <155@cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>>[Passing arguments in registers] would be fine if C had nested >>>procedures or inlines or something, but a disaster otherwise. >> >>In fact, a compiler is free to optimise any function into inline code, > >Actually, you can always pass arguments in registers if you're smart about it. >The compiler for the IBM RT/PC does. (A clever idea added after I stopped >working on it.) The first few arguments to a procedure are always passed in >registers, but space is left for them in the stack frame. If they aren't >declared register in the routine, the routine's prolog saves them. Note that ^----------------------------------------------------------------^ >this saves code space, since you have one set of store instructions in the >routine's prolog rather than replicating the code at each call. If the >arguments are declared register, well, they're already in registers. 1) Passing arguments in registers is indeed a big win. There is at least some belief that 2 registers gets you 70-80% of the calls, 4 registers gets you 90-95%. 2) I'm sure many systems do this these days, especially now that varargs is more widely used. I may recall incorrectly, but I thought the Zilog ZEUS system's compiler did this. At least the HP Spectrum and MIPS R2000 compilers do (4 regs). This is especially attractive on 32-register RISC machines. Certainly the method is not a "disaster", since live running Unices are supported by them. 3) (^---^ part above): They don't have to be saved unless the code takes the address of them (the exact conditions vary, but reasonable assumptions can be made). A good global optimizer may well NEVER save them. In particular, they almost NEVER need to be saved inside a leaf (i.e., calls no functions) routine, at least on machines that have 32 registers. Even better, the arguments may well be computed into the argument registers in the first place. 4) For good optimizers, "register x" doesn't mean much any more except to clue the compiler quickly that no address can be taken of x. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 2312 for JMS@ARIZMIS; Mon, 19-MAY-1986 05:33 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 07:20:46 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002368; 19 May 86 4:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a001986; 19 May 86 3:51 EDT From: Steve Rumsby Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <287@euclid.warwick.UUCP> Date: 12 May 86 10:13:17 GMT To: info-c@BRL-SMOKE.ARPA In article <797@bentley.UUCP> kwh@bentley.UUCP writes: >In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>I have ranted about C using a one statement model for its control >>statements instead of an explicit end statement. Compound statements are >>bounded by braces instead. Yuk! > >Ah yes, there are two major types of language in the structured family; >f77 with "endif" (some members use "end" for all of "endif", "endwhile", >etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I >presume this is what you dislike. (If it's the spelling that bothers you, >I'm sure you're aware that you can define "begin" and "end" as macros.) > >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) > Occam uses this model to delimit its blocks. It's a nice idea - no more adding {/} around an if's "then" or "else" part simply because you've changed it from one statement to two. Consistency like this can save a lot of time looking for missing braces, etc. However, you do have to be *very* careful with the space bar. One space in the wrong place can also be a bit irritating to find, especially if you can't use vi/emacs to match them for you like you can with {/}! Couldn't you write a small(?) filter which would let you write C without braces and fill them in for you from the indentation? It doesn't seem too difficult. (No I'm not offering to do it). Steve. -- Steve Rumsby. UUCP: ...!ukc!warwick!steve JANET: steve%warwick.uucp@uk.ac.warwick.daisy ARPA: steve%warwick.uucp@ucl-cs.ARPA BITNET: steve%warwick.uucp%uk.ac.warwick.daisy@uk.ac Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2399 for JMS@ARIZMIS; Mon, 19-MAY-1986 05:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002371; 19 May 86 4:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a002034; 19 May 86 3:53 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#6 Message-ID: <1039@hou2d.UUCP> Date: 11 May 86 11:28:56 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sun, 11 May 86 Volume 16 : Issue 6 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 5 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 5 To: cbosgd!std-c%utcsri # C.3.0.1 Lvalues {--> and function locators} * An "lvalue" is an expression that designates an object {and that * may be used to change its value -->}. {--> When an object is said to have a particular type, the type is specified by the lvalue used to designate the object.} N--> If an lvalue appears in a context other than as an operand that N--> may or shall be an lvalue, if it has array type it is converted N--> to a pointer as described in #C.2.2.1, otherwise it is replaced N--> by the value of the designated object. In either case, the N--> result is not an lvalue. N--> A "modifiable lvalue" is an lvalue that does not have array type N--> and does not have a type declared with the const type specifier. N--> A "function locator" is an expression that has function type. If N--> a function locator appears in a context other than as an operand N--> that may or shall be a function locator, it is converted to a N--> pointer as described in #C.2.2.1. The result is not a function N--> locator. * {Some operators yield lvalues. -->} The discussion of each opera- * tor {states if it expects --> identifies those that may or shall * have an lvalue {-->, modifiable lvalue, or function locator} * operand, and {if it --> those that} yield an lvalue {--> or func- tion locator} result. * ... The name "lvalue" comes {--> originally} from the assignment expression E1 = E2, in which the left operand E1 must be an * lvalue. {--> It is perhaps better considered as representing an object "locator value". What is sometimes called "rvalue" is in this Standard described as the "value of an expression".} * An obvious example of an lvalue is an identifier {used on the left side of an assignment operator --> of an object}. As a further example, if E is a unary expression that has pointer type, *E is an lvalue that designates the object to which E points. # C.3.1 Primary expression <--O An identifier is a primary expression, provided it has been suit- <--O ably declared as discussed later. Its type is specified by its <--O declaration, except for the conversions of function and array ex- <--O pressions discussed previously. Because of these conversions, <--O function and array identifiers are not lvalues. N--> An identifier is a primary expression, provided it has been de- N--> clared as an object (in which case it is an lvalue) or a function N--> (in which case it is a function locator). A constant is a primary expression. Its type depends on its * form, as detailed {previously --> in #C.1.1.3}. <--O A string literal is a primary expression. Its type is originally <--O "array of const char"; following the conversion rule given previ- <--O ously for arrays, this is converted to "pointer to const char" <--O and the result is a pointer to the initial character in the <--O string literal. N--> A string literal is a primary expression. It is an lvalue of N--> type "array of char", as detailed in #C.1.1.4. * A parenthesized expression is a primary ... {The presence of parentheses does not affect whether the expression is an lvalue. --> It is an lvalue if the unadorned expression is an lvalue, or a function locator if the unadorned expression is a function lo- cator.} # C.3.2.1 Array subscripting <--O Usually, the first expression has type "array of TYPE" <--O (equivalently, "pointer to TYPE"), the subscript has integral <--O type, and the type of the result is "TYPE". N--> One of the expressions shall have type "pointer to TYPE", the N--> other expression shall have integral type, and the result has N--> type "TYPE". # C.3.2.1 Array subscripting * If E is an n-dimensional array ... then E, {appearing in an ex- pression --> used as other than an lvalue}, is converted to a pointer to an (n-1)-dimensional array ... If the unary * opera- tor is applied to this pointer explicitly, or implicitly as a result of subscripting, the result is the pointed-to (n-1)- * dimensional array, which is itself {immediately converted into a pointer --> converted into a pointer if used as other than an lvalue}. # C.3.2.2 Function calls * The {first expression --> expression preceding the parentheses} * shall have type {"function returning TYPE" or -->} "pointer to * function returning TYPE" {--> (which could be the result of con- verting a function locator)}. # C.3.2.2 Function calls N--> If a function prototype declarator is in scope, the number of ar- N--> guments shall agree with the number of formal parameters. The N--> types shall be such that each formal parameter may be assigned N--> the value of the corresponding argument. # C.3.2.2 Function calls * An argument may be {a function identifier or an expression that has the type of any object --> any expression other than a void expression}. In preparing for the call to a function, each argu- * ment is {assigned to the corresponding formal parameter; thus, all argument passing is strictly by value --> evaluated, and each formal parameter is assigned the value of the corresponding argu- ment}. * ... If no {"function prototype" (a declaration that declares the types of the parameters) --> function prototype declarator} is in scope, the integral promotions are performed, and arguments that * have type float are promoted to double. {--> These are called the "default argument conversions". If the number of arguments or their types after conversion do not agree with those of the formal parameters, the behavior is undefined.} # C.3.2.3 Structure and union members A postfix expression followed by a dot and an identifier desig- * nates a member of a structure or union {object --> entity}. The * value ... is an lvalue {if the first expression is an lvalue and the type of the member is not array or a type with the const at- tribute --> unless the first expression is the value returned by a function call}. A postfix expression followed by an arrow ... and an identifier designates a member of a structure or union object. The value * ... is an lvalue {if the type of the member is not array or a type with the const attribute -->}. <--O ... If f is a function returning a structure or union, and x is <--O a member of that structure of union, f().x is a valid postfix ex- <--O pression but is not an lvalue. # C.3.2.4 Postfix increment and decrement operators * The operand ... shall be a {--> modifiable} lvalue. ... # C.3.3.1 Prefix increment and decrement operators * The operand ... shall be a {--> modifiable} lvalue. ... # C.3.3.2 Address and indirection operators N--> The operand of the unary & operator shall be a function locator N--> or an lvalue that designates an object other than a bit-field or N--> an object declared with the register storage-class specifier. * The operand of the unary * operator shall have pointer type {-->, other than pointer to void.} # C.3.3.2 Address and indirection operators The unary * operator denotes indirection. If the operand points * to a function, the result is {an expression by which the function can be called --> a function locator}; ... # C.3.3.2 Address and indirection operators * It is always true that if E is an lvalue {--> or function loca- * tor}, *&E is an lvalue {--> or function locator} equal to E. * If *P is an lvalue and T is the name of an {--> object} pointer type, the cast expression *(T)P is an lvalue that has the same type as that to which T points. * Forward references: cast operators (#C.3.4) {-->, storage-class specifiers (#C.5.1), structure and union specifiers (#C.5.2.1)}. ------------------------------ End of mod.std.c Digest - Sun, 11 May 86 07:27:01 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2471 for JMS@ARIZMIS; Mon, 19-MAY-1986 05:53 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002373; 19 May 86 4:07 EDT Received: from USENET by SMOKE.BRL.ARPA id a002038; 19 May 86 3:53 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#7 Message-ID: <1040@hou2d.UUCP> Date: 11 May 86 11:34:37 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sun, 11 May 86 Volume 16 : Issue 7 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 6 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 6 To: cbosgd!std-c%utcsri # C.3.3.3 Unary arithmetic operators * Except that it inhibits regrouping {--> of subexpressions of E with subexpressions outside of E}, the expression +E is equivalent to (0+E). # C.3.3.4 The sizeof operator <--O The sizeof operator ... may be applied to any object except a <--O bit-field member of a structure, which is the only kind of object <--O whose size might not be an integral number of bytes. N--> The sizeof operator may not be applied to any expression that has N--> type function, bit-field, or void, or to the parenthesized name N--> of the type of such an expression. # C.3.3.4 The sizeof operator * The size is determined from the {declaration --> type} of the * {object in the -->} operand {expression -->}, which is not itself * evaluated. The result is {an unsigned constant that has integral type and may be used anywhere such a constant is required --> an integer constant}. The size of the result is implementation- * defined {-->, and its type (an unsigned integral type) is size_t defined in the header}. # C.3.3.4 The sizeof operator * When applied to a formal parameter that has array {--> or func- * tion} type, the sizeof operator yields the size of {a pointer to a member of such an array --> the pointer obtained by converting as in #C.2.2.1}. # C.3.3.4 The sizeof operator <--O double *dp = alloc(sizeof (double)); <--O ... <--O sizeof(array)/sizeof(array[0]) N--> double *dp = alloc(sizeof *dp); N--> ... N--> sizeof array / sizeof array[0] # C.3.3.4 The sizeof operator * Forward references: ... {--> terms and common definitions (#D.1.1)}, ... # C.3.4 Cast operators * An {--> arbitrary} integer may be converted to a pointer. {If the space provided was long enough, the mapping always carries an integer converted from a pointer back to the same pointer, but is otherwise --> The result is} implementation-defined. # C.3.4 Cast operators N--> A cast does not yield an lvalue. # C.3.6 Additive operators When two pointers to members of the same array object are sub- tracted ... the size of the result is implementation-defined * {-->, and its type (a signed integral type) is ptrdiff_t defined in the header}. # C.3.9 Equality operators Both of the operands may have arithmetic type, or both may be * pointers to the same type. In addition, {--> one may be an ob- ject pointer and the other a pointer to void, or} one may be a * pointer and the other {an integral constant expression with the value 0 --> a null pointer constant}. N--> ... If one of the operands is a pointer to void, the other is N--> converted to that type. # C.3.15 Conditional operator Both the second and third operands shall have arithmetic type, or shall have the same structure, union, or pointer type, or shall * be void expressions. In addition, {--> one may be an object pointer and the other a pointer to void, or} one may be a pointer * and the other {an integral constant expression with the value 0 --> a null pointer constant}. N--> ... If one of the operands is a pointer to void, the other N--> operand is converted to that type and the result has that type. N--> A conditional expression does not yield an lvalue. # C.3.16 Assignment operators * An assignment operator shall have a {--> modifiable} lvalue as its left operand. * An assignment operator stores a value in the object {specified by the lvalue --> designated by the left operand}. An assignment expression has the type of the left operand and the value of the * left operand after the assignment {-->, but is not an lvalue}. # C.3.16.1 Simple assignment <--O The operands may each have arithmetic type or may be structure or <--O union objects that have the same type. In addition, the left <--O operand may be a pointer, in which case the right operand must be <--O a pointer that has the same type or has type "pointer to void", <--O or must be an integral constant expression with the value 0. N--> Both the operands shall have arithmetic type or shall have the N--> same structure, union, or pointer type. In addition, if the left N--> operand is a pointer, either of the operands may be a pointer to N--> void, or the right operand may be a null pointer constant. * ... If the left operand is a pointer {and the right operand an integral constant expression with the value 0, the constant is converted into a null pointer -->, if either of the operands is a pointer to void or the right operand is a null pointer constant, the right operand is converted to the type of the left operand}. # C.3.17 Comma operator N--> A comma operator does not yield an lvalue. # C.4 CONSTANT EXPRESSIONS A function-call operator (), an increment or decrement operator * ++ or --, {an indirection * unary operator, -->} or an assignment operator shall not appear in any constant expression. ... The array-subscripting [] and member-access . and -> opera- * tors and the "address-of" & {--> and indirection *} unary opera- * tors shall not appear {,--> except in an expression that is the operand of a sizeof operator}. <--O For constant expressions in initializers, in addition to integral <--O constant expressions as discussed previously, one can also use <--O floating constants and arbitrary casts and can apply the unary & <--O operator to objects that have static storage duration and to ar- <--O rays that have static storage duration subscripted with an in- <--O tegral constant expression. The unary & operation can also be <--O implied by appearance of a function identifier or an unsubscript- <--O ed array identifier. In short, the expression must evaluate to a <--O constant, to the identifier or a previously declared function, or <--O to the address of a previously declared object that has static <--O storage duration plus or minus an integral constant expression, <--O or to the difference in addresses of two previously declared ob- <--O jects that are members of the same aggregate. N--> For constant expressions in initializers, in addition to integral N--> constant expressions as discussed previously, floating constants N--> and arbitrary casts may be used. Lvalues of objects that have N--> static storage duration or function identifiers may also be used N--> to specify addresses, explicitly with the unary & operator or im- N--> plicitly for unsubscripted array identifiers or function identif- N--> iers. A constant difference in the addresses of two members of N--> the same aggregrate may be used. As a special case, a suitably N--> cast null pointer may be used to derive an integral constant ex- N--> pression, the value of which is the offset in bytes of an element N--> of a structure from its beginning, by means of an expression of N--> the form N--> (int)&((TYPE-SPECIFIER)0)->POSTFIX-EXPRESSION N--> where TYPE-SPECIFIER specifies the type of a pointer to a struc- N--> ture and POSTFIX-EXPRESSION designates any member of that struc- N--> ture or of a subaggregate (any array subscript shall be an in- N--> tegral constant expression). ------------------------------ End of mod.std.c Digest - Sun, 11 May 86 07:34:03 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2654 for JMS@ARIZMIS; Mon, 19-MAY-1986 06:04 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028764; 15 May 86 4:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a008335; 15 May 86 4:05 EDT From: Bob Larson Newsgroups: net.lang.c,net.unix-wizards Subject: Re: varargs Message-ID: <318@usc-oberon.UUCP> Date: 9 May 86 01:39:57 GMT Xref: brl-sem net.lang.c:1015 net.unix-wizards:1179 To: info-c@BRL-SMOKE.ARPA In article <5388@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: > 2. the practice of writing programs that accept varying > numbers of actual parameters and access them using ONLY the > facilities provided by . The particular > implementation of these facilities may differ from one > machine to another. > >I said I don't know offhand of a machine that can't implement #2. Hypothetical but quite beleivable: On a 68000, pass the first N 32-bit integer (int, long, etc.) arguements in data regisers and the first M (32-bit) pointer arguments in address registers. There isn't a typeof operator, and the hack of determining the data type by doing string manipulations on the quoted type, besides preprocessor replacements in quoted strings being a pcc oddity, breaks when faced with typedefs. (I think argument quoting via a different meathod is proposed in the current ansi C draft.) This is true of any architecture with different register types with identical size. (Otherwise the type could be determined by sizeof, which I do in the varargs.h implementation I wrote.) Any proposted solutions, other than not having such a compiler on such a machine? -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: ihnp4!sdcrdcf!usc-oberon!blarson Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2715 for JMS@ARIZMIS; Mon, 19-MAY-1986 06:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028782; 15 May 86 4:30 EDT Received: from USENET by SMOKE.BRL.ARPA id a008591; 15 May 86 4:14 EDT From: Steve Summit Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <342@copper.UUCP> Date: 8 May 86 06:58:08 GMT To: info-c@BRL-SMOKE.ARPA In article <501@brl-smoke.ARPA>, rbj@icst-cmr (Root Boy Jim) writes: > Most People Your's Truly > > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ There is an excellent, excellent book, which everybody should read, called The Elements of Style, by William Strunk and E. B. White. It is about writing in English, but almost everything in it applies to writing in programming languages as well. One of my favorite quotes (from page 74 of the third edition) is "In ordinary composition, use orthodox spelling. Do not write "nite" for "night," "thru" for "through," "pleez" for "please," unless you plan to introduce a complete system of simplified spelling and are prepared to take the consequences." The consequences, of course, are that in virtually all cases you will be laughed out of the room. Convention has a place. You are not being a sheep or a lemming if you do things the way most people do things; you are being responsible. C can be hard enough to read when it is formatted "correctly;" we certainly don't need any more unorthodox methodologies floating around. Proponents of things like "look ma, no braces" will claim that theirs is not "ordinary composition," and that they are therefore exempt from generally accepted programming practices. This statement is in fact perfectly true. If you want to be a rugged individualist and program in a vacuum; if nobody else ever reads your code; if only you have to maintain it or port it to other machines; then you are certainly welcome to make each program you write an odds on favorite for the winner's circle in the Obfuscated C Contest. However, do the rest of us a favor and perfect your isolated environment by sparing this newsgroup from your rantings and ravings. Steve Summit tektronix!copper!stevesu Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3437 for JMS@ARIZMIS; Mon, 19-MAY-1986 07:54 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 09:46:09 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002508; 19 May 86 4:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a001696; 19 May 86 3:41 EDT From: Frank Adams Newsgroups: net.lang.c,net.lang Subject: Multiple assignments Message-ID: <1455@mmintl.UUCP> Date: 12 May 86 05:23:17 GMT Followup-To: net.lang Xref: brl-sem net.lang.c:1078 net.lang:307 To: info-c@BRL-SMOKE.ARPA In article <797@bentley.UUCP> kwh@bentley.UUCP writes: >In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>And as someone pointed out, assignments return a value too, so should we >>cast them to void as well? Oh yeah, assignment is `different'. > >Actually, this does bother me somewhat. I think I prefer the idea that >values should be used or explicitly discarded, as in forth. (Not that forth >has any error checking!) No, I'm not suggesting that lint should complain >about assignments, or that C should have a different notation for assignments >that are being pipelined into another expression. Just waiting for the next >generation of languages. This bothers me somewhat too. I do have a suggestion for how to deal with it: have a "multi-assignment" operator. Supposing that "$" is being used for this operator, then to set both "a" and "b" to zero, one would write "a $ b = 0", rather than "a = b = 0", as C does. This has the disadvantage that it cannot be used where the result of the assignment is used immediately in a calculation (e.g., "a = 2 * b = sqrt(c)"). On the other hand, if your language supports argument passing by address, it permits an output argument to be multiply assigned; something which assignment-with-value does not support. I am not recommending that this be put into C. It is an idea for new languages. Accordingly, I have directed follow-ups to net.lang instead of net.lang.c. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3498 for JMS@ARIZMIS; Mon, 19-MAY-1986 07:57 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002533; 19 May 86 4:22 EDT Received: from USENET by SMOKE.BRL.ARPA id a002074; 19 May 86 3:54 EDT From: Andrew Hunt Newsgroups: net.lang.c Subject: SCREEN INPUT Message-ID: <1772@gitpyr.UUCP> Date: 13 May 86 02:07:51 GMT To: info-c@BRL-SMOKE.ARPA Hello, NetLand! I wonder if anyone out there might be able to give me a little direction: I am looking for a portable C program that will do screen input forms generation, using curses and depositing the result into a C struct or a Pascal record. Portable source would be nice, but mostly I just need it for a Convergant Technologies MiniFrame II. As they say, thanks in advance... "The more forking you do the more children you get" Andy Hunt Box 34099 Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!gt4099a Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3571 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002537; 19 May 86 4:23 EDT Received: from USENET by SMOKE.BRL.ARPA id a002197; 19 May 86 4:00 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <2741@utcsri.UUCP> Date: 9 May 86 16:57:07 GMT To: info-c@BRL-SMOKE.ARPA In article <602@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >2) More of the same. We all know about *++p. But what if I want to jump > more than one element? I can't write *(p += 2); Or maybe I > want to write `p = &(i += 5). You can write *(p += 2). For *p++, you can write *((p += 2 ) - 2 ) if you really want to. If p is a register, there will be little penalty over dereferencing *before* the p+=2. Why you wanna do p = &(i += 5 ) ?????? Like your immortal `exit(1,fprintf(stderr,"Arrg!!\n"))' this is an artificial combination of two unconnected statements. What's wrong with `i+=5; p= &i'? ( You probably prefer i+=5,p= &i; ) > >3) Exchange operator. This has probably been discussed before, so pardon > me if I blunder into that pit. BUT, DMR has stated that one of > the reasons that exponentiation was left out was because no > (or few, if any) machine could do it inline, and therefore > all the compiler would be doing is a function call anyway. > By the same reasoning, exchange CAN be done efficiently by > some machines, and the hack of a temporary variable and > three assignments is a rather stale idiom. The three > statement XOR trick avoids the temporary, at the expense > of execution time and clarity. > Good stuff. Even machines without an EXG can use a scratch register, which is better than using a user-supplied temp. What, by the way, is the XOR trick? >4) Allow complex statements to be considered as expressions so that > the comma operator can be used to avoid braces, as in > > if (e) x = y, return z; > Errr... well.... I'm not a compiler guru, but.... In the current ( conventional ) setup, compilation of expressions is done separately from 'statement processing' ( i.e. returns, ifs, whiles, cases, etc ). Your suggestion would require that the two be entwined together, which would make generation of really good code a difficult thing. Currently, when an expression is found, a tree is built, then the tree is crunched upon, and the code is generated. If every statement was an expression, then expression trees would need to have nodes for ifs and whiles, etc... ( starting to get LISPy). This could of course get very messy, and a really good coder is already a fairly messy thing to do. Besides, I don't think this would help very much, except for Obfuscated C entries. >5) Allow immediate constants. Currently, there is only one special > case, that of a character array. One can say char *p = "string"; > and have the string squirreled away and the (magic) address > stuffed into the pointer. Why not int *p = &5; where the > integer five is whisked away and replaced by its address. > Sure would eliminate a lot of housekeeping variables. > Fine by me. I would also like to suggest struct constants/rvalues. Suppose I have struct foo{ int f1; char f2; char *bar; } foo_var; I'd like to write something like this ( an executable statement ): foo_var = struct foo{ /* set structure value */ .bar = "Ergo Sum"; .f1 = 73; .f2 = '?'; }; This allows the use of unnamed (structure constants). #define cmplx(a,b) struct complex { .r=(a); .i=(b); } #define J cmplx( 0.0,1.0 ) cvar1 = cmul( cvar2, cmplx( 2.0, 1.02 ) ); I think it is important that the member names be used instead of the order. Also, it would be nice if the compiler were smart in cases like xchar = struct foo{ .bar="??"; .f2 = ychar+1; .f1 = func(i); }.f2; not to generate all the code to compute f1 and bar ( Holy side-effects, Batman! ). The above line could arise by a macro expansion. I have though out many of the implementation details, and I *still* think it's a good idea :-). I am very open to suggestions about the syntax. I will ramble on about/ argue about this later if you want ( and probably if you don't want 8-) <- peril-sensitive sunglasses. ). >6) Eliminate arrays altogether! Well not exactly, but make all > arrays vectored in all dimensions. This would show > those quiche eaters what a real tough language C is :-). > Array syntax would still be available of course, but would > be translated into glorious pointer notation. And it wouldn't > matter whether a variable was defined differently than it > was declared (char x[] or char *x). > Fully vectored arrays were used in B, and I like C's stuff better. You can always set up vectored arrays if you want - and still say array[i][j][k] into the bargain. Of course, you have to set up the vectors yourself... > >8) Allow formal arguments to be declared AFTER the opening brace. > This would allow prioritization of register variables. > Well, register arguments need to copied from the stack anyway, so you can declare your own with an explicit copy. But it wouldn't hurt to let the compiler do it. Since it silly ( presently ) to say `foo(p){ register char *p;...' this could be taken as an argument declaration. I have a related suggestion. Suppose I have the following: f(){ ... { int x,y; ... } { double xy; ... } } I would expect x and y to share the same stack space with xy. Now look at this ( assume 4 regs available ): f(){ register i,j,k,l,m; /* more vars than regs available */ { register ii ..... }; } I think the inner loop should push 'l' ( the lowest priority reg var ) on the stack and keep 'ii' in that reg, since ii will probably get more use in the inner block. The register priority would become ii/i/j/k, so if a further nested block said 'register a,b', the next regs to be kicked out would be j and k, leaving the priority as a/b/ii/i. At the end of the block, the value of l would be popped. If the block were the body of a loop, the pushing/popping would need to be done outside the actual loop, for speed. Inside the loop, of course, 'l' would be addressed as an auto. This allows C programmers one more advantage previously available only to assembler programmers: the re-use of registers for completely different things. The problem is that it would make jumping into/out of blocks a mess. I guess the compiler would have to detect this and generate 'fix' code for the jumps. -- "Canabee be said2b or not2b anin tire b, if half thabee isnotabee, due2 somain chunt injury?" - Eric's Dilemma ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3697 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:11 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002539; 19 May 86 4:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a002660; 19 May 86 4:05 EDT From: Jim Hutchison Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <1776@sdcsvax.UUCP> Date: 12 May 86 17:42:09 GMT To: info-c@BRL-SMOKE.ARPA () well now for ||= you can use |= because C defines 0 as false and non-0 as true (Yes, I know that boolean expressions are defined to return 0/1 as defined in K&R if that is still used). typedef char bool; #define B_TRUE ((bool)1) #define B_FALSE ((bool)0) bool a, b; a = B_TRUE; b = (x == READY); ... b |= (x == READY); b ^= a; Now this can get you into trouble, because 2 and 1 and 47 are also "true". This is o.k. for '|' but not '^'. You could of course do b = (b == 0) ^ (a == 0) but that looks a bit strained. -- /* Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu [ Disclaimer eaten by a passing kiwi ] */ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3777 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 10:13:25 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000941; 15 May 86 8:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a011174; 15 May 86 7:51 EDT From: Kilsup Lee Newsgroups: net.wanted,net.lang,net.lang.c,net.lang.pascal Subject: Looking for Pascal-to-C Converter Program Message-ID: <25@kaist.UUCP> Date: 11 May 86 09:46:02 GMT Keywords: Pascal, C Xref: brl-sem net.wanted:546 net.lang:304 net.lang.c:1024 net.lang.pascal:91 To: info-c@BRL-SMOKE.ARPA I am looking for Pascal to C converter that runs on UNIX environment. If does anyone know this information, please inform to me. And I don't care the Public Domain or Commercial one. The sooner it is, the better it is. Lee, Kilsup ----- <> ------------------ <> ------------------ <> ----- UUCP: ......seismo!kaist!kslee CSNET: kslee@kaist.csnet Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3839 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001003; 15 May 86 8:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a011234; 15 May 86 7:52 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <732@steinmetz.UUCP> Date: 9 May 86 19:59:39 GMT To: info-c@BRL-SMOKE.ARPA In article <210@sdchema.sdchem.UUCP> tps@sdchema.UUCP (Tom Stockfisch) writes: >In article <778@bentley.UUCP> kwh@bentley.UUCP writes: >>In article <838@ihwpt.UUCP> ihwpt!knudsen writes: >>>(2) There isn't any ^^ (XOR) operator either, as in >> >>There is, but it's spelled "!=". (Presumably more efficient than "^", though >>I think either one should work with a smart compiler.) >> > >Not quite the same. > 3 ^^ 4 >would evaluate as 0, > 3 != 4 >evaluates as 1. > >-- Tom Stockfisch, UCSD Chemistry XOR can be defined as an (ugly) macro, I believe. #define XOR(a,b) (((a) != 0) != ((b) != 0) /* or if you like small better than readable */ #define XOR(a,b) (!!(a) != !!(b)) -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3912 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:32 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001056; 15 May 86 8:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a011256; 15 May 86 7:53 EDT From: Wayne Throop Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Re: allocating arrays Message-ID: <350@dg_rtp.UUCP> Date: 10 May 86 18:43:47 GMT Xref: brl-sem net.lang.c:1026 net.micro.pc:1100 net.unix:682 To: info-c@BRL-SMOKE.ARPA Ever alert to save the world from mistaken C code examples that could have been caught by simple use of lint or other commonly available tools, our eagle eyed hero finds a particularly silly example. Let's listen in.... > allbery@ncoast.UUCP (Brandon Allbery) > | Consider an array of 15 pointers to arrays of doubles: > | double (*parray[15])[]; > | The following code to 'malloc' the actual double array barfs on Microsoft 'C', > | with a 'different levels of indirection' warning on the '='. > | The code passes through LINT, and compiles OK on UN*X 5.2 > | char *malloc(); > | parray[0] = (double*)malloc((unsigned)sizeof(double)*75); > double (*parray[15])[]; means: > an indefinitely-sized array of (or a pointer to) > an array of 15 > (double *) Wrong. It means just what the original poster said it meant. It is an array of 15 pointers to arrays of double. What the original poster is mistaken about is that lint doesn't complain about the example. In particular, given this example void f(){ double (*a[15])[]; char *malloc(); a[0] = (double *)malloc((unsigned)sizeof(double)*75); } lint (on our system at least) says warning: illegal pointer combination (4) I grant you, this isn't very informative, but lint *doesn't* like it, that much is certain. Let's run a more blabbermouth tool over it. #1052 4 inconsistent types discovered (= (:AREF (:IDENTIFIER a :AUTO ... ) (:OCT_INT 0)) (:CAST (:POINTER_TO (:DOUBLE)) (:FUNCALL (:IDENTIFIER malloc :EXTERN ... ) (* (:CAST (:UNSIGNED) (:SIZEOF ... )) (:DEC_INT 75))))) Types are: (:POINTER_TO (:ARRAY_OF (:DOUBLE) () ())) and: (:POINTER_TO (:DOUBLE)) As you can see, this is an attempt to assign a pointer-to-double to a pointer-to-array-of-double. In this case, it is easy to tell that this is what is going on even without blabbermouth typecheckers. The declaration of a is of the form (*[])[], making the type of a[0] (*)[], a pointer to an array. The cast of the return value of malloc was simply *, that is, a simple pointer. If you want your compiler to shut up, you should make the cast read (double (*)[]). When the cast is changed in this way, lint no longer complains. Changing the cast to (double **) naturally still causes complaint. The problem as I see it is that the C compiler led the original poster astray with a misleading error message. The problem isn't with a wrong level of indirection, but with an assignment of a value of type pointer-to-scalar to an lvalue of type pointer-to-array. The compiler in question seems to have the common misconception that pointers == arrays in C... they do not. Now, with all that said, I suspect that what was really wanted was this: void f(){ double *a[15]; char *malloc(); a[0] = (double *)malloc((unsigned)sizeof(double)*75); } This is type-correct, and is probably what is wanted. We have here an array of 15 pointers to (implicitly, variable sized arrays of) double. To reference the second double in the implicit array pointed to by the third pointer in a, one would say a[2][1]. To say the same thing with the original definitions would be (*a[2])[1]. > My compiler (pcc) won't even TAKE ``double (*parray[15])[];'' unless it's > initialized or external; apparently sys5 converts it to the declaration > ``double *(*parray[15]);'' -- ptr to array[15] of (double *) -- automatically. Yes, the pcc seems to be another beastie with odd (and in some cases incorrect) ideas about pointers and arrays. Sigh. -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4000 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:37 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001126; 15 May 86 8:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a011334; 15 May 86 7:55 EDT From: eric@chronon Newsgroups: net.lang.c Subject: Re: varargs Message-ID: <236@chronon> Date: 2 May 86 03:48:00 GMT To: info-c@BRL-SMOKE.ARPA In article <129@drilex.UUCP> dricej@drilex.UUCP writes: > >rb@ccird2 (Rex Ballard) wonders what kind of systems would not be able to >handle varargs. ... >... Therefore, a more proper question would be: is there any >architecture which is suitable for a C compiler, but not for varargs? Yes! I can think of an example close to home... An architecture with a large (LARGE) number of registers, a sliding window to allow reference to a smaller register set locally within a procedure, and OS support for using the register set as a stack (handling overflow/underflow). The first arguments are passed in registers via the overlapped sliding window, remaining have to be passed in memory. The problem is that no choice of will be correct; you can only make arbitrarily small the probability of it not being big enough... and at the cost of additional expense elsewhere... I assert that this architecture, and the rest of what goes with this particular feature, is particularly well-suited for efficient execution of programs written in C. >P.S. Microcomputers pass things in registers, rather than on the stack, >because stack operations are slow relative to register operations. This >is also typical of assembly language programming, rather than C language >programming. >Not everybody is willing to pay the high-level language penalty. > >Craig Jackson >UUCP: {harvard,linus}!axiom!drilex!dricej Microcomputers aren't the only ones interested in the fact that using registers is faster than using memory. Does this argument sound RISC-y? Note that nothing in the C language requires this particular high-level language penalty (passing args in memory rather than in registers). The varargs kludge is for convenience only (yes, I like it, too, and would chafe at Pascal-like restrictiveness!). -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric WELL: eblack BIX: eblack Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4148 for JMS@ARIZMIS; Mon, 19-MAY-1986 08:58 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006793; 15 May 86 11:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a018825; 15 May 86 11:40 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#2 Message-ID: <1031@hou2d.UUCP> Date: 10 May 86 23:12:25 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sat, 10 May 86 Volume 16 : Issue 2 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Explanation Differences from April 1985 to February 1986 Draft Standard, Part 1 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Explanation To: cbosgd!std-c%utcsri The preliminary draft proposed ANSI C Standard of April 30, 1985, has been generally available for some time. However, the X3J11 committee has produced since produced further drafts, dated Au- gust 11, 1985; November 11, 1985; and February 14, 1986. The last I heard another draft was going to be printed shortly. This posting is intended for readers who have some familiarity with the April 1985 draft, to bring them up to date on what has happened since then up to the February 1986 version. It exists because I sent mail to Larry Rosler suggesting that it would be a good idea, and he replied that he didn't have time to do it and offered to send me all the versions if I did. That mail exchange, incidentally, happened about Christmas time, and referred to changes up to the November draft only. Much of the delay since then is attributable to some combination of AT&T's mailroom in Summit, NJ; the US Postal Service; and Canada Post. The rest is attributable to my shortage of spare time to do this in; if I'd known how long it was going to take, I would not have volunteered. This posting covers parts A-C of the document; that is, there is nothing about the libraries. I hope to do another one covering the rest of the document shortly. Now, what you see here does not include all of the differences between the versions. I have generally suppressed changes that appeared to provide only a clearer wording. Some of these are fairly substantial in extent, with sentences and paragraphs being rearranged. On the other hand, I have included all changes to the language and to the terminology for talking about it ... un- less, of course, I missed some. The changes are cited in the order of their appearance in the new version, with a few slight exceptions to group related matter. I don't give a lot of context for each one, to keep the length of this document manageable. Never assume that you are seeing a complete paragraph. However, where I have elided important text I have placed an ellipsis (...). For changes that affect a small part of a paragraph, I have adopted the notation {old text --> new text}, which is simply run in line. Each line containing the start of at least one such change is starred in the left margin. The old or new text may be null: thus, the change to section A.1 consists of the deletion of the word "preliminary". In such a paragraph, the words not en- closed in braces may be unchanged from April 1985 to February 1986, or they have have changed in a minor way in which case I am showing the new version. For larger changes, I give complete paragraphs or blocks of para- graphs in old and new forms. The notation "<--O" in the left margin means that this paragraph has been deleted or replaced; "N-->" refers to its replacement or an added paragraph. Since the typographical changes of the actual document are not available here, I have rendered some of them in punctuation and omitted others. (In particular, "quotation marks" in this arti- cle more often than not represent italics in the original and thus a definition of a term.) Paragraphs marked Remark are mine. Mark Brader ------------------------------ Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 1 To: cbosgd!std-c%utcsri # Title N--> Draft Proposed American National Standard for Information Systems N--> -- Programming Language C # A.1 Foreword * This {preliminary -->} draft proposed American National Standard describes the C programming language. # A.6 Definitions of terms <--O Object -- something that has a value. N--> Object -- a region of storage, the contents of which can N--> represent values. # A.6 Definitions of terms It need not be possible to express the address of each individual * bit {--> of an object}. * ... It {must --> shall} be possible to express the address of * each individual byte {--> of an object} uniquely. Remark: The word "must" seems to have been banished from the do- cument. Further instances of this substitution will not be indi- cated, even if the sentence is being cited for another change. # A.6 Definitions of terms N--> Terms explicitly defined in this Standard are not to be presumed N--> to refer implicitly to similar terms defined elsewhere. # A.7 Compliance * A "comforming freestanding implementation" {must --> shall} ... * provide the standard headers {--> and } specified in Section D (library). <--O A conforming implementation may have extensions, which must not <--O alter the behavior of a strictly conforming program (except <--O perhaps by requiring the replacement of identifiers that conflict <--O with new keywords or library symbols). N--> A conforming implementation may have extensions (including addi- N--> tional library functions), provided they do not alter the N--> behavior of a strictly conforming program. # {--> A.8 Future directions} N--> With the introduction of new devices and extended character sets, N--> new features may be added to the Standard. Sections in the N--> Language and Library parts warn implementors and programmers of N--> usages which, though valid in themselves, may conflict with fu- N--> ture additions. N--> Certain features are "deprecated", which means that their use in N--> new programming is discouraged. They are retained in the Stan- N--> dard because of their widespread use in existing programs. N--> Deprecated features may be withdrawn in future revisions of the N--> Standard. Remark: With a new section A.8, the old A.8 (Difference marks) becomes A.9. # B.1.1.2 Translation phases Remark: I'm showing the entire section this time. The precedence among the syntax rules of translation is specified by the following stages. An implementation is not required to * mimic this separation into phases. {Each phase requires a com- plete parse at its level, that is, it may not terminate with a partial non-terminal. -->} 1. Physical source text file characters are mapped to the source character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph sequences are replaced by corresponding single-character internal representations. 2. Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical * source lines to form logical source lines. {--> A file shall not end in a backslash character immediately followed by a new-line character.} 3. Character constants, string literals, and the arguments to #include preprocessing directives are tokenized. Each comment is * replaced by one space character. {--> A file may not end in a partial token.} 4. The source text is completely tokenized. New-line characters * {become new-line tokens --> are retained}. {Each sequence of other white-space characters becomes a single white-space token; alternatively, each other white-space character becomes a unique token. --> Whether each sequence of other white-space characters is retained or is replaced by one space character is implementa- tion defined.} * 5. {The source text is preprocessed. --> Preprocessing directives are executed.} A #include preprocessing directive causes the * named file to be processed from phase 1, recursively. {Prepro- cessing interprets new-line tokens as --> New-line characters are} syntactically significant; "left-parenthesis not preceded by white-space" is syntactically significant to the #define grammar. <--O 6. The preprocessing concatenation operation is applied, and the <--O full source is retokenized. Adjacent string literals are con- <--O catenated. New-line characters are treated the same as other <--O white-space characters. N--> 6. White-space characters separating tokens are no longer signi- N--> ficant. The preprocessing concatenation operator ## is applied. N--> Adjacent string literals are concatenated. 7. The remaining tokens are syntactically and semantically analyzed and translated. * 8. All external {data --> object} and function references are resolved. Library components may be linked to satisfy external references to functions and objects not defined in the current translation. All such translator output is collected into a pro- gram image which contains information needed for execution in its execution environment. Remark: "Data" is another word that seems to have been banished throughout the document. ------------------------------ End of mod.std.c Digest - Sat, 10 May 86 18:09:59 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4329 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:07 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006844; 15 May 86 11:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a018930; 15 May 86 11:43 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#4 Message-ID: <1037@hou2d.UUCP> Date: 10 May 86 23:00:30 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sat, 10 May 86 Volume 16 : Issue 4 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 3 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 3 To: cbosgd!std-c%utcsri # C.1 Lexical elements The program fragment x+++++y is parsed as x ++ ++ + y, which {is a syntax error --> violates a constraint on increment operators}, even though the parse x ++ + ++ y might yield a correct expression. * Forward references: expressions (#C.3) {-->, postfix increment and decrement operators (#C.3.2.4)}. Remark: A number of things have been reclassified from syntax to constraints in this fashion. # C.1.2 Identifiers * An identifier denotes ... one of the following ... a {type --> typedef} name ... # C.1.2.1 Scopes of identifiers N--> (A "function prototype" is a declaration of a function that de- N--> clares the types of its parameters.) # C.1.2.2 Linkages of identifiers In the set of source files and libraries that constitutes an entire program, every instance of a particular identifier with "external linkage" denotes the same function or object. If the declarations in two source files {--> or in disjoint scopes within one source file} differ, the behavior is undefined. # C.1.2.2 Linkages of identifiers For an identifier of a function or object declared with file * scope, if its lexically first declaration {--> with file scope} in the source file contains the keyword static, the identifier has internal linkage. # C.1.2.4 Storage durations of objects [An] instance of an object that has "automatic storage duration" ... is discarded when exe- cution of the block ends by reaching the terminating "}", by jumping to an enclosing block, or by executing a {--> break or} return statement. # C.1.2.5 Types An object declared as a character (char) is large enough to store any member of the {execution character set that can be specified as a single-character character constant without using an octal or hexadecimal escape sequence --> required source character set enumerated in #B.2.1}. # C.1.2.5 Types There are four types of signed integers, called signed char, short int, int, and long int. A "plain" int has the natural size * suggested by the architecture of the execution environment {--> (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header )}; the other types are provided to meet special needs. The set of values of each signed integral type is a subset of the values of the next type * in the list above. Even if the implementation defines {--> signed char,} short int, int, or long int to have the same set of values, they are nevertheless different types. # C.1.2.5 Types N--> The set of non-negative values of a signed type is a subset of N--> its corresponding unsigned type. # C.1.3 Constants <--O If the value of a constant cannot be represented in the storage <--O appropriate for that type in the execution environment, the <--O behavior is undefined. N--> The value of a constant shall be representable in the storage ap- N--> propriate for its type in the execution environment. # C.1.3.2 Integer constants Remark: The notation [opt] below represents a subscript opt, which means optional. <--O integer-suffix: <--O integer-suffix-letter <--O integer-suffix-letter integer-suffix-letter <--O integer-suffix-letter: one of <--O u l U L N--> integer-suffix: N--> unsigned-suffix long-suffix[opt] N--> long-suffix unsigned-suffix[opt] N--> unsigned-suffix: one of N--> u U N--> long-suffix: one of N--> l L # C.1.3.2 Integer constants The type of an integer constant is the first of the corresponding list in which its value can be represented. Unsuffixed decimal: int, long int {-->, unsigned long int}. ... # C.1.3.4 Character constants Even if eight bits are used for ob- jects that have type char, the construction {'\xFF1' --> '\x123'} specifies a character constant containing only one character. (The value of this {--> single-character} constant is implementation-defined.) To specify a character constant contain- ing the two characters {0xFF and 1 --> 0x12 and 3} , the con- struction {'\x0FF1' --> '\x0123'} may be used. (The value of this {--> two-character} constant is also implementation- defined.) # C.1.4 String literals A string literal has static storage dura- tion and type "array of {const -->} char" ... N--> If the program attempts to modify a string literal, the behavior N--> is undefined. # C.1.5 Operators operator: one of ... , {--> # ##} N--> ... The operators # and ## may occur in macro-defining prepro- N--> cessor directives only. # C.1.6 Punctuators punctuator: one of [ ] ( ) { } * , : = ; ... # {## -->} N--> The punctuator # may occur in preprocessor directives only. # C.2.1.1 Characters and integers * A char, or a short int {-->, or an int bit-field}, or their signed or unsigned varieties, may be used in an expression wher- ever an int may be used. In all cases the value is converted to an int if an int can represent all values of the original type; otherwise it is converted to an unsigned int. These are called * the "integral {widening conversions --> promotions}". Remark: The new term "promotion" is used throughout the document. * When an integer is {converted --> demoted} to a shorter unsigned * integer {--> or unsigned int bit-field} or unsigned char, the result is the remainder modulo the largest unsigned number that * can be represented plus one. When an integer is {converted --> * demoted} to a shorter signed integer {--> or int bit-field} or signed char, if the value cannot be represented the result is implementation-defined. ------------------------------ End of mod.std.c Digest - Sat, 10 May 86 19:00:12 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4421 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:14 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006854; 15 May 86 11:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a018934; 15 May 86 11:43 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#5 Message-ID: <1038@hou2d.UUCP> Date: 10 May 86 23:00:43 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sat, 10 May 86 Volume 16 : Issue 5 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 4 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 4 To: cbosgd!std-c%utcsri # C.2.1.2 Signed and unsigned integers * When a signed integer is {assigned to, or used as one of the operands of a binary operator the other operand of which is --> converted to} an unsigned integer of equal or greater length, * {--> if the value of the signed integer is non-negative, its value is unchanged. Otherwise, if the unsigned integer is * longer,} the signed integer is first {converted --> promoted} to * a signed integer of the same length as the unsigned integer. {If the value of the signed integer is negative, the conversion in- volves --> Then it is converted to unsigned by} adding to it the largest number that can be represented in the unsigned integer type plus one. # C.2.1.3 Floating and integral <--O When a value of floating type is converted to integral type, if <--O the result does not fit in the space provided, the behavior is <--O undefined. When a positive value is converted to integral, the <--O fractional part is discarded. When a negative value is converted <--O and the value cannot be represented exactly, the result is one of <--O the two nearest integers, chosen in an implementation-defined <--O manner. N--> When a value of floating type is converted to integral type, the N--> fractional part is discarded. If the result does not fit in the N--> space provided, the behavior is undefined. # C.2.1.5 Usual arithmetic conversions * ... The purpose is to yield a common type, which is {--> also} the type of the result. * ... Otherwise, if {only one --> either} operand has type float, * the other operand is converted to float. {(The presence of this conversion is implementation-defined. In its absence, if one operand has type float, both operands are converted to double.) -->} * ... Otherwise, both operands {and the result -->} have type int. N--> Operands may be converted to other types, provided neither range N--> nor precision is lost thereby; the type of the result is not N--> changed thereby. Conversion of an operand to the same type N--> causes no change. # C.2.2.1 Arrays, functions and pointers * Except when used as {the operand of the sizeof operator --> an operand that may or shall be an lvalue,} or when a string literal is used to initialize an array of chars, an expression that has type "array of TYPE" is converted to an expression that has type "pointer to TYPE" and that points to the initial member of the array object. * {--> Except when used as an operand that may or shall be a func- tion locator,} an identifier declared as "function returning TYPE" is converted to an expression that has type "pointer to function returning TYPE". * Forward references: {function calls (#C.3.2.2) --> lvalues and * function locators (#C.3.0.1)}, initialization (#C.5.6) {, the sizeof operator (#C.3.3.4) -->}. # C.2.2.2 void * The (nonexistent) value of a {void expression --> "void expres- sion" (an expression that has type void)} must not be used in any way, and explicit or implicit conversions must not be applied to * such {a value --> an expression}. Remark: Another change that applies throughout the document. # C.2.2.3 Pointers <--O An integral constant expression with the value 0 may be assigned <--O to or compared for equality to a pointer. The integer constant 0 <--O is converted to a pointer of the appropriate type that is <--O guaranteed not to point to any object. Such a pointer, called a <--O "null pointer", must appear to be equal to the integer constant <--O 0. N--> An integral constant expression with the value 0 or such an ex- N--> pression cast to type void * is called a "null pointer constant". N--> If a null pointer constant is assigned to or compared for equali- N--> ty to a pointer, the constant is converted to a pointer of that N--> type. Such a pointer, called a "null pointer", is guaranteed not N--> to point to any object or function. # C.2.2.4 const and volatile N--> The properties associated with the const type specifier are mean- N--> ingful only for expressions that are lvalues. An expression that has a type declared with the const type * specifier shall not be {an --> a modifiable} lvalue. Remark: The above does not reflect a change in the language but rather a change in the meaning of the term "lvalue". See... * ... Forward references: ... {--> lvalues and function locators (#C.3.0.1)}. # C.2.2.4 const and volatile * {The address of a const object may --> Except via an explicit cast, an expression that has type "pointer to type with the const attribute" shall not} be assigned to a pointer to a type without * the const attribute. If an attempt is made to {change the value --> modify an object that has a type declared with the const type specifier by means of an lvalue that has a type not declared with the const type specifier}, the behavior is undefined. Remark: And likewise for volatile, except the paragraph for vola- tile does not use the word "attempt". # C.3 EXPRESSIONS An "expression" is a sequence of operators and operands that * specifies how to compute a value {--> or (in the case of a void expression) how to generate side effects}. # C.3 EXPRESSIONS Except as indicated by the syntax or otherwise specified later * (for the function-call operator (), {--> the unary plus opera- tor,} &&, ||, ?:, and comma operators), the order of evaluation of an expression is unspecified. # C.3 EXPRESSIONS To force a particular grouping of operations ... grouping * parentheses may be preceded by a unary plus {or minus -->} opera- tor. # C.3 EXPRESSIONS The syntax specifies the precedence of operators in the evalua- tion of an expression, which is the same as the order of the ma- jor subsections of this section, highest precedence first. ... * {The only exceptions are unary operators (#C.3.3), which may have cast expressions (#C.3.4) as operands. --> The exceptions are cast expressions (#C.3.4) as operands of unary operators (#C.3.3), and an operand contained between any of the following pairs of operators: grouping parentheses () (#C.3.1), subscript- ing brackets [] (#C.3.2.1), function-call parentheses () (#C.3.2.2), and the conditional operator ?: (#C.3.15).} ------------------------------ End of mod.std.c Digest - Sat, 10 May 86 18:53:53 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4629 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:29 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007344; 15 May 86 12:23 EDT Received: from USENET by SMOKE.BRL.ARPA id a019387; 15 May 86 11:59 EDT From: Alan J Rosenthal Newsgroups: net.lang.c Subject: Re: A simple non-portable expression tha Message-ID: <1229@utcs.uucp> Date: 9 May 86 08:25:07 GMT To: info-c@BRL-SMOKE.ARPA In article <972@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright) writes: >Different code for (L+I1)+I2 and L+(I1+I2) will only be generated if >ints are smaller than longs. This is strictly true, but it is not true that different code for (L+I1)+I2 and L+(I1+I2) will necessarily be generated if ints are smaller than longs. (Besides which, it is unwise to assume this; see K&R p34...) Anyway, the official K&R quote here is from page 185 which says: ...[besides precedence rules] the order of evaluation of expressions is undefined. ... Expressions involving a commutative and associative operator (*, +, &, |, ^) may be rearranged arbitrarily, even in the presence of parentheses; to force a particular order of evaluation an explicit temporary must be used. So you see that the expressions (L+I1)+I2 and L+(I1+I2) are not necessarily distinct (though not necessarily identical either). Alan J Rosenthal {linus|decvax}!utzoo!utcs!flaps, {ihnp4|allegra}!cbosgd!utcs!flaps Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4529 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:29 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007113; 15 May 86 12:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a019246; 15 May 86 11:53 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <6667@utzoo.UUCP> Date: 8 May 86 19:14:59 GMT To: info-c@BRL-SMOKE.ARPA > All too often, one sees programmers writing code before > a proper job of analysis and design has been done. I > also believe that is partly because semi-running code > makes it appear as though progress has been made, > while a complete design doesn't convey the same impression. Sorry, Doug, I can't let that one go by. All too often, one sees programmers writing detailed design specifications before writing any code. This is probably because design specs make it appear that the problem is fully understood, and give the impression to management that the rest of the process of implementation will be entirely mechanical and hence will be on budget and on schedule. Ho ho. Then one gets to draw up a new budget and schedule for "maintenance", which is the process of modifying the program so that it really meets the customer's needs, instead of merely meeting the specification. The alternative is to recognize that (a) the user probably does not have a complete and coherent idea of what he needs, and hence cannot write a spec or meaningfully assess one you write, and (b) in any case, the presence of the software itself will change the user's tasks and therefore his needs. Given recognition of this situation, it is not even theoretically possible to avoid a trial-and-error process of software development. Hence you should aim to make your inevitable mistakes as early as possible. Which puts a heavy premium on getting initial prototype software into the hands of the customers right away, so that you can learn what's wrong with it. One progresses by iteratively enhancing (and perhaps sometimes re-doing) the prototype, with regular user feedback. This is not to say that the design-it-first method doesn't have its uses, and its advantages, when the problem is understood well enough. But a very large class of problems -- almost anything to do with user interaction, for example -- simply don't meet that criterion. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4674 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:30 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007350; 15 May 86 12:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a019507; 15 May 86 12:01 EDT From: George Robbins Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C (Really arguments in registers) Message-ID: <227@cbmvax.cbmvax.cbm.UUCP> Date: 12 May 86 01:26:30 GMT To: info-c@BRL-SMOKE.ARPA In article <357@pyramid.UUCP> wendyt@pyramid.UUCP (Wendy Thrash) writes: [...] >I don't want to quote too much of the original article -- it was rather long. >The thrust of it was that passing parameters in registers doesn't make things >run faster. This does not fit with my experience. When we implemented >parameter passing in registers at Zilog, it was a big win. *WAS* a big win - meaning maybe it looked good on benchmarks... [...] >I will admit that this parameter passing caused difficulties. In particular, >varargs code was messy, and debuggers more difficult to implement. Was it >worth it? I believe so. Our emphasis was on speed, and that we had. 1) pdp-11 style varargs was broken - no way from C to get a those arguments that got crammed into registers. 2) Because of the register assignment scheme used, you couldn't even blindly pass a list of variable arguments to a routine like printf that did know how to deal with them. 3) setjmp/longjmp got broken with respect to restoring register variable parameters somewhere along the way. In the long run, portability seems to have become the more important issue: Just try porting some of the code in mod.sources and net.sources to the machine and see how far you can get without having to go into the editor and start whacking at source code. Assume that software developers will have the same problems porting their wares... Also, note that Zilog has never delivered its ATT SVID blessed System V port, and that their next series of machines will contain ATT chips running vanilla 3Bx software... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4245 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:30 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006816; 15 May 86 11:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a018926; 15 May 86 11:43 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#3 Message-ID: <1034@hou2d.UUCP> Date: 10 May 86 22:51:50 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sat, 10 May 86 Volume 16 : Issue 3 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 2 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 2 To: cbosgd!std-c%utcsri # B.1.1.3 Diagnostics * A conforming implementation shall produce {a --> at least one} * diagnostic message for every {--> source file that contains a} violation of any syntax rule or constraint. # B.1.2.2 Hosted environment <--O The function called at program startup is called main, and can be <--O declared as <--O extern int main(int argc, char *argv[]); N--> The function called at program startup is called main. The im- N--> plementation declares no prototype for this function. It can be N--> defined with no parameters: N--> int main(void) { /*...*/ } N--> or two parameters (referred to here as argc and argv, though any N--> names may be used, as they are local to the function in which N--> they are declared): N--> int main(int argc, char *argv[]) { /*...*/ } * {--> If they are defined,} the parameters to main have the fol- lowing constraints: # B.1.2.3 Program execution <--O All output directed to interactive devices must occur before new <--O interactively generated input is accepted. N--> The input and output dynamics of interactive devices shall take N--> place as specified in #D.9. N--> ... The intent of the requirements of #D.9 is that unbuffered or N--> line-buffered output appear as soon as possible, to ensure that N--> prompting messages actually appear prior to a program waiting for N--> input. # B.1.2.3 Program execution N--> ... Alternatively, an operation involving only ints or floats N--> may be executed using double precision operations if neither N--> range nor precision is lost thereby. # B.1.2.3 Program execution * Forward references: ..., sequence points (#C.3, {--> #C.6}), ... # B.2.1 Character sets The following trigraph sequences ... shall be replaced by the specified characters ... N--> Any other trigraph sequence that begins with ?? is unchanged. The trigraph sequences enable the input of characters that are * not defined in the ISO {646 --> 646-1983} Invariant Code Set, which is a subset of the seven-bit ASCII code set. # B.2.2 Character display semantics * The "{printing --> active} position" is that location on a display device where the next character output by the fputc func- * tion would appear. The {effect --> intent} of writing a print- able character (as defined by the isprint function) to a display device is to display a graphic representation of that character * at the {current printing --> active} position and then advance * the {printing --> active} position to the next position on the * current line. {--> If the active position is at the final posi- tion of a line (if there is one), the behavior is unspecified.} Alphabetic escape sequences representing non-graphic characters * {--> in the execution character set are intended to} produce for- mat effecting actions on display devices as follows: * \a ("alert") Produces an {implementation-defined -->} audible or * visible representation of an alert character. {Any consequent alteration to the printing position is implementation-defined. --> The active position shall not be changed.} * ... \v ("vertical tab") Moves the {printing --> active} position * to the initial {printing --> active} position of the next * {implementation-defined -->} vertical tabulation position. {--> If the active position is at or past the last defined vertical tabulation position, the behavior is unspecified.} # B.2.3 Signals and interrupts Functions shall be implemented such that they may be interrupted at any time by a signal, and may be called by a signal handler * with no alteration {--> to control flow, to function return values, or} to objects with automatic storage duration belonging to earlier invocations. # B.2.3 Signals and interrupts N--> The functions in the standard library are not guaranteed to be N--> reentrant and may modify objects with static storage duration. # B.2.4.1 Translation limits * The implementation shall be able to {compile at least one --> * translate and execute a} program that {meets or exceeds all --> * contains at least one instance} of the following {translation -->} limits: * ... {6 --> 12} pointer, array, and function declarators modify- ing a basic type in a declaration * ... {1024 --> 127} identifiers with block scope in one block * 1024 macro identifiers {--> simultaneously defined} in one source file * 31 parameters in one function {--> definition and} call * 31 parameters in one macro {--> definition and invocation} N--> ... 509 characters in a string literal (after concatenation) N--> 32767 bytes in an object (in a hosted environment only) * {4 --> 8} nesting levels for #included files <--O maximum number of alphabetic cases in an external identifier (1) # B.2.4.2 Numerical limits A conforming implementation shall document all these items, which * are specified in the headers {--> and }. * Sizes of integral types {--> } The values given below shall be replaced by implementation- * defined {values --> constant expressions} that shall be equal or greater in magnitude (absolute value). # B.2.4.2 Numerical limits * Characteristics of floating types {--> } N--> The integer values given below shall be replaced by N--> implementation-defined constant expressions that shall be equal N--> or greater in magnitude (absolute value). Values that have N--> floating type need not be constant expressions. N--> The following apply to all three floating-point types and require N--> only one name. radix of exponent representation FLT_RADIX 2 * {DBL_RADIX 2 -->} * {LDBL_RADIX 2 -->} * addition rounds (1), chops (0), {--> or indeterminable during translation (-1)} FLT_ROUNDS 0 * {DBL_ROUNDS 0 -->} * {LDBL_ROUNDS 0 -->} N--> guard digits are used (1) or not used (0) for floating multipli- N--> cation N--> FLT_GUARD 0 N--> floating values must be normalized (1) or need not be (0) N--> FLT_NORMALIZE 0 <--O maximum power of 10 that can be represented ... <--O FLT_MAX_EXP +38 <--O DBL_MAX_EXP +38 <--O LDBL_MAX_EXP +38 <--O minimum power of 10 that can be represented ... <--O FLT_MIN_EXP -38 <--O DBL_MIN_EXP -38 <--O LDBL_MIN_EXP -38 N--> maximum representable finite floating-point number N--> FLT_MAX 1E+38 N--> DBL_MAX 1E+38 N--> LDBL_MAX 1E+38 N--> minimum representable positive floating-point number N--> FLT_MIN 1E-38 N--> DBL_MIN 1E-38 N--> LDBL_MIN 1E-38 N--> maximum integer such that FLT_RADIX raised to that power yields a N--> representable finite floating-point number N--> FLT_MAX_EXP N--> DBL_MAX_EXP N--> LDBL_MAX_EXP N--> minimum negative integer such that FLT_RADIX raised to that power N--> yields a representable positive floating-point number N--> FLT_MIN_EXP N--> DBL_MIN_EXP N--> LDBL_MIN_EXP N--> maximum integer such that 10 raised to that power yields a N--> representable finite floating-point number N--> FLT_MAX_10_EXP +38 N--> DBL_MAX_10_EXP +38 N--> LDBL_MAX_10_EXP +38 N--> minimum negative integer such that 10 raised to that power yields N--> a representable positive floating-point number N--> FLT_MIN_10_EXP -38 N--> DBL_MIN_10_EXP -38 N--> LDBL_MIN_10_EXP -38 number of decimal digits of precision FLT_DIG 6 DBL_DIG 6 LDBL_DIG 6 N--> number of base-FLT_RADIX digits in the floating-point mantissa N--> FLT_MANT_DIG N--> DBL_MANT_DIG N--> LDBL_MANT_DIG N--> number of base-FLT_RADIX digits in the floating-point exponent N--> (including bias or sign) N--> FLT_EXP_DIG N--> DBL_EXP_DIG N--> LDBL_EXP_DIG N--> minimum positive floating point number x such that 1.0 + x != 1.0 N--> FLT_POS_EPS 1E-5 N--> DBL_POS_EPS 1E-5 N--> LDBL_POS_EPS 1E-5 N--> minimum positive floating point number x such that 1.0 - x != 1.0 N--> FLT_NEG_EPS 1E-5 N--> DBL_NEG_EPS 1E-5 N--> LDBL_NEG_EPS 1E-5 N--> minimum integer such that FLT_RADIX raised to that power yields a N--> floating-point number x such that 1.0 + x != 1.0 N--> FLT_POS_EPS_EXP N--> DBL_POS_EPS_EXP N--> LDBL_POS_EPS_EXP N--> minimum integer such that FLT_RADIX raised to that power yields a N--> floating-point number x such that 1.0 - x != 1.0 N--> FLT_NEG_EPS_EXP N--> DBL_NEG_EPS_EXP N--> LDBL_NEG_EPS_EXP ------------------------------ End of mod.std.c Digest - Sat, 10 May 86 18:51:13 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4721 for JMS@ARIZMIS; Mon, 19-MAY-1986 09:32 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007360; 15 May 86 12:25 EDT Received: from csnet-relay.arpa by SMOKE.BRL.ARPA id a019775; 15 May 86 12:12 EDT Received: from slb-doll by csnet-relay.csnet id a010512; 15 May 86 12:07 EDT Posted-Date: Thu 15 May 1986 11:40:08 EST Date: Thu 15 May 1986 11:40:08 EST From: Paul Dietz Subject: Re: blabbermouth tool To: info-c@BRL-SMOKE.ARPA In-Reply-To: Wayne Throop's message of 10 May 86 18:43:47 GMT Cc: >I grant you, this isn't very informative, but lint *doesn't* like it, >that much is certain. Let's run a more blabbermouth tool over it. > > #1052 4 inconsistent types discovered > (= > (:AREF > (:IDENTIFIER a :AUTO ... ) > (:OCT_INT 0)) > (:CAST Wayne: what is that blabbermouth tool you refered to? Look's like a Lisp-based package. Is it in the public domain, or for sale? Paul Dietz dietz%slb-doll@csnet-relay.arpa Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5338 for JMS@ARIZMIS; Mon, 19-MAY-1986 10:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 12:21:57 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002543; 19 May 86 4:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a002664; 19 May 86 4:05 EDT From: Jim Hutchison Newsgroups: net.lang.c Subject: Public domain C compiler Message-ID: <1777@sdcsvax.UUCP> Date: 12 May 86 17:52:26 GMT Keywords: Public-Domain,compiler To: info-c@BRL-SMOKE.ARPA <> Does anyone know where I can get a reasonably bug free C compiler or small-(read as subset)-C compiler? It will end up in a commercial product (icky I know), so some expense is justified. Noble venture: I am trying to transform a fortran house into a C house! I have a faction convinced that C is wonderful, now I need to port a compiler to there proprietary system. Probably on my own time, but to be allowed to work in a more reasonable language than fortran is worth it. If no public domain C compiler is available, could anyone point me at public domain yacc's/lex's ??? -- /* Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu [ Disclaimer eaten by a passing kiwi ] */ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5434 for JMS@ARIZMIS; Mon, 19-MAY-1986 10:42 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002595; 19 May 86 4:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a002927; 19 May 86 4:14 EDT From: KW Heuer Newsgroups: net.lang.c,net.lang.apl Subject: Proliferation of operators (was: C Builtin Functions) Message-ID: <812@bentley.UUCP> Date: 14 May 86 00:01:09 GMT Xref: brl-sem net.lang.c:1086 net.lang.apl:18 To: info-c@BRL-SMOKE.ARPA In article <1418@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <788@bentley.UUCP> kwh@bentley.UUCP writes: >>I can feel the flames ("More operators? It's getting as bad as APL!"). > >"More operators? It's getting as good as APL!" -- except that it still >falls way short in this respect. I'm serious; APL does *not* have too many >operators. It does have too little structure. The primitive functions in APL correspond roughly to C operators *and* the entire runtime library. I agree that APL does not have a problem there. APL has its own character set; C is restricted to a subset of ASCII. The size of the alphabet is not a serious problem since new operators in C may be multi-character; however, this may make them less mnemonic. (Of course, some of the APL characters are not all that mnemonic either: "x" for signum is a good example.) The reason APL can deal with having so many primitives is that they all have the same precedence. Adding that many operators to C would be a disaster. You say APL has "too little structure". If you mean things like "while" and "if", I think they may be unwelcome. Put in a "while" loop, and people will start using it to implement a matrix multiply. (For those who don't get it, APL has a builtin matrix multiply, "+.x".) The language doesn't need much program structure, because it has data structure in its place. Now, I *would* like to see some improvement in the data structure. It's now practically impossible to write a function which expects, say, three string (character vector) arguments. I like the grounded tree model, myself, as a fix for this. Also, APL is *severely* in need of *variable declarations*! Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint *** Please restrict followups appropriately! {net.lang.c|net.lang.apl} *** Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6512 for JMS@ARIZMIS; Mon, 19-MAY-1986 12:38 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 14:25:32 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014080; 15 May 86 16:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a002803; 15 May 86 15:46 EDT From: mwm%ucbopal.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Problems with lint as a seperate program Message-ID: <687@jade.BERKELEY.EDU> Date: 10 May 86 05:26:16 GMT Sender: usenet@jade.ucb-vax.ARPA To: info-c@BRL-SMOKE.ARPA Just so that people don't assume that having lint-like things as a seperate program is right, with no problems, I'd like to point out one: on at least one occasion, lint didn't accept quite the same language that cc did. Unless lint it just cc with a magic flag, somebody has to make sure that the lint tracks cc (even if it's only making sure that lint gets recompiled whenever cc changes). I've been using a C compiler that has much of the lint-like checking built in (uninitialized and unused variables, constant references beyond the ends of arrays, type clashes and the like). It's GREAT! It's not a complete lint, in that it won't help you verify that your code will port to other machines, but it catches most of the coding errors that lint does, and issues warnings so that it doesn't mangle the 1% of the cases where they are correctly used. I think most C compilers would benifit from having these types of checks built in. Those obsessed by portability will disagree, because people would be less likely to run lint. But you can still lint code if you wish, and it makes the job of writing running code easier. Message-Id: <8605151946.AA20256@icst-cmr.ARPA> To: copper!stevesu@seismo.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint > In article <501@brl-smoke.ARPA>, rbj@icst-cmr (Root Boy Jim) writes: > > Most People Your's Truly > > > > if (c) { if (c) > > w = y; w = x, > > y = z; y = z; > > } /* look ma, no brace */ > > There is an excellent, excellent book, which everybody should > read, called The Elements of Style, by William Strunk and E. B. > White. It is about writing in English, but almost everything in > it applies to writing in programming languages as well. One of > my favorite quotes (from page 74 of the third edition) is > > "In ordinary composition, use orthodox spelling. Do not > write "nite" for "night," "thru" for "through," "pleez" > for "please," unless you plan to introduce a complete > system of simplified spelling and are prepared to take > the consequences." Attacking me on both fronts, eh? Well GFY! These people are obviously more conservative than I choose to be. After all, don't we hear enuf people screaming about UUCP transmission isn't free? Well, I am just helping out in my own little way :-). What kind of a person would let the way someone spells bother them? You must have awfully thin skin. Worry about something that makes a difference for a change. After all, you *do* understand me don't you? > The consequences, of course, are that in virtually all cases you > will be laughed out of the room. Convention has a place. True. When you start following mine I'll start following yours. For example, I happen to think that all code should be formatted such that all funxions fit on a page. This is a good idea, but one I seldom see adhered to. You're laughing? So what? I'm laughing at you for getting stuck on an insignificant detail. Since you don't have anything real to say, you're attacking the style, not the substance. > You are not being a sheep or a lemming if you do things the way most > people do things; you are being responsible. C can be hard > enough to read when it is formatted "correctly;" we certainly > don't need any more unorthodox methodologies floating around. I didn't make this style up just to be ornery. My whole point is that the delimiting style chosen by the authors of the language left a little something to be desired. Bourne's macros fixed this. And yet, some people complained about them. > Proponents of things like "look ma, no braces" will claim that > theirs is not "ordinary composition," and that they are therefore > exempt from generally accepted programming practices. This > statement is in fact perfectly true. If you want to be a rugged > individualist and program in a vacuum; if nobody else ever reads > your code; if only you have to maintain it or port it to other > machines; then you are certainly welcome to make each program you > write an odds on favorite for the winner's circle in the > Obfuscated C Contest. However, do the rest of us a favor and > perfect your isolated environment by sparing this newsgroup from > your rantings and ravings. Hey, lighten up pal. Most of the `examples' I posted I have given up long ago. Even with the comma trick, sooner or later you're going to want to add a control statement that forces the braces. I just get tired of all you sanctimonious zealots that insist upon quoting the party line on everything. It makes me ornery. You can't please everyone all of the time. And you can't expect people to please you either. All you can do get off on the common ground, while putting aside the (minor & insignificant) differences. I quit trying to please everyone else long ago. That's your job. As for sparing you, I just might do that. I'm getting pretty sick of these discussions and I haven't seen anything new for awhile. > Steve Summit > tektronix!copper!stevesu (Root Boy) Jim Cottrell "You used to laugh about Everybody that was hanging out" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6695 for JMS@ARIZMIS; Mon, 19-MAY-1986 12:46 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015402; 15 May 86 20:07 EDT Received: from brl-vmb.arpa by SMOKE.BRL.ARPA id a005862; 15 May 86 19:29 EDT Date: Thu, 15 May 86 19:17:03 EDT From: Doug Gwyn (VLD/VMB) To: Henry Spencer cc: info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint You seem to have missed a key word in my posting. I urged "a proper job of analysis and design" before coding. A proper job of systems analysis addresses the issues you raised. Structured software development even encourages early hands- on use of prototypes, to REFINE the design, not to try to ARRIVE at a design by trial-and-error. There IS a lot of knowledge about user interaction; like structured software development, however, few practitioners appear to have bothered to study it. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7165 for JMS@ARIZMIS; Mon, 19-MAY-1986 13:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 15:35:50 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016332; 15 May 86 21:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a007034; 15 May 86 21:43 EDT From: Landon Noll Newsgroups: net.lang.c Subject: Re: Obfuscated C Message-ID: <3570@nsc.UUCP> Date: 12 May 86 06:53:03 GMT To: info-c@BRL-SMOKE.ARPA In article woody@juliet.caltech.edu (William E. Woody) writes: > I Like C to be reasonably easy to learn _and_ extremely powerful, as well. >But if we tack on new commands and operators at will, then everyone's program >will be a winner in the Obfuscated C contest! > > - William Woody I agree. Most suggestions of "new-and-improved" C features try to make C into some other language. I was glad to see Ansi-C standard drafts did not go Hog-wild (as in J. Poornelly C) with features, though some of them go too far. When you want to add something to C, ask yourself: Does the power I gain justify the additional complexity of the compiler? Does it break existing C programs? Does it add something that was not already there in another form? Last, consider what this "new" feature will do to the complexity of C source. Consider the potential abuse of the "feature". If 1986's entries any any judge, we nearly have enough of these problems already... chongo /\cc/\ Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7276 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:02 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 15:41:46 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016411; 15 May 86 22:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a007113; 15 May 86 21:45 EDT From: "G.M. Paris" Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <2235@rayssd.UUCP> Date: 11 May 86 18:22:19 GMT Sender: "Gregory M. Paris @ Raytheon Co., Portsmouth RI" To: info-c@BRL-SMOKE.ARPA > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++--------------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++ Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7428 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:05 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 15:50:12 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016417; 15 May 86 22:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a007129; 15 May 86 21:47 EDT From: Bellcore CIM Newsgroups: net.lang.c,net.micro.pc Subject: Microsoft 'C' - Problem with Spawns & Open files Message-ID: <202@pyuxv.UUCP> Date: 12 May 86 00:49:24 GMT Xref: brl-sem net.lang.c:1066 net.micro.pc:1111 To: info-c@BRL-SMOKE.ARPA I'm having a problem using the Microsoft C 3.0 'spawnlp' function with open files in the calling program. (PCDOS-3.1, IBM PC/XT) After returning from the spawn, all file pointers (except stdin,stdout etc) are randomised ! The spawned program does nothing except print 'hello world' & exit. I've tried: a) Using 'system' instead of 'spawn' - no change b) 'dup'ing the relevent file descriptors before the spawn, and trying to restore them afterwards - no change c) Using 'freopen' to reopen the file as the standard input, and then read 'stdin' - no change. The only work-around I've found so far is to do 'ftell's on the files before the function, then 'fseek's afterwards - which, to put it mildly, is a really putrid kludge. Does anyone have a better fix ? Robert Fair. ihnp4!pyuxv!cim2 Bell Communications Research. Piscataway NJ My signature line has given up in disgust & become a COBOL programmer. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7536 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:11 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 16:02:31 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002597; 19 May 86 4:39 EDT Received: from USENET by SMOKE.BRL.ARPA id a002931; 19 May 86 4:14 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Operators for max and min (was: Boolean Operators Slighted in C) Message-ID: <813@bentley.UUCP> Date: 14 May 86 00:05:27 GMT To: info-c@BRL-SMOKE.ARPA In article <2692@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >... to support '/\' and '\/' ( max and min ) ... >#define min(a,b) ((a)\/(b)) >#define max(a,b) ((a)/\(b)) Shouldn't that be the other way around? Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7610 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:19 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002602; 19 May 86 4:40 EDT Received: from USENET by SMOKE.BRL.ARPA id a003004; 19 May 86 4:16 EDT From: " G.R.Tomasevich" Newsgroups: net.lang.c Subject: Shady programming, ignoring return values Message-ID: <371@twitch.UUCP> Date: 12 May 86 13:18:05 GMT To: info-c@BRL-SMOKE.ARPA > w = y; return w = x, > return; As usual, news arrived out of order. Someone else already barfed on this. > Yes, but it all depends on what you're willing to put up with. I find it > terribly ugly having to cast printf's or close's to void. And as What happens if your program is a filter and the printf() return values are trying to tell you something, such as that the disk is full? We have had people do that to us with overnight program runs. Even if your program is not a filter WRT stdout, you might still redirect output, or even stderr also for an overnight run. A 'little output' could become a lot for some pathological reason. -- George Tomasevich, ihnp4!twitch!grt AT&T Bell Laboratories, Holmdel, NJ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7681 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002616; 19 May 86 4:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a003512; 19 May 86 4:33 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <815@bentley.UUCP> Date: 14 May 86 01:42:58 GMT To: info-c@BRL-SMOKE.ARPA In article <866@ttrdc.UUCP> ttrdc!levy (Dan Levy) writes: >Y'know--while I'm thinking about it, why IS malloc() set up to return a >(char *) pointer at all, if that IS inviting a potential (or at least to >lint's little mind) pointer alignment problem? Since malloc() is supposed >to return a maximally aligned pointer, seems to me that it should have >been set up to return a (double *). Yes, yes, before flames of misunder- >standing start, I _KNOW_ that the convention for malloc() is to return >a (char *) and that it returns a maximally aligned pointer just the same >because of the way it has been written. It just seems that the methodology >was back-a**wards, that at least returning a (double *) would indicate an >implicit promise to the user (and to lint-like checking) that the return >value WAS maximally aligned. The only problem I could see with this kind >of scheme is that some systems might not support double. But that could >be gotten around by #defining a malloc_t type that would represent the >maximally aligned data type of the machine at hand. This is what I started to mention once before, and picked up a lot of "no, you don't understand how it works" messages (sigh). I saw the need for a "ALIGN *" datatype, and was hoping "void *" would be it. (Nope, just a useless synonym for "char *"). The idea would be that, just as it's always legal to cast any pointer into a "char *", it would be legal to cast *from* "ALIGN *" to any pointer. Then lint would shut up about malloc()! Also, having malloc() return a real "ALIGN *" would be convenient for word- addressible machines where "char *" requires extra bits. Btw, if I really want to reduce the signal/noise ratio in lint, I use #if lint extern char *cmalloc(); extern int *imalloc(); extern struct foo *fmalloc(); ... #else extern char *malloc(); #define cmalloc(n) ((char *)malloc((n)*sizeof(char)) #define imalloc(n) ((int *)malloc((n)*sizeof(int)) #define fmalloc(n) ((struct foo *)malloc((n)*sizeof(struct foo)) ... #endif Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7791 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 16:23:25 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002620; 19 May 86 4:58 EDT Received: from USENET by SMOKE.BRL.ARPA id a003588; 19 May 86 4:36 EDT From: D Gary Grady Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <1544@ecsvax.UUCP> Date: 12 May 86 17:26:48 GMT To: info-c@BRL-SMOKE.ARPA In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) As several people have pointed out, this convention is used in some languages. I just wanted to point out an instance no one has mentioned yet: IBM's ISPF, a mainframe 3270 screen management package that allows you to define a "panel" with associated procedural information. You find things in the oddest places... -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7722 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 16:15:20 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002614; 19 May 86 4:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a003508; 19 May 86 4:33 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <814@bentley.UUCP> Date: 14 May 86 01:16:50 GMT To: info-c@BRL-SMOKE.ARPA In article <268@valid.UUCP> valid!sbs (Steven Brian McKechnie Sargent) writes: >A Boolean data type distinct from integers clutters the language I disagree. I think an explicit boolean datatype *simplifies* the language. The way I see it, booleans already exist internally. >and removes handy idioms like > foo[x == 0] = bar; I'd guess that would still be legal, just like "float x = 0;". The compiler could know how to convert bool to int. At worst, you could write "(int)" to force it. (I prefer to write "foo[x==0 ? 1 : 0] = bar;", which is no less efficient since that's how the compiler converts the "internal bool" into an int anyway.) >(Vide the "enum" type, which doesn't participate in address arithemtic >either.) I'd like to see a syntax to declare an array which is subscripted by an enum instead of an int. Having to use a cast is a pain. (In the example above, you didn't mean to imply that foo[] would only be indexed by bool, did you? If so, cancel my comment about "?:".) >Arguments that boolean functions make for more efficient implementations >are pretty puny: >> o A function returning a bool could be implemented on some machines by >> setting the condition codes instead of storing a full integer value in >> the return register. >If the caller wants to use the result of the function as a value, rather >than as input to a branching decision, then it must write branches anyway >to set the value appropriately. Result: bigger slower code. No slower than putting the same branch in the called function! Anyway, I suspect that most boolean functions *are* used in a boolean context rather than an integer context. >> >o Multiple flag variables with local scope and no address operator (e.g. >> > variables declared "register bool") could be packed into a single word. >Last I checked, (flags&BOOLEAN_VALUE_OF_MERIT) did what you want. Packing >and unpacking don't come for free, in space or time. "Packing and unpacking" don't need to be done except in an integer context. The boolean operations are single instructions. As for (f&CONST), I'd just like to reduce the ugliness. Cf. bitfields. >** >Builtin functions confuse language implementation with programming >environment implementation; C lives in enough different environments >that this is just plain bad planning. "Inline functions," a la those >of C++, are another matter entirely (although they have been mentioned >repeatedly in discussions of builtin functions). The benefits that >inline functions offer over CPP macros are: simpler cleaner syntax, >more flexibility because they admit arbitrary control structure within, >and avoidance of horrible botches like putchar(*p++). The disadvantage, >at least in my mind, is uncertainty as to what happens to the free >variables of an inline function. Are they bound lexically where the >inline is declared, or are they bound at the point where the inline is >used, assuming the nearest enclosing scope? Consider: [example deleted] I think I agree about builtins. There's no problem with "putchar(*p++)", I believe you're thinking of "putc(c, *fp++)". It's my understanding that "inline" has the same semantics as "static", but is a hint to the compiler; your example may force the compiler to forgo the inline expansion. >** >New operators like "< =" ... I originally mentioned this just to point out that there exist operators which cannot be extended with "op=". The one person who thought it would be useful was confusing it with "MAX=". (Mark Brader has pointed out that B, a sibling* language to C, actually has these operators (spelled "=<", etc.) for completeness. I still think they're useless.) >** >... I have yet to see a feature proposed that fixes a crippling problem of >the language. Do you know of any "crippling problems" that require new features? Anyway, it's useful to keep in mind that much of what is said here (by me, certainly) is not a "proposal", but just an idea to be tossed around in the think tank. As an example of such, here's an idea which I do *not* want to see in the next ANSI draft. In stepping through a linked list (recursive structure), one often writes "p=p->next;". The logic that creates "+=" would suggest that this could be written "p->=next". However, "->" is not really an operator since its right "argument" is not an expression. An alternate notation would be "p=>next", where "=>" is a sort of overstrike between "->" and "=". (I actually had a case once where this would've been useful -- "p" was an expression with side effects!) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint *The original B was a parent language of C; modern B is a sibling. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7851 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:40 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002642; 19 May 86 5:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a003740; 19 May 86 4:40 EDT From: Mike Banahan Newsgroups: net.lang.c Subject: Re: Indentation Message-ID: <995@inset.UUCP> Date: 13 May 86 17:53:21 GMT To: info-c@BRL-SMOKE.ARPA In article <797@bentley.UUCP> kwh@bentley.UUCP writes: (I just pull out the bit that interests me) >In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>I have ranted about C using a one statement model for its control >>statements instead of an explicit end statement. Compound statements are >>bounded by braces instead. Yuk! > >Ah yes, there are two major types of language in the structured family; >f77 with "endif" (some members use "end" for all of "endif", "endwhile", >etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I >presume this is what you dislike. (If it's the spelling that bothers you, >I'm sure you're aware that you can define "begin" and "end" as macros.) > >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) Sorry, you're wrong. Occam uses indentation to show nesting. You *can't* write an incorrectly indented program, because different indent is a different program! (Occam is the parallel language for the Inmos Transputer; it's good fun but boy do you have to re-think those old ideas about sequential execution.) -- Mike Banahan, Technical Director, The Instruction Set Ltd. mcvax!ukc!inset!mikeb Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7914 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:50 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 16:36:08 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a006654; 19 May 86 9:18 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a006448; 19 May 86 8:42 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA23432; Fri, 16 May 86 16:27:51 edt Date: Fri, 16 May 86 16:27:51 edt From: Root Boy Jim Message-Id: <8605162027.AA23432@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, rayssd!gmp@seismo.ARPA Subject: Re: Re: questions from using lint From info-c-request@BRL.ARPA Fri May 16 00:24:39 1986 Received: from BRL-SMOKE.ARPA (brl-smoke.arpa.ARPA) by icst-cmr.ARPA (4.12/4.7) id AA20984; Fri, 16 May 86 00:24:35 edt Received: from USENET by SMOKE.BRL.ARPA id a007113; 15 May 86 21:45 EDT From: "G.M. Paris" Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-Id: <2235@rayssd.UUCP> Date: 11 May 86 18:22:19 GMT Sender: "Gregory M. Paris @ Raytheon Co., Portsmouth RI" To: info-c@brl-smoke.arpa > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++--------------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7998 for JMS@ARIZMIS; Mon, 19-MAY-1986 14:58 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016183; 19 May 86 14:10 EDT Received: from wiscvm.wisc.edu by SMOKE.BRL.ARPA id a015801; 19 May 86 13:50 EDT Received: from (3GTLJHW)CALSTATE.BITNET by WISCVM.WISC.EDU on 05/19/86 at 12:48:18 CDT Date: Mon May 19, 1986 at 10:47 AM PDT From: Joerg Hallbauer <3GTLJHW%CALSTATE.BITNET@wiscvm.ARPA> To: Info-C Subject: Analysis and DEsign >All too often, one sees programmers writing detailed design specifications >before writing any code. This is probably because design specs make it >appear that the problem is fully understood, and give the impression to >management that the rest of the process of implementation will be entirely >mechanical and hence will be on budget and on schedule. Ho ho. Then one >gets to draw up a new budget and schedule for "maintenance", which is the >process of modifying the program so that it really meets the customer's >needs, instead of merely meeting the specification. Sorry, but *I* can't let that one go by. The whole point is doing a careful job of program/system design is so that you WILL understand the problem fully. >The alternative is to recognize that (a) the user probably does not have >a complete and coherent idea of what he needs, and hence cannot write a >spec or meaningfully assess one you write, and (b) in any case, the presence >of the software itself will change the user's tasks and therefore his needs. You are absolutely right, few users have a meaningful or coherent idea of what it is they want. Again this is an good arguement for why you SHOULD do a good job of systems analysis. One of the main tasks that a good analyst does is to help the user make decisions! He guides the user and in that process gets a clear view of exactly what it is the user is trying to do and what the user will expect as a result. This is important not only so that the system will meet the users need when it is delivered, but is also needed in order for the system to be tested properly. The presence of the software only changes the user task's if this has not been discussed with the user. Again a good analyst will expain to the user how the software will impact his working enviroment, and together than can plan with this in mind. >Given recognition of this situation, it is not even theoretically possible >to avoid a trial-and-error process of software development. Hence you >should aim to make your inevitable mistakes as early as possible. Which >uts a heavy premium on getting initial prototype software into the hands >of the customers right away, so that you can learn what's wrong with it. >One progresses by iteratively enhancing (and perhaps sometimes re-doing) >the prototype, with regular user feedback. That's the whole point to systems analysis. Place the interative process at the front of the systems life cycle, NOT at the end! Currently maintenence is the single largest cost in DP today. One of the major reasons that so much time is currently being spent "enhancing" existing software is that when that software was written the people writing it did not have a good understanding of that the user wanted. Discovering what the users needs are is not done in front of a computer terminal writting code, it's done TALKING to the user! Sure in order to full expain some things to the user you may want to do some prototyping, but you certainly don't want to run out and write the entire system and THEN ask the user what he/she thinks. >This is not to say that the design-it-first method doesn't have its uses, >and its advantages, when the problem is understood well enough. But a very >large class of problems -- almost anything to do with user interaction, for >example -- simply don't meet that criterion. You have it exactly backwards! Structured Systems Analysis and design are MOST efective when they are used on large projects that have a great deal of user interaction involved with them. Sudies have shown conclusively that 40+% of the time bugeted for a project whould be spent in analysis and design with the rest divided between coding and testing (with documentation though really having been done as part of the analysis and design taking a couple of percent here too). Joerg Hallbauer Systems Analyst Professional Services Division Control Data Corporation Technical Support Group California State Universities BitNet: 3GTLJHW@CALSTATE ArpaNet: 3GTLJHW%CALSTATE@WISCVM.EDU Phone: (213) 852 - 5087 [ The usual disclaimers apply of course ] Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8181 for JMS@ARIZMIS; Mon, 19-MAY-1986 15:16 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 16:59:08 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002618; 19 May 86 4:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a003516; 19 May 86 4:33 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: builtins and automatic defines Message-ID: <816@bentley.UUCP> Date: 14 May 86 02:01:24 GMT To: info-c@BRL-SMOKE.ARPA In article <1232@utcs.uucp> utcs!flaps (Alan J Rosenthal) writes: >Well I sure hope no one sticks in such a thing without telling me! >Any such #include or #define things should not only be optional, they >should have to be explicit. So perhaps instead of merely beginning every >program with #include , you can also have #include . > >*I* won't #include it, though... They should be semantically identical, so what do you care whether it's optimized by default? I wonder if perhaps (and ) should be included by default, with an explicit "#exclude" to disable. (Cf. "#undef".) Probably tricky to implement -- don't do the automatic "#include" until checking for "#exclude", which must be at the top of the file (after whitespace)? I had much the same attitude when I learned of the (then) new features that allowed structure copy/call-by-value/return-by-value. I wasn't using them (of course, since they were new), and I wanted to see an error if I used one by mistake (forgotten "&"). I was hoping for a compatibility option of some type, like EO in TECO-10. (A nice feature that allowed TECO to simulate an older version of itself, so as not to obsolete all old macros.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8403 for JMS@ARIZMIS; Mon, 19-MAY-1986 15:46 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 17:20:59 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003312; 19 May 86 17:51 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a022042; 19 May 86 17:42 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA03421; Mon, 19 May 86 16:52:48 edt Date: Mon, 19 May 86 16:52:48 edt From: Root Boy Jim Message-Id: <8605192052.AA03421@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, rayssd!gmp@seismo.ARPA Subject: Re: Re: questions from using lint > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint > happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++------------------------------------------------------------------++ Where's the rest of me? I sent out a flame with this, but it must have disappeared. Oh well, here it is: For all of you who have ROT13 software, you will know what to do with this: Tb Shpx Lbhefrys! And for those of you who don't like my spelling, at least it's deliberate. This cretin doesn't even know how to spell `bizarre'. Buddy, I forgot more than you'll ever know. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8786 for JMS@ARIZMIS; Mon, 19-MAY-1986 16:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/19/86 at 18:18:12 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003749; 19 May 86 19:07 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a022422; 19 May 86 18:28 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA03595; Mon, 19 May 86 18:27:32 edt Date: Mon, 19 May 86 18:27:32 edt From: Root Boy Jim Message-Id: <8605192227.AA03595@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Args in Regs >I don't want to quote too much of the original article -- it was rather long. >The thrust of it was that passing parameters in registers doesn't make things >run faster. This does not fit with my experience. When we implemented >parameter passing in registers at Zilog, it was a big win. *WAS* a big win - meaning maybe it looked good on benchmarks... [...] >I will admit that this parameter passing caused difficulties. In particular, >varargs code was messy, and debuggers more difficult to implement. Was it >worth it? I believe so. Our emphasis was on speed, and that we had. 1) pdp-11 style varargs was broken - no way from C to get a those arguments that got crammed into registers. The key phrase here is `pdp-11 style'. No way from C? Just use the variable names! The compiler knows about them. 2) Because of the register assignment scheme used, you couldn't even blindly pass a list of variable arguments to a routine like printf that did know how to deal with them. Why not? And who says varargs has to be written in C? It just may have to be written in assembly some day. 3) setjmp/longjmp got broken with respect to restoring register variable parameters somewhere along the way. Probably difficult, but not impossible. Pyramids seem to work. In the long run, portability seems to have become the more important issue: Just try porting some of the code in mod.sources and net.sources to the machine and see how far you can get without having to go into the editor and start whacking at source code. Assume that software developers will have the same problems porting their wares... Agreed. No one said it would be easy. But then, if it wasn't just a little bit hard, they'd hire your kid sister instead of you. Also, note that Zilog has never delivered its ATT SVID blessed System V port, and that their next series of machines will contain ATT chips running vanilla 3Bx software... Zilog of course has other problems as well. George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3461 for JMS@ARIZMIS; Tue, 20-MAY-1986 07:41 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/20/86 at 09:11:46 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010966; 20 May 86 10:00 EDT Received: from csnet-relay.arpa by SMOKE.BRL.ARPA id a002064; 20 May 86 9:24 EDT Received: from ti-eg by csnet-relay.csnet id a009141; 20 May 86 9:23 EDT Date: Tue, 20 May 86 06:26 ??? From: HARGED%ti-eg.csnet@CSNET-RELAY.ARPA To: info-c%brl-smoke.arpa@CSNET-RELAY.ARPA Subject: abuse from the net Root Boy Jim Non carborundum illegitami ! (Don't let the bastards wear you down !) Joe Richard Hargrove harged%ti-eg@csnet-relay.arpa Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4591 for JMS@ARIZMIS; Tue, 20-MAY-1986 09:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/20/86 at 11:19:34 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014536; 20 May 86 12:04 EDT Received: from USENET by SMOKE.BRL.ARPA id a000350; 20 May 86 11:44 EDT From: "Wayne A. Christopher" Newsgroups: net.lang.c Subject: Re: LINT Message-ID: <323@cad.UUCP> Date: 13 May 86 20:05:09 GMT To: info-c@BRL-SMOKE.ARPA In article <2452@watmath.UUCP>, rbutterworth@watmath.UUCP (Ray Butterworth) writes: > I too used to think that most of what lint complained about was crap. > I also noticed an awful lot of things that it didn't complain about but > should have. So I took the source and turned on all the options that > normally make it shut up about certain things, and then added even more > checks than lint ever had before. Then I looked at all the crap in the > output and gradually taught lint which one's really were crap and > shouldn't be issued. Now I have a version of lint with which I use > four fifths of what it complains about. Sounds great. Can we have it? (Post diffs to net.sources, maybe?) Wayne Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 4547 for JMS@ARIZMIS; Tue, 20-MAY-1986 09:36 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/20/86 at 11:19:20 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014554; 20 May 86 12:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a000410; 20 May 86 11:46 EDT From: "Jonathan P. Leech" Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <479@cit-vax.Caltech.Edu> Date: 14 May 86 09:00:45 GMT Expires: Sender: Followup-To: To: info-c@BRL-SMOKE.ARPA Organization : California Institute of Technology Keywords: In article <815@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: > >This is what I started to mention once before, and picked up a lot of "no, >you don't understand how it works" messages (sigh). I saw the need for a >"ALIGN *" datatype, and was hoping "void *" would be it. (Nope, just a >useless synonym for "char *"). The idea would be that, just as it's always >legal to cast any pointer into a "char *", it would be legal to cast *from* >"ALIGN *" to any pointer. Then lint would shut up about malloc()! > I don't think 'void *' is useless. What do you do on a machine where it's NOT 'always legal to cast any pointer into a "char *"'? I find 'void *' most wonderful and useful in C++. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5084 for JMS@ARIZMIS; Tue, 20-MAY-1986 10:23 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/20/86 at 12:07:13 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015518; 20 May 86 12:45 EDT Received: from USENET by SMOKE.BRL.ARPA id a001529; 20 May 86 12:14 EDT From: "Gary M. Samuelson" Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <640@bunkerb.UUCP> Date: 13 May 86 17:35:00 GMT To: info-c@BRL-SMOKE.ARPA In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >[2] close(), as near as I can tell, can only fail by being handed a number > that does not denote an open file. I usually assume that this error > would have been caught earlier. Assuming a buffered device, the last block of data will not be physically written until close(), in which case nearly all of the errors possible with write() could occur with close(). >[3] unlink() and most other system calls should be checked! (It's too bad > lint can't tell whether you've tested the return value of open(), etc.) ??? Lint certainly can check for that (at least the lint I use); it says something like "open returns value which is sometimes ignored" (or "always", as the case may be). It does this by checking the definition of open() in /usr/lib/lint >"lint returns an error which is always ignored" :-) This is going to my collection of classic quotes. From Jim Cotrl (yes, I know the spelling is wrong, but after all, think of all the keystrokes I saved): >>And as someone pointed out, assignments return a value too, so should we >>cast them to void as well? Oh yeah, assignment is `different'. If I say "a = b", I have clearly used the value of the expression. Gary Samuelson Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5038 for JMS@ARIZMIS; Tue, 20-MAY-1986 10:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/20/86 at 12:01:59 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015462; 20 May 86 12:42 EDT Received: from USENET by SMOKE.BRL.ARPA id a001440; 20 May 86 12:11 EDT From: Kenneth Almquist Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <456@hropus.UUCP> Date: 13 May 86 19:44:33 GMT To: info-c@BRL-SMOKE.ARPA > Yet another convention, not endorsed by any language I know, is to dispense > with the braces and let the indentation alone tell the compiler how to > interpret the program. (I came up with this idea after an argument on the > "correct" place to put the braces.) I first encountered this idea about 8 years ago, when Dave Korn used it in a specialized language for data checking, and it is a good one. Using braces to indicated the structure of a program results in code that is quite difficult to read. (Try removing all indentation from any C program you choose and see how readable the result is.) Of course sensible programmers use indentation to indicate the structure of the program to the reader. So from the reader's point of view braces are just useless clutter. Thus the C language forces the programmer to use two separate methods of indicating the structure of the program, one for the benefit of the reader and the other for the benefit of the compiler. Given that the compilers can fairly easily be written to understand about indentation, there is no justification for requiring programmers to translate the indentation information into brace form by hand, with the attendent risk of errors. Furthermore, Jim has correctly pointed out that the braces actually obscure the code for the human reader, since they add clutter without providing any new information about the program. In fairness, C is better than most languages in this respect since it reduces begin and end to single characters. This is good enough that I do not agree with the extremes to which Jim goes to avoid braces. But C doesn't take the idea to its logical conclusion, which is to eliminate the delimiters entirely. Fortunately, grouping by indentation has finally been adopted by at least on language. See the article on "Modcap" in the March issue of Sigplan Notices. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path) Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1049 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015856; 20 May 86 12:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a002120; 20 May 86 12:29 EDT From: Jim Reid Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <131@stracs.cs.strath.ac.uk> Date: 14 May 86 11:48:57 GMT To: info-c@BRL-SMOKE.ARPA In article <989@dataioDataio.UUCP> bjorn@dataio.UUCP writes: > The state-of-the-art in compilers has progressed on PCs, > so why hasn't anyone come up with a better compiler for > UNIX, or have I just not heard of it? > >For your information I'm running UNIX 4.2bsd with the standard C >compiler on a VAX 11/750, and Datalight C 2.04 on an IBM PC/AT under >MSDOS 3.0. The PC takes 5 minutes 26 seconds to compile 7605 lines of >code in 29 files (plus 735 lines of header in 13 files), whereas the unloaded >VAX (load average 1.13) takes 8 minutes 30 seconds. All the outside >influences were indentical: debugging, optimization, etc. Whoopee! I'm glad someone has proved that an AT - floppy disks and all? - is faster than a VAX. Maybe now I can convince folk it's a good idea to scrap our VAX for an AT!!! :-) :-) :-) :-) :-) Comparisons like that are *totally meaningless* - What about the quality of the generated code? What "optimisations" do the compilers perform? Do both produce much the same symbolic information for debugging? What's involved in linking object modules in the two progams? How many passes over the source code/expanded code/"parse trees" does each compiler do? The 4BSD compiler has at least 5 - 6 if you count linking. First there's the preprocessor, then the compiler proper has probably two passes, the assembler has another two for good measure (depending on how you look at the assembler). Then there's your configuration - how much memory does each system have? How much core does each compiler use/need? How much paging or swapping goes on during compilation? How much disk traffic - intermediate files etc - is done? Granted, your AT compiler might have faster algorithms for symbol table lookup and the like, but the only conclusion that can be drawn from the numbers you gave is that for the conditions you describe, your AT C compiler is faster. It doesn't follow that both compilers or CPUs are doing the same amount of work, so making comparisons or drawing conclusions are pointless. Jim Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0941 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 01:20:19 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015604; 20 May 86 12:47 EDT Received: from USENET by SMOKE.BRL.ARPA id a001541; 20 May 86 12:15 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#8 Message-ID: <1041@hou2d.UUCP> Date: 13 May 86 13:06:56 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Tue, 13 May 86 Volume 16 : Issue 8 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 7 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 7 To: cbosgd!std-c%utcsri # C.4 CONSTANT EXPRESSIONS An expression that evaluates to a constant is required in several * contexts ... More latitude is permitted for initializers {of ob- jects that have static storage duration -->}. # C.5 DECLARATIONS <--O As discussed later, a declaration without a declarator may be <--O used to declare a structure, union, or enumeration tag. Any oth- <--O er kind of declaration without a declarator is also permitted, <--O though without effect. N--> A declaration shall declare at least a declarator, a tag, or the N--> members of an enumeration. # C.5.1 Storage-class specifiers A declaration with storage-class specifier extern indicates that * {-->, if the identifier declared is in fact referred to, then} somewhere in the set of source files that constitutes the entire * program there exists an "external {data --> object} definition" * for the given identifier (a definition with file scope). {--> If the declaration with storage-class specifier extern occurs out- side a function, the identifier is declared with file scope and external linkage, and may itself serve as the required defini- tion, as discussed later.} # C.5.1 Storage-class specifiers <--O Invalid or excess register declarations are treated as auto de- <--O clarations. N--> The implementation may treat any register declaration simply as N--> an auto declaration. # C.5.2.1 Structure and union specifiers N--> The presence of a struct-declaration-list in a struct-or-union- N--> specifier declares a new type. # C.5.2.1 Structure and union specifiers In addition, a member may be declared to consist of a specified * number of bits {--> (including a sign bit, if any)}. Such a member is called a "bit-field" ... * ... {--> An implementation may allocate any addressable storage unit large enough to hold a bit-field.} If enough space remains, * a bit-field that follows another bit-field {is --> shall be} * packed into adjacent bits of the same {int --> unit}. {An imple- mentation may refuse to permit a bit-field to straddle an int boundary, in which case a bit-field that does not fit into the space remaining in an int is put into the next int. --> If insuf- ficient space remains, whether a bit-field that does not fit is put into the next unit is implementation-defined.} The order of * allocation of bit-fields within {an int --> a unit} (high-order to low-order or low-order to high-order) is implementation- defined. # C.5.2.1 Structure and union specifiers N--> A pointer to a structure object, suitably cast, points to its in- N--> itial member or, if it is a bit-field, to the unit in which it N--> resides. N--> ... A pointer to a union object, suitably cast, points to each N--> of its members or, if a member is a bit-field, to the unit in N--> which it resides. # C.5.2.1 Structure and union specifiers N--> There may therefore be unnamed holes within a structure, but not N--> at its beginning {-->, nor more than necessary to achieve the ap- N--> propriate alignment}. # C.5.2.3 Enumeration specifiers * The scope of an enumeration constant {is the same as that of --> begins after its declaration and ends with the scope of} the enumeration of which it is a member. # C.5.2.3 Enumeration specifiers * {--> An object that has an enumeration type behaves like an int in an expression.} The implementation may use the set of values in the enumeration to determine whether to make the effective * type of an enum object a shorter {signed -->} integral type that will promote to int ... # C.5.3 Declarators Remark: Again, the notation [opt] below represents a subscript opt, which means optional. The [] characters not part of [opt] are real [] characters. The {} characters are the usual differ- ence notation of this article. declarator: pointer[opt] declarator2 declarator2: identifier ( declarator ) declarator2 [ constant-expression[opt] ] * declarator2 ( parameter-type-list {[opt] -->} ) * declarator2 ( {parameter-identifier-list[opt] --> identifier-list[opt]} ) <--O ... parameter-identifier-list: <--O identifier-list <--O identifier-list , ... # C.5.3 Declarators * The implementation shall allow at least {six --> 12} pointer, ar- ray, and function declarators (in any combinations) modifying a basic type, either directly or via typedefs. # C.5.3.3 Function declarators {--> (including prototypes)} <--O A parameter identifier list declares only the identifiers of the <--O formal parameters of the function, and may be present in the de- <--O clarator only in a function declaration (#C.7.1). If the list is <--O empty, the function has no parameters. N--> An identifier list declares only the identifiers of the formal N--> parameters of the function. If the list is empty in a function N--> declaration that is not part of a function definition, no infor- N--> mation about the number or types of the parameters is supplied. N--> If the list is empty in a function declaration that is part of a N--> function definition, the function has no parameters. # C.5.4 Type names N--> Empty parentheses in a type name are interpreted as "function N--> with no parameter type information", rather than redundant N--> parentheses around the omitted identifier. # C.5.5 Type definitions and type equivalence <--O In the program fragment <--O typedef float length; <--O /*...*/ <--O { <--O static int length; <--O /*...*/ <--O if the int type specifier were omitted from the second declara- <--O tion, it would be taken to be a (semantically vacuous) declara- <--O tion with type length and no declarators. ------------------------------ End of mod.std.c Digest - Tue, 13 May 86 09:05:58 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1180 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016007; 20 May 86 13:00 EDT Received: from USENET by SMOKE.BRL.ARPA id a002186; 20 May 86 12:31 EDT From: mnl Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C (really swap with XOR) Message-ID: <314@cernvax.UUCP> Date: 16 May 86 02:11:08 GMT To: info-c@BRL-SMOKE.ARPA In article <2741@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <602@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > >>3) Exchange operator. This has probably been discussed before, so pardon >> me if I blunder into that pit. BUT, DMR has stated that one of >> the reasons that exponentiation was left out was because no >> (or few, if any) machine could do it inline, and therefore >> all the compiler would be doing is a function call anyway. >> By the same reasoning, exchange CAN be done efficiently by >> some machines, and the hack of a temporary variable and >> three assignments is a rather stale idiom. The three >> statement XOR trick avoids the temporary, at the expense >> of execution time and clarity. >> >Good stuff. Even machines without an EXG can use a scratch register, which >is better than using a user-supplied temp. >What, by the way, is the XOR trick? > To swap the contents of A and B (no particular language): A = A XOR B B = A XOR B A = A XOR B On some machines, assuming A and B are in registers, this won't take any more time than the normal three assignments using a temporary. -- Mark Nelson mnl@cernvax.bitnet or ...!seismo!mcvax!cernvax!mnl If the ACM had a sub-group for naturalists, would it be ACM SIGnature? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1457 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:42 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a017256; 20 May 86 13:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a003749; 20 May 86 13:04 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#10 Message-ID: <1043@hou2d.UUCP> Date: 13 May 86 13:10:39 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Tue, 13 May 86 Volume 16 : Issue 10 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 9 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 9 To: cbosgd!std-c%utcsri # {C.8.3 --> C.8.1} Conditional inclusion Preprocessing directives of the forms # if constant-expression new-line group[opt] * {--> # elif constant-expression new-line group[opt]} check whether the controlling constant expression evaluates to non-zero. # {C.8.3 --> C.8.1} Conditional inclusion Each directive's condition is checked in order. If it evaluates * to false (0), the {program text that follows it --> group that it * controls} is skipped ... The first {section of program text --> group} whose control condition evaluates to true (non-zero) is processed. If none of the conditions evaluates to true, and * there is a #else directive, the {program text between the #else and the #endif --> group controlled by the #else} is processed; * lacking a #else directive, all the {program text through --> groups until} the #endif are skipped. # {C.8.1 --> C.8.2} Source file inclusion N--> The character sequence in the form of preprocessing directive N--> # include new-line N--> shall not include a > character. The character sequence in the N--> form of preprocessing directive N--> # include "x-char-sequence" new-line N--> shall not include a " character. # {C.8.1 --> C.8.2} Source file inclusion The named source file is searched for in association with the * {--> original} source file {containing the #include directive * -->}. {This implementation-defined capability presumes that oth- er named source files may be associated in some way with the source file containing the text being read, typically by means of a file system with named files organized into "directories". -->} * If this {--> implementation-defined} capability is not supported ... # {C.8.1 --> C.8.2} Source file inclusion * Failure in processing a #include directive is {an error --> equivalent to a violation of a syntax rule}. # {C.8.2 --> C.8.3} Macro replacement * The arguments in the invocation are {--> (possibly empty)} se- quences of tokens separated by comma tokens ... # {C.8.2 --> C.8.3} Macro replacement Each occurrence in the definition of a formal parameter is re- * placed by the corresponding argument from the invocation {-->, with all macros replaced in each argument}. # {C.8.2 --> C.8.3} Macro replacement If a formal parameter in the definition follows a # token, both are replaced by the corresponding argument from the invocation, preceded and followed by a double-quote character to create a * string literal. {--> Whether} white space between tokens in the * argument {may be --> is retained in the string or} replaced by a * single space character {--> is implementation-defined}. White space preceding the first token or following the last token is * deleted. {--> A backslash character is inserted before each double-quote character in the argument.} # {C.8.2 --> C.8.3} Macro replacement * A macro definition lasts ... {--> until a corresponding #undef directive is encountered or (if none is encountered)} until the end of the source file ... # {C.8.2 --> C.8.3} Macro replacement The replacement token sequence is reexamined for more macro names * {-->, which are themselves replaced and rescanned}. # {C.8.2 --> C.8.3} Macro replacement After all replacements have taken place, each instance in the de- * finition of a ## {token --> operator} is deleted, and the tokens * preceding and following it are concatenated. {--> If the result is not a valid token, the behavior is undefined.} # C.8.4 Line control <--O The predefined macro name __LINE__ has the value of the line <--O number of the current source line (a decimal constant). The <--O predefined macro name __FILE__ has the value of the presumed name <--O of the source file (a string literal). # {--> C.8.7 Predefined macro names} N--> The following macro names shall be defined by the implementation N--> prior to the beginning of translation: N--> __LINE__ The line number of the current source line (a decimal N--> constant). N--> __FILE__ The presumed name of the source file (a string N--> literal). N--> __DATE__ The date of translation of the source file as a N--> string literal of the form "Mmm dd yyyy", where the N--> names of the months are the same as those generated N--> by the asctime function. N--> __TIME__ The time of translation of the source file as a N--> string literal of the form "hh:mm:ss". N--> No other macro names shall be predefined. N--> Forward references: the asctime function (#D.12.3.1). # {--> C.9 FUTURE DIRECTIONS} # {--> C.9.1 Character escape sequences} N--> Lower-case letters as escape sequences are reserved for future N--> standardization. Other characters may be used in extensions. # {--> C.9.2 Function declarations} N--> The use of function declarations with empty parentheses (not N--> prototype-format parameter-type declarations) is deprecated. # {--> C.9.3 Function definitions} N--> The use of function definitions with separate parameter identif- N--> ier and declaration lists (not prototype-format parameter type N--> and identifier declarations) is deprecated. ------------------------------ End of mod.std.c Digest - Tue, 13 May 86 09:09:55 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1573 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a017748; 20 May 86 13:53 EDT Received: from USENET by SMOKE.BRL.ARPA id a004161; 20 May 86 13:11 EDT From: Guy Harris Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <3674@sun.uucp> Date: 14 May 86 19:36:49 GMT To: info-c@BRL-SMOKE.ARPA > I saw the need for a "ALIGN *" datatype, and was hoping "void *" would > be it. (Nope, just a useless synonym for "char *"). The idea would > be that, just as it's always legal to cast any pointer into a "char *", > it would be legal to cast *from* "ALIGN *" to any pointer. Then lint > would shut up about malloc()! No, you just don't understand how it works. From the August 11, 1985 C standard draft: C.2.2.3 Pointers A pointer to "void" may be converted to a pointer to an object of any type. A pointer to an object of any type may be converted to a pointer to "void" or to a pointer to an object of less strict alignment and back again without change. Nowhere is it implied that "void *" is a synonym for "char *". "lint" should not give any complaints about conversions between pointers of other types and pointers to "void" (this isn't stated in the C draft, but then again it's not a description of "lint", it's a language standard). As such, it is not a synonym for "char *", since "lint" should (and does) complain about conversions between "char *" and other pointers. As the C draft clearly states, it is legal to cast *from* "void *" to any pointer; as such, if "malloc" is declared to return "void *", "lint" will shut up about it. No, the language does not *guarantee* that a "void *" is properly aligned, but there's no way for it to do so anyway. Big deal. The language couldn't *guarantee* that an "ALIGN *" is properly aligned either - if you wrote "malloc" in C (as all UNIX implementations I know of are written), you would just have to trust that the implementation delivers a maximally-aligned pointer. As such, "ALIGN *" is just a useless synonym for "void *". > Also, having malloc() return a real "ALIGN *" would be convenient for word- > addressible machines where "char *" requires extra bits. Maybe, but I'm not sure the added convenience of having "malloc" be able to return a value of a type requiring fewer bits is sufficient to justify adding another type to the language. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1355 for JMS@ARIZMIS; Wed, 21-MAY-1986 00:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 01:58:38 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa16648; 20 May 86 13:22 EDT Received: from USENET by SMOKE.BRL.ARPA id a003743; 20 May 86 13:04 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#9 Message-ID: <1042@hou2d.UUCP> Date: 13 May 86 13:09:47 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Tue, 13 May 86 Volume 16 : Issue 9 Today's Topics: Differences from April 1985 to February 1986 Draft Standard, Part 8 ---------------------------------------------------------------------- Date: Sun, 27 Apr 86 01:17:06 est From: Subject: Differences from April 1985 to February 1986 Draft Standard, Part 8 To: cbosgd!std-c%utcsri # C.5.6 Initialization <--O A declarator may include an initializer that specifies an initial <--O value for the object whose identifier is being declared. <--O ... Any object may be initialized. N--> Any declaration that defines an object may include an initializer N--> that specifies its initial value. # C.5.6 Initialization N--> Initializers that are neither flat (no interior brackets) nor N--> fully bracketed are ambiguous. ***> The draft shall specify the N--> correct category for this situation. <*** Remark: In other words, they haven't decided. # C.6 STATEMENTS <--O Completion of the execution of a statement is a sequence point. <--O Forward references: compound statement, or block (#C.6.2), func- <--O tion definitions (#C.7.1). N--> A "full expression" is an expression that is not part of another N--> expression. Each of the following is a full expression: an ini- N--> tializer of an object that has automatic storage duration; the N--> expression in an expression statement; the controlling expression N--> of a selection statement (if or switch); the controlling expres- N--> sion of an iteration statement (while, do, or for). Completion N--> of the evaluation of a full expression is a sequence point. N--> Forward references: expression and null statements (#C.6.3), N--> selection statements (#C.6.4), iteration statements (#C.6.5). # C.6.2 Compound statement, or block * An object declared extern {--> inside a block} shall not be ini- * tialized in the declaration, as storage for it is {allocated --> defined} elsewhere. # C.6.4.1 The if statement * If the first substatement is reached via a {named -->} label, the second substatement is not executed. # C.6.4.2 The switch statement <--O The implementation must allow at least 255 case values in a <--O switch statement. N--> As discussed previously (#B.2.4), the implementation may limit N--> the number of case values in a switch statement. # C.6.6.3 The break statement N--> A break statement may appear only in a switch body or loop body. # C.6.6.4 The return statement N--> A return statement with an expression may not appear in a func- N--> tion declared as returning type void. # C.6.6.4 The return statement Reaching the } that terminates a function is equivalent to exe- * cuting a return {with no returned value --> statement without an expression}. # C.7.1 Function definitions <--O The following constraints apply only to a parameter identifier <--O list. Only the identifiers in the parameter list may be declared <--O in the declaration list. An identifier declared as a typedef <--O name must not be redeclared as a formal parameter. N--> Even if the type specifier is a typedef name that declares the N--> function as having no parameters, the parentheses that bound the N--> (empty) parameter identifier list may not be omitted from the de- N--> clarator. N--> The only storage-class specifier allowed in the declaration of a N--> formal parameter is register. N--> If the declarator is a function prototype declarator, no declara- N--> tion list may follow. If the declarator is an identifier list, N--> only the identifiers it names may be declared in the declaration N--> list; an identifier declared as a typedef name shall not be rede- N--> clared as a formal parameter. # C.7.1 Function definitions If a function prototype is in scope when the function is defined * {, --> but} a semantically equivalent prototype {must be --> is * not} in scope everywhere the function is called {-->, the * behavior is undefined}. {--> If a function that accepts a vari- able number of arguments is defined without the ellipsis notation in its prototype, the behavior is undefined.} If no function prototype is in scope when the function is de- * fined, the {following -->} default {--> argument} conversions are * {--> assumed to have been} applied {--> to each call}. ... # C.8 PREPROCESSING DIRECTIVES Remark: The subsections C.8.1 through C.8.3 have been reordered, and all the syntax rules have been collected at the beginning of section C.8. # C.8 PREPROCESSING DIRECTIVES Remark: Again, the notation [opt] below represents a subscript opt, which means optional. N--> preprocessing-file: N--> group N--> preprocessing-file group N--> group: N--> group-part N--> group group-part N--> group-part: N--> tokens[opt] new-line N--> if-section N--> control-line * {token-sequence --> tokens}: token * {token-sequence --> tokens} token N--> if-section: N--> if-group elif-groups[opt] else-group[opt] endif-line N--> if-group: N--> # if constant-expression new-line group[opt] N--> # ifdef identifier new-line group[opt] N--> # ifndef identifier new-line group[opt] N--> elif-groups: N--> elif-group N--> elif-groups elif-group N--> elif-group: N--> # elif constant-expression new-line group[opt] N--> else-group: N--> # else new-line group[opt] N--> endif-line: N--> # endif new-line * {--> control-line:} * # include { --> } new-line * # include {"s-char-sequence" --> "x-char-sequence"} new-line # include identifier new-line * # define identifier {token-sequence --> tokens}[opt] new-line # define identifier lparen identifier-list[opt] * {token-sequence --> tokens}[opt] ) new-line # undef identifier new-line # line digit-sequence string-literal[opt] new-line # pragma x-char-sequence new-line # new-line Remark: In the above syntax for "control-line", each entry begin- ning with # is supposed to be written on one line. The multiple lines in this document represent continuations rather than alter- natives. x-char-sequence: x-char x-char-sequence x-char x-char: any character in the source character set except the new-line character Remark: An "s-char-sequence", which was used in the old version, is defined in #C.1.4; it is whatever can be between the double- quotes of a string literal. N--> lparen: N--> the left-parenthesis character without preceding N--> white-space new-line: the new-line character <--O A preprocessing directive may appear anywhere. It is terminated <--O by the next new-line character, which is not considered to be <--O part of the directive. <--O There may be any number of space and horizontal-tab characters <--O between the # token and the identifier that constitutes the next <--O token, and before the new-line character that terminates the <--O directive. N--> In this phase of processing, tokens may be separated by any N--> number of space and horizontal-tab characters. ------------------------------ End of mod.std.c Digest - Tue, 13 May 86 09:09:25 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. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1679 for JMS@ARIZMIS; Wed, 21-MAY-1986 01:09 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018547; 20 May 86 14:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a006021; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: More extensions to C (was: Boolean Operators Slighted in C) Message-ID: <826@bentley.UUCP> Date: 16 May 86 03:15:56 GMT To: info-c@BRL-SMOKE.ARPA In article <2741@utcsri.UUCP> greg@utcsri.UUCP writes: >In article <602@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>3) Exchange operator. ... > >Good stuff. Even machines without an EXG can use a scratch register, which >is better than using a user-supplied temp. This could be considered a special case of my ",," operator: to exchange x and y, write "x = (y ,, (y = x))". >What, by the way, is the XOR trick? "x ^= y; y ^= x; x ^= y;". Not useful for floats or structs. >>5) Allow immediate constants. [Generalization of quoted strings.] >>... Why not int *p = &5 ... Does "&5" point to a character, short, int, unsigned, or long constant? (No fair using the left side of the assignment to disambiguate!) >I would also like to suggest struct constants/rvalues. Suppose I have > struct foo{ int f1; char f2; char *bar; } foo_var; >I'd like to write something like this ( an executable statement ): > foo_var = struct foo{ .bar = "Ergo Sum"; .f1 = 73; .f2 = '?'; }; > >This allows the use of unnamed (structure constants). ... I think it is >important that the member names be used instead of the order. Yes, because then you could use unions too. In fact, a similar notation would allow the compile-time initialization of a union, something I've wanted for some time. (I hear ANSI wants to use the first member of the union for initializations. Sorry folks, I want to initialize an array[2] of union {int;char*} to { {12}, {"foo"} }.) >Also, it would be nice if the compiler were smart in cases like > xchar = struct foo{ .bar="??"; .f2 = ychar+1; .f1 = func(i); }.f2; >not to generate all the code to compute f1 and bar ( Holy side-effects, >Batman! ). The above line could arise by a macro expansion. Umm... I think it's better if the compiler does include the call to func(). The constant assignment to ".bar" can be optimized out, of course, and the structure itself need not exist. (xchar = (void)func(i),ychar+1) >>6) Eliminate arrays altogether! You want to take them *out* of the language? I say let's put them *in*! As it stands, arrays are half-implemented. >>And it wouldn't matter whether a variable was defined differently than it >>was declared (char x[] or char *x). I don't get it. If "char *x" is valid for all array/pointer variables, where does the memory come from, malloc()? >>8) Allow formal arguments to be declared AFTER the opening brace. >> This would allow prioritization of register variables. >> >Well, register arguments need to copied from the stack anyway, so >you can declare your own with an explicit copy. But it wouldn't >hurt to let the compiler do it. Since it silly ( presently ) to >say `foo(p){ register char *p;...' this could be taken as an argument >declaration. > >I have a related suggestion. > >Suppose I have the following: > >f(){ > ... > { int x,y; ... } > { double xy; ... } >} >I would expect x and y to share the same stack space with xy. >Now look at this ( assume 4 regs available ): > >f(){ register i,j,k,l,m; /* more vars than regs available */ > { register ii ..... }; >} >I think the inner loop should push 'l' ( the lowest priority reg var ) on >the stack and keep 'ii' in that reg, since ii will probably get more use >in the inner block. The register priority would become ii/i/j/k, so if >a further nested block said 'register a,b', the next regs to be kicked out >would be j and k, leaving the priority as a/b/ii/i. >At the end of the block, the value of l would be popped. If the block were >the body of a loop, the pushing/popping would need to be done outside the >actual loop, for speed. Inside the loop, of course, 'l' would be addressed >as an auto. > >This allows C programmers one more advantage previously available only to >assembler programmers: the re-use of registers for completely different >things. The problem is that it would make jumping into/out of blocks a >mess. I guess the compiler would have to detect this and generate 'fix' >code for the jumps. (Sorry I had to quote so much here.) This has *nothing* to do with the C language; we are now in the realm of compiler implementation. Here's a counter-proposal: compilers should allocate registers based on the last declaration instead of the first. (This is quite legal; "register" has no guaranteed semantics.) In the above example, i and j would be auto, while k, l, m, and ii would be register. No need to save registers in the middle of a function. Better yet, Let's make the compilers smart enough to allocate registers on their own, and make the "register" keyword obsolete! (DEC did this.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2212 for JMS@ARIZMIS; Wed, 21-MAY-1986 01:51 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018588; 20 May 86 14:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a006028; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <827@bentley.UUCP> Date: 16 May 86 03:18:39 GMT To: info-c@BRL-SMOKE.ARPA In article <1776@sdcsvax.UUCP> hutch@sdcsvax.UUCP writes: >well now for ||= you can use |= ... I think the intent was that "v ||= e" would not evaluate e if v were already true. (Same as "v = v || e".) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2144 for JMS@ARIZMIS; Wed, 21-MAY-1986 01:53 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 03:35:02 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018547; 20 May 86 14:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a006021; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: More extensions to C (was: Boolean Operators Slighted in C) Message-ID: <826@bentley.UUCP> Date: 16 May 86 03:15:56 GMT To: info-c@BRL-SMOKE.ARPA In article <2741@utcsri.UUCP> greg@utcsri.UUCP writes: >In article <602@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>3) Exchange operator. ... > >Good stuff. Even machines without an EXG can use a scratch register, which >is better than using a user-supplied temp. This could be considered a special case of my ",," operator: to exchange x and y, write "x = (y ,, (y = x))". >What, by the way, is the XOR trick? "x ^= y; y ^= x; x ^= y;". Not useful for floats or structs. >>5) Allow immediate constants. [Generalization of quoted strings.] >>... Why not int *p = &5 ... Does "&5" point to a character, short, int, unsigned, or long constant? (No fair using the left side of the assignment to disambiguate!) >I would also like to suggest struct constants/rvalues. Suppose I have > struct foo{ int f1; char f2; char *bar; } foo_var; >I'd like to write something like this ( an executable statement ): > foo_var = struct foo{ .bar = "Ergo Sum"; .f1 = 73; .f2 = '?'; }; > >This allows the use of unnamed (structure constants). ... I think it is >important that the member names be used instead of the order. Yes, because then you could use unions too. In fact, a similar notation would allow the compile-time initialization of a union, something I've wanted for some time. (I hear ANSI wants to use the first member of the union for initializations. Sorry folks, I want to initialize an array[2] of union {int;char*} to { {12}, {"foo"} }.) >Also, it would be nice if the compiler were smart in cases like > xchar = struct foo{ .bar="??"; .f2 = ychar+1; .f1 = func(i); }.f2; >not to generate all the code to compute f1 and bar ( Holy side-effects, >Batman! ). The above line could arise by a macro expansion. Umm... I think it's better if the compiler does include the call to func(). The constant assignment to ".bar" can be optimized out, of course, and the structure itself need not exist. (xchar = (void)func(i),ychar+1) >>6) Eliminate arrays altogether! You want to take them *out* of the language? I say let's put them *in*! As it stands, arrays are half-implemented. >>And it wouldn't matter whether a variable was defined differently than it >>was declared (char x[] or char *x). I don't get it. If "char *x" is valid for all array/pointer variables, where does the memory come from, malloc()? >>8) Allow formal arguments to be declared AFTER the opening brace. >> This would allow prioritization of register variables. >> >Well, register arguments need to copied from the stack anyway, so >you can declare your own with an explicit copy. But it wouldn't >hurt to let the compiler do it. Since it silly ( presently ) to >say `foo(p){ register char *p;...' this could be taken as an argument >declaration. > >I have a related suggestion. > >Suppose I have the following: > >f(){ > ... > { int x,y; ... } > { double xy; ... } >} >I would expect x and y to share the same stack space with xy. >Now look at this ( assume 4 regs available ): > >f(){ register i,j,k,l,m; /* more vars than regs available */ > { register ii ..... }; >} >I think the inner loop should push 'l' ( the lowest priority reg var ) on >the stack and keep 'ii' in that reg, since ii will probably get more use >in the inner block. The register priority would become ii/i/j/k, so if >a further nested block said 'register a,b', the next regs to be kicked out >would be j and k, leaving the priority as a/b/ii/i. >At the end of the block, the value of l would be popped. If the block were >the body of a loop, the pushing/popping would need to be done outside the >actual loop, for speed. Inside the loop, of course, 'l' would be addressed >as an auto. > >This allows C programmers one more advantage previously available only to >assembler programmers: the re-use of registers for completely different >things. The problem is that it would make jumping into/out of blocks a >mess. I guess the compiler would have to detect this and generate 'fix' >code for the jumps. (Sorry I had to quote so much here.) This has *nothing* to do with the C language; we are now in the realm of compiler implementation. Here's a counter-proposal: compilers should allocate registers based on the last declaration instead of the first. (This is quite legal; "register" has no guaranteed semantics.) In the above example, i and j would be auto, while k, l, m, and ii would be register. No need to save registers in the middle of a function. Better yet, Let's make the compilers smart enough to allocate registers on their own, and make the "register" keyword obsolete! (DEC did this.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 2305 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:00 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018629; 20 May 86 14:22 EDT Received: from USENET by SMOKE.BRL.ARPA id a006036; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <828@bentley.UUCP> Date: 16 May 86 03:26:56 GMT To: info-c@BRL-SMOKE.ARPA In article <287@euclid.warwick.UUCP> warwick!steve writes: >Couldn't you write a small(?) filter which would let you write C >without braces and fill them in for you from the indentation? It >doesn't seem too difficult. (No I'm not offering to do it). I almost wrote such a filter when I first got this idea, but there wasn't enough interest. No, it isn't difficult -- a short awk script could do it, I think. I guess for continuation lines you'd have to either start flush with the previous line, or use a continuation character (backslash). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2346 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018684; 20 May 86 14:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a006041; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: Indentation Message-ID: <829@bentley.UUCP> Date: 16 May 86 03:31:57 GMT To: info-c@BRL-SMOKE.ARPA In article <995@inset.UUCP> inset!mikeb (Mike Banahan) writes: >In article <797@bentley.UUCP> kwh@bentley.UUCP writes: >>Yet another convention, not endorsed by any language I know, is to dispense >>with the braces... > >Sorry, you're wrong. Occam uses indentation to show nesting. ... No, I was right. Occam is not "a language I know". Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Okay, maybe I should've added a "that".) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2386 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:10 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018756; 20 May 86 14:26 EDT Received: from USENET by SMOKE.BRL.ARPA id a006054; 20 May 86 13:55 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <830@bentley.UUCP> Date: 16 May 86 03:43:01 GMT To: info-c@BRL-SMOKE.ARPA In article <640@bunkerb.UUCP> bunkerb!garys (Gary Samuelson) writes: >In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>(It's too bad lint can't tell whether you've tested the return value of >>open(), etc.) > >??? Lint certainly can check for that (at least the lint I use); it says >something like "open returns value which is sometimes ignored" By "open(), etc." I meant the class a functions which return a useful value even when they succeed. For example, lint does *not* catch the following: fp = fopen(fname, "r"); c = getc(fp); which is a potential error because fopen() could return NULL. Trouble is, even if lint knew that fopen had such an error return, it would have to know whether getc() is prepared to handle it (it isn't). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2433 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:14 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018802; 20 May 86 14:28 EDT Received: from USENET by SMOKE.BRL.ARPA id a006096; 20 May 86 13:56 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <831@bentley.UUCP> Date: 16 May 86 03:49:39 GMT To: info-c@BRL-SMOKE.ARPA In article <479@cit-vax.Caltech.Edu> cit-vax!jon writes: > I don't think 'void *' is useless. What do you do on a machine >where it's NOT 'always legal to cast any pointer into a "char *"'? You get a compiler that works. The proposed property of "void *" is already guaranteed for "char *". (Sorry, no K&R handy, can't quote it.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2486 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:19 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a018816; 20 May 86 14:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a006105; 20 May 86 13:57 EDT From: "Peter S. Shenkin" Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <473@cubsvax.UUCP> Date: 15 May 86 17:09:10 GMT To: info-c@BRL-SMOKE.ARPA In article peter@baylor.UUCP writes: >> One of the more traumatic things about being exposed to unix after working >> with numerous other systems was that the stupid c compiler refused to give me >> a nice clean listing with source, interspersed error messages, and optional >> object code. I'm not dumb, but trying to learn a debug a big program though >> a 24-line window and my memory just doesn't make it... > >On the other hand, I found VAX/VMS 'C' a real pain after UNIX because it >put all the error messages in this huge ugly listing instead of a brief >list so I could find them. Of course the stupid bloody editor that didn't >have a shell escape or any sort of facility for editing multiple files >didn't help. What I'm waiting for is an interactive interpretive debugger that runs from vi. The program would run interpretively until an error was encountered, then place you at the appropriate line in the source file with the error message displayed. Then you could go into insert mode, make the necessary change, and resume execution. Normally interpreted languages, like APL, often have such facilities. Are there insuperable difficulties with doing this with a normally compiled language like C? (I'm sure it could be done with FORTRAN, since FORTRAN interpreters are well-known... but why have we seen no C interpreters?) Seems to me a few years ago some people on the net from Harvard were trying to implement this concept or one similar to it. Whatever happened? Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2543 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa21414; 20 May 86 16:00 EDT Received: from brl-vgr.arpa by SMOKE.BRL.ARPA id a008836; 20 May 86 15:49 EDT Received: from [128.39.1.2] by VGR.BRL.ARPA id aa01658; 20 May 86 15:32 EDT Date: Wed, 14 May 86 14:22:49 -0200 From: Stein-Erik Engbr}ten Posted-Date: Wed, 14 May 86 14:22:49 -0200 Message-Id: <8605141222.AA04921@nta-vax.ARPA> Received: by nta-vax.ARPA (5.31/3.21) id AA04921; Wed, 14 May 86 14:22:49 -0200 To: info-c@BRL.ARPA Subject: No booleans? >THERE IS NO SUCH THING AS A BOOLEAN DATA TYPE (to which Doug Gwyn will >reply `there is no such thing as an integer either :-). There may be >boolean OPERATORS, but their range and domain is integers. I hope this '...NO SUCH THING...' is a statement regarding C only! Stein-Erik Engbr}ten Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2620 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:32 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 04:20:57 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023795; 20 May 86 18:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a013595; 20 May 86 18:26 EDT From: Tainter Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <1918@ihlpg.UUCP> Date: 15 May 86 15:04:48 GMT To: info-c@BRL-SMOKE.ARPA >>>And as someone pointed out, assignments return a value too, so should we >>>cast them to void as well? Oh yeah, assignment is `different'. >If I say "a = b", I have clearly used the value of the expression. > Gary Samuelson No. You have only used the value of the expression "b", not the expression "a = b" (which happens, by definition, to return the value of the expression "b"). The argument stands. The principle behind ignoring, even meaningful, return codes is: I don't have any particular response to this error so I will fall back on whatever default error handling the system provides. Admittedly, this is not the desired response when what is being written is a general tool. ROBUSTNESS provides GENERALITY but costs DEVELOPMENT TIME. --j.a.tainter Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2684 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:43 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023973; 20 May 86 19:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a013910; 20 May 86 18:37 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <835@bentley.UUCP> Date: 19 May 86 15:29:49 GMT To: info-c@BRL-SMOKE.ARPA In article <3674@sun.uucp> sun!guy writes: [bentley!kwh writes:] >> I saw the need for a "ALIGN *" datatype, and was hoping "void *" would >> be it. (Nope, just a useless synonym for "char *"). The idea would >> be that, just as it's always legal to cast any pointer into a "char *", >> it would be legal to cast *from* "ALIGN *" to any pointer. Then lint >> would shut up about malloc()! > >No, you just don't understand how it works. From the August 11, 1985 C >standard draft: > > C.2.2.3 Pointers > > A pointer to "void" may be converted to a pointer to an > object of any type. A pointer to an object of any type may be > converted to a pointer to "void" or to a pointer to an object > of less strict alignment and back again without change. > >Nowhere is it implied that "void *" is a synonym for "char *". Since sizeof(char) == 1 (I believe that's now a guaranteed rule rather than merely "true in all known implementations", right?), it has the least strict alignment. Thus your last quoted sentence implies that "char *" can also hold a pointer of any type, and restore it unchanged. And to even attempt to restore it means that "char *" must meet the first property as well. So, although not necessarily synonyms, they do have the same properties, except that "char *" conversions usually require a cast to be acceptable. >No, the language does not *guarantee* that a "void *" is properly aligned, >but there's no way for it to do so anyway. Big deal. The language couldn't >*guarantee* that an "ALIGN *" is properly aligned either... What I had in mind was that "ALIGN *" would be a synonym for "int *" or whatever happens to be the most restrictive pointer type. The "guarantee" would be as good as the "guarantee" on an "int *". >> Also, having malloc() return a real "ALIGN *" would be convenient for word- >> addressible machines where "char *" requires extra bits. > >Maybe, but I'm not sure the added convenience of having "malloc" be able to >return a value of a type requiring fewer bits is sufficient to justify >adding another type to the language. Well, what *is* the justification for adding "void *" to the language? To allow people to shove pointers around without casts? (Shudder!) To make lint shut up about malloc()? Or just to distinguish "generic pointers" from pointers that can be dereferenced? (Could be done with a typedef. So could "void", but they put it in anyway.) I do not strongly object to the addition of "void *", but I am worried about it "hiding" errors. (I'm one of those purists who thinks that programmers *should* use casts to change types.) Also, it's a misnomer; it has nothing to do with "void". Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2745 for JMS@ARIZMIS; Wed, 21-MAY-1986 02:49 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023983; 20 May 86 19:10 EDT Received: from USENET by SMOKE.BRL.ARPA id a013916; 20 May 86 18:38 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Comma and semicolon Message-ID: <836@bentley.UUCP> Date: 19 May 86 15:46:03 GMT To: info-c@BRL-SMOKE.ARPA In article <118@danews.UUCP> danews!lvc writes: > printf("usage: foo bar\n") , return 1 ; >seems reasonably "within C's style". Comments ? It would've been nice if the "," operator and the ";" separator had been the same token, but they aren't. They happen to be interchangeable in one instance (both sides statement-expressions, and not the body of an if/else/ while/do/switch without braces), that's all. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4922 for JMS@ARIZMIS; Wed, 21-MAY-1986 07:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 09:09:38 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023994; 20 May 86 19:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a013924; 20 May 86 18:38 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: using indentation rather than braces Message-ID: <838@bentley.UUCP> Date: 19 May 86 16:09:45 GMT To: info-c@BRL-SMOKE.ARPA In article <968@umd5.UUCP> umd5!zben (Ben Cranston) writes: >Forgive me if this is too obvious to mention, but it seems to me that using >the indentation information makes life much harder for programs like YACC >and LEX that act by creating C source code. Now they have to keep track of >what column they are outputting to... Slightly harder, but still not all that difficult. Instead of outputting a left brace, the program increments a variable; instead of a right brace, it decrements. Then each output line is preceded by that many blanks. Of course, I'm assuming some support would be built into yacc and lex. They would automatically add the indentation level of your code blocks to that of the automatically-generated blocks. Btw, how would such a language interpret a one-liner like "if (c) a; b;"? Would that be "if (c) {a;} b;" or "if (c) {a; b;}" or just illegal? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5204 for JMS@ARIZMIS; Wed, 21-MAY-1986 07:58 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024053; 20 May 86 19:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a014193; 20 May 86 18:48 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <5462@alice.uUCp> Date: 15 May 86 13:29:46 GMT To: info-c@BRL-SMOKE.ARPA > I don't think 'void *' is useless. What do you do on a machine > where it's NOT 'always legal to cast any pointer into a "char *"'? You don't implement C on it. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 5261 for JMS@ARIZMIS; Wed, 21-MAY-1986 09:34 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024253; 20 May 86 19:35 EDT Received: from USENET by SMOKE.BRL.ARPA id a014368; 20 May 86 18:55 EDT From: bright%dataio.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <996@dataioDataio.UUCP> Date: 14 May 86 16:35:05 GMT To: info-c@BRL-SMOKE.ARPA In article <1469@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >In article <989@dataioDataio.UUCP>, bjorn@dataio.UUCP writes: >>... I notice this (odd) fact: the compiler on the PC is better than >>the one on the VAX! It's faster, it produces better code, and it >>catches errors that the UNIX C does not. So I'm curious: >1. Your company gets paid for improving your compiler. Is not > that so? No, it isn't so. Datalight, Data I/O, Data Exchange, Data Translation Inc., Data Zone Inc., Datacom Northwest Inc., Datatech Enterprises Co. and Data General are all independent companies. The similarity in the names is coincidence. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6477 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:11 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024369; 20 May 86 19:48 EDT Received: from USENET by SMOKE.BRL.ARPA id a014523; 20 May 86 19:01 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#18 Message-ID: <1056@hou2d.UUCP> Date: 15 May 86 17:32:52 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 18 Today's Topics: MORE C standard differences Apr85-Feb86, part 8 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 8 of 9 To: utzoo!ihnp4!hou2d!osd # D.12.2.1 The clock function * The clock function returns ... the processor time used {--> by the program} since the beginning of an implementation-defined era * {--> related only to the program invocation}. # D.12.2.2 The time function N--> The encoding of the value is unspecified. # D.12.2.2 The time function * The time function returns ... the current calendar time {since the beginning of an implementation-defined era -->}. # D.12.3.1 The asctime function The asctime function converts the broken-down time in the struc- * ture pointed to by timeptr into a {26-character -->} string in * the {following -->} form {. All the fields have constant width. -->} Sun Sep 16 01:03:52 1973\n\0 N--> using the equivalent of the following algorithm: N--> char *asctime(const struct tm *timeptr) N--> { N--> static const char wday_name[7][3] = { N--> "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" N--> }; N--> static const char mon_name[12][3] = { N--> "Jan", "Feb", "Mar", "Apr", "May", "Jun", N--> "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" N--> }; N--> static char result[26]; N--> (void) sprintf(result, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n", N--> wday_name[timeptr->tm_wday], N--> mon_name[timeptr->tm_mon], N--> timeptr->tm_mday, timeptr->tm_hour, N--> timeptr->tm_min, timeptr->tm_sec, N--> 1900 + timeptr->tm_year); N--> return result; N--> } # C.12.3.2 The ctime function N--> It is equivalent to N--> asctime(localtime(timer)) N--> ... Forward references: the localtime function (#D.12.3.5). # {--> D.13 FUTURE DIRECTIONS} # {--> D.13.1 Character handling } N--> Function names that begin with "is" and "to" and a lower-case N--> letter may be added to the declarations in the header. # {--> D.13.2 Mathematics } N--> The names of all existing functions declared in the N--> header, suffixed with f or l, are reserved for corresponding N--> functions with float and long double arguments and return values, N--> respectively. # {--> D.13.3 Signal handling } N--> Macros that begin with SIG and an upper-case letter may be added N--> to the definitions in the header. # {--> D.13.4 Input/output } N--> The use of leading 0 in fprintf format to request padding with N--> leading zeros is deprecated. Use the "precision" specifier in- N--> stead. N--> Lower-case letters may be added to the conversion specifiers in N--> fprintf and fscanf. Other characters may be used in extensions. # {--> D.13.5 String handling N--> Function names that begin with "str" and "mem" and a lower-case N--> letter may be added to the declarations in the header. # E. APPENDICES Remark: Since the appendices are not part of the Standard, I have included only certain ones here. The ones I included were the new section #E.2 Sequence Points, section #{E.3 --> E.5} Common Warnings, and section #{E.5 --> E.6} Portability Issues. # {--> E.2 SEQUENCE POINTS} N--> The following are the sequence points described in #B.1.2.3. N--> * The call to a function, after the arguments have been evaluated N--> (#C.3.2.2). N--> * The logical AND operator && (#C.3.2.13). N--> * The logical OR operator || (#C.3.2.14). N--> * The conditional operator ? (#C.3.2.15). N--> * The comma operator , (#C.3.2.17). N--> * Completion of the evaluation of a full expression: an initial- N--> izer of an object that has automatic storage duration (#C.5.6); N--> the expression in an expression statement (#C.6.3); the con- N--> trolling expression of a selection statement (if or switch) N--> (#C.6.4); the controlling expression of an iteration statement N--> (while, do, or for) (#C.6.5). # {E.3 --> E.5} COMMON WARNINGS * An implicit narrowing conversion is encountered, such as the * assignment of a long int or a double to an int {-->, or a pointer to void to a pointer to any type of object other than char (#C.2)}. ... <--O * A declaration with no effect is encountered (#C.5). N--> * An object is defined but not used (#C.5). # {E.5.1 --> E.6.1} Unspecified behavior N--> * The behavior if a printable character is written when the ac- N--> tive position is at the final position of a line (#B.2.2). N--> * The behavior if a backspace character is written when the ac- N--> tive position is at the initial position of a line (#B.2.2). N--> * The behavior if a horizontal tab character is written when the N--> active position is at or past the last defined horizontal tabu- N--> lation position (#B.2.2). N--> * The behavior if a vertical tab character is written when the N--> active position is at or past the last defined vectical tabula- N--> tion position (#B.2.2). # {E.5.1 --> E.6.1} Unspecified behavior N--> * The order in an array sorted by the qsort function of two N--> members that compare as equal (#D.10.5.2). # {E.5.1 --> E.6.1} Unspecified behavior N--> * The encoding of the calendar time returned by the time function N--> (#D.12.2.2). ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:32:29 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6203 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:14 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 10:39:49 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024327; 20 May 86 19:43 EDT Received: from USENET by SMOKE.BRL.ARPA id a014511; 20 May 86 19:00 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#15 Message-ID: <1053@hou2d.UUCP> Date: 15 May 86 17:31:28 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 15 Today's Topics: MORE C standard differences Apr85-Feb86, part 5 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 5 of 9 To: utzoo!ihnp4!hou2d!osd # D.10.1.1 The atof function <--O If the value cannot be represented, the behavior is undefined. <--O It the string starts with an unrecognized character, zero is re- <--O turned. Remark: And likewise for atoi (#D.10.1.2) and atol (#D.10.1.3). # D.10.1.2 The atoi function <--O The function recognizes an optional sequence of white-space char- <--O acters, then an optional plus or minus sign, then a sequence of <--O digits. The first unrecognized character ends the conversion. <--O The sequence of digits is interpreted by the same rules as for a <--O decimal integer constant. N--> Except for the behavior on error, it is equivalent to N--> (int)strtol(nptr, (char **)NULL, 10) N--> ... Forward references: the strtol function (#D.10.1.5). Remark: Likewise for atol (#D.10.1.3), except with no (int) cast. # D.10.1.4 The strtod function The function recognizes an optional leading sequence of white- * space characters {--> (as specified by the isspace function)}, ... N--> If an unrecognized character occurs before the first digit fol- N--> lowing the e or E, the exponent is taken to be zero. ... * If {the string starts with -->} an unrecognized character {--> * occurs before any digit}, zero is returned {-->, and errno is set to EDOM}. # D.10.1.4 The strtod function <--O The string is interpreted by the same rules as a floating con- <--O stant. N--> The sequence of characters from the first digit or the decimal N--> point (whichever occurs first) to the character before the first N--> unrecognized character is interpreted as a floating constant ac- N--> cording to the rules of #C.1.3.1, except that if neither an ex- N--> ponent part nor a decimal point appears, a decimal point is as- N--> sumed to follow the last digit in the string. If a minus sign N--> appears immediately before the first digit, the value resulting N--> from the conversion is negated. # D.10.1.5 The strtol function The function recognizes an optional leading sequence of white- * space characters {--> (as specified by the isspace function)}, ... * If {the string starts with -->} an unrecognized character {--> occurs before the first recognized digit or letter}, zero is re- * turned {-->, and errno is set to EDOM}. # D.10.1.5 The strtol function * If the value of base is 0, the sequence of {digits --> characters from the first digit to the character before the first unrecog- * nized character} is interpreted {by the same rules -->} as {for * -->} an integer constant {--> according to the rules of * #C.1.3.2}. {After the optional sign, a leading zero indicates octal conversion, and a leading 0x or 0X hexadecimal conversion. Otherwise, decimal conversion is used. --> If a minus sign ap- pears immediately before the first digit, the value resulting from the conversion is negated.} If the value of base is between 2 and 36, it is used as the base * for conversion. {--> Letters from a (or A) through z (or Z) are ascribed the values 10 to 35; a letter whose value is greater than or equal to the value of base ends the conversion.} Leading * zeros after the optional sign are ignored, and {--> leading} 0x * or 0X is ignored if the value of base is 16. {--> If a minus sign appears immediately before the first digit or letter, the value resulting from the conversion is negated.} # D.10.2.1 The rand function The rand function computes a sequence of pseudo-random integers * in the range 0 to {32767 --> RAND_MAX} {using the specified linear multiplicative algorithm, which has a period of 2 raised to the power 32 -->}. # D.10.2.1 The rand function * The following functions define {the required semantics --> a portable implementation} of rand and srand. ... * int rand({--> void}) ... <--O void srand(seed) <--O unsigned int seed; N--> void srand(unsigned int seed) # D.10.3 Memory management functions N--> The pointer returned if the allocation succeeds is suitably N--> aligned so that it may be assigned to a pointer to any type of N--> object and then used to access such an object in the space allo- N--> cated (until the space is explicitly freed or reallocated). # D.10.3.1 The calloc function * void *calloc({unsigned int --> size_t} nelem, size_t size); # D.10.3.1 The calloc function <--O The pointer returned may safely be case to point to an object of <--O any type. Remark: Likewise for malloc (#D.10.3.3) and realloc (#D.10.3.4). # D.10.3.1 The calloc function * If the space cannot be allocated, {--> or if nelem or size is zero,} the calloc function returns a null pointer. # D.10.3.2 The free function N--> If ptr is a null pointer, no action occurs. # D.10.3.4 The realloc function N--> If ptr is a null pointer, the realloc function behaves like the N--> malloc function for the specified size. ... If size is zero, the realloc function returns a null pointer and the object pointed to by ptr is freed. # D.10.4.1 The abort function * Unless the signal SIGABRT is being {--> cuaght or} ignored, the abort function causes abnormal program termination to occur. # D.10.4.1 The abort function If the signal SIGABRT is being ignored, the abort function re- * turns no value. {--> Otherwise, the abort function cannot return to its caller.} Remark: I assume "caught or ignored" is meant. # D.10.4.2 The exit function <--O If a registered function fails to return as its value the value <--O returned by the call to the onexit function by means of which it <--O was registered, the behavior is undefined. ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:31:09 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. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5459 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:17 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024263; 20 May 86 19:37 EDT Received: from USENET by SMOKE.BRL.ARPA id a014473; 20 May 86 18:59 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#11 Message-ID: <1049@hou2d.UUCP> Date: 15 May 86 17:28:40 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 11 Today's Topics: Cover Letter for MORE C standard differences MORE C standard differences Apr85-Feb86, part 1 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: Cover Letter for MORE C standard differences To: utzoo!ihnp4!hou2d!osd This is the continuation of my earlier posting enumerating signi- ficant differences between the April 30, 1985, and February 14, 1986, drafts of the proposed ANSI C Standard. This posting cov- ers Part D and part of Part E. It did not seem worthwhile doing the rest of Part E. As before, what you see here does not include ALL of the differ- ences between the versions. I have generally suppressed changes that appeared to provide only a clearer wording, or to move some text to a more appropriate heading. Some of these changes are actually fairly substantial in extent. On the other hand, I have included all changes that affect either C itself or the terminol- ogy for talking about it ... except, of course, any that I missed. The changes are cited in the order of their appearance in the new version, with a few slight exceptions to group related text. I don't give a lot of context for each one, to keep the length of this document manageable. Never assume that you are seeing a complete paragraph. However, where I have elided important text I have placed an ellipsis (...). For changes that affect a small part of a paragraph, I have adopted the notation {old text --> new text}, which is simply run in line. Each line containing the start of at least one such change is starred in the left margin. The old or new text may be null: thus, the change to the description of ptrdiff_t in section D.1.1 consists of the insertion of the word "signed". In such a paragraph, the words not enclosed in braces may be unchanged from April 1985 to February 1986, or they may have changed in a minor way, as described above, in which case I am showing the new ver- sion. For larger changes, I give what are generally complete paragraphs or blocks of paragraphs, showing old and new forms separately. The notation "<--O" in the left margin means that this paragraph has been deleted or replaced; "N-->" refers to its replacement or an added paragraph. Since the typographical changes of the actual document are not available here, I have rendered some of them in punctuation and omitted others. (In particular, "quotation marks" in this arti- cle more often than not represent italics in the original and thus a definition of a term.) Paragraphs marked Remark are mine. Mark Brader - ihnp4!utzoo!lsuc!msb ------------------------------ Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 1 of 9 To: utzoo!ihnp4!hou2d!osd # D.1 INTRODUCTION { --> } # D.1.1 Terms and common definitions N--> A "letter" is a character in the execution character set N--> corresponding to any of the 52 required lower-case and upper-case N--> letters in the source character set, listed in #B.2.1. # D.1.1 Terms and common definitions <--O A "null pointer" is a pointer of appropriate type whose value <--O compares equal to that of an integral constant expression with <--O the value 0. # D.1.1 Terms and common definitions The following types and macros ... are also defined in a common * standard header, { --> }. The types are ptrdiff_t * which is the {--> signed} integral type of the result of sub- tracting two pointers; and size_t * which is the {--> unsigned} integral type of the result of the sizeof operator. The macros are NULL * which expands to {a constant expression whose value compares equal to that of an integral constant expression with the value 0, which can be assigned to a pointer or used as an argument to represent the null pointer --> an implementation-defined null pointer constant}; and errno * which expands to {an lvalue expression --> a modifiable lvalue} * that designates {an int --> a volatile integer} which is set to a positive error code by several library functions. ... N--> The macro errno need not be the identifier of an object. It N--> might be a modifiable lvalue resulting from a function call (for N--> example, *_errno()). # D.1.2 Headers * Each library function {or object -->} is {associated with --> de- clared in} a "header" ... made available via ... #include ... * The header declares a set of related functions {and objects -->}, * plus any necessary types and additional {#define -->} macros needed to facilitate their use. Remark: The draft no longer refers to headers declaring any ob- jects; this is a general change and will not be mentioned again. # D.1.2 Headers <--O An implementation may define macros whose names begin with two or <--O more underscores, even if no headers are explicitly included. # D.1.2 Headers The standard headers are ... N--> ... * { --> } # D.1.2 Headers * Headers ... may be included more than once {--> in a given scope}, with no effect different from being included only once. # D.1.3 Use of library functions Any function declared in a header may be implemented as a macro defined in the header, <--O so it is generally not safe to declare or take the address of a <--O library function or object. N--> so a library function should not be declared explicitly if its N--> header is included. Any macro definition of a function can be N--> suppressed locally by enclosing the name of the function in N--> parentheses, because the name is then not followed by the left N--> parenthesis that indicates expansion of a macro function name. N--> For the same syntactic reason, it is permitted to take the ad- N--> dress of a library function even if it is also defined as a mac- N--> ro. * The use of #undef to remove any macro definition will {--> also} ensure that an actual function is referenced. # D.1.3 Use of library functions N--> If a function that accepts a variable number of arguments is not N--> declared (explicitly or by including its associated header), the N--> behavior is undefined. # D.1.3 Use of library functions ... assuredly generating a true function reference ... #include #undef atoi /*...*/ i = atoi(str); N--> or N--> #include N--> /*...*/ N--> i = (atoi)(str); # D.1.3 Use of library functions ... the appropriate header could specify #define abs(x) _builtin_abs(x) for a compiler whose code generator will accept it. In this manner, a user desiring to guarantee that a given library function such as abs will be a genuine function may write #undef abs whether the implementation's header provides a macro implementa- * tion of abs or a builtin implementation. {--> The prototype for the function, which precedes and is hidden by any macro defini- tion, is thereby revealed also.} ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:28:03 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6335 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024340; 20 May 86 19:45 EDT Received: from USENET by SMOKE.BRL.ARPA id a014515; 20 May 86 19:00 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#16 Message-ID: <1054@hou2d.UUCP> Date: 15 May 86 17:31:54 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 16 Today's Topics: MORE C standard differences Apr85-Feb86, part 6 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 6 of 9 To: utzoo!ihnp4!hou2d!osd # D.10.4.3 The getenv function N--> The array pointed to is not modifiable by the program, but may be N--> overwritten by a subsequent call to the getenv function. # D.10.4.4 The onexit function If the registration succeeds, the onexit function returns a value * that compares unequal to {--> the integer constant} 0. # {--> D.10.5 Searching and sorting utilities} # {--> D.10.5.1 The bsearch function} N--> Synopsis N--> #include N--> void *bsearch(const void *key, const void *base, N--> size_t nel, size_t keysize, N--> int (*compar)(const void *, const void *)); N--> Description N--> The bsearch function searches an array of nel objects, the ini- N--> tial member of which is pointed to by base, for a member that N--> matches the object pointed to by key. The size of each object is N--> specified by keysize. N--> The array shall be previously sorted in ascending order according N--> to a comparison function pointed to by compar, which is called N--> with two arguments that point to the objects being compared. The N--> function shall return an integer less than, equal to, or greater N--> than zero if the first argument is considered to be respectively N--> less than, equal to, or greater than the second. N--> Returns N--> The bsearch function returns a pointer to the matching member of N--> the array, or a null pointer if no match is found. # {--> D.10.5.2 The qsort function} N--> Synopsis N--> #include N--> void qsort(void *base, size_t nel, size_t keysize, N--> int (*compar)(const void *, const void *)); N--> Description N--> The qsort function sorts an array of nel objects, the initial N--> member of which is pointed to by base. The size of each object N--> is specified by keysize. N--> The array is sorted in ascending order according to a comparison N--> function pointed to by compar, which is called with two arguments N--> that point to the objects being compared. The function shall re- N--> turn an integer less than, equal to, or greater than zero if the N--> first argument is considered to be respectively less than, equal N--> to, or greater than the second. N--> If two members compare as equal, their order in the sorted array N--> is unspecified. N--> Returns N--> The qsort function returns no value. # {--> D.10.6 Integer arithmetic functions} # {D.5.6.1 --> D.10.6.1} The abs function ... * #include { --> } ... # {--> D.10.6.2 The idiv function} N--> Synopsis N--> #include N--> idiv_t idiv(int numer, int denom); N--> Description N--> The idiv function computes the quotient and remainder of the N--> division of the numerator numer by the denominator denom. If the N--> division is inexact, the sign of the quotient is that of the N--> mathematical quotient, and the magnitude of the quotient is the N--> largest integer less than the magnitude of the mathematical quo- N--> tient. If the result cannot be represented, the behavior is un- N--> defined. N--> Returns N--> The idiv function returns a structure with two elements: the quo- N--> tient and the remainder. The type returned is defined by N--> typedef struct { int quot, rem; } idiv_t; # {--> D.10.6.3 The ldiv function} N--> Synopsis N--> #include N--> ldiv_t ldiv(long numer, long denom); N--> Description N--> The ldiv function is similar to the idiv function, except that N--> the arguments and the members of the returned structure (which N--> has type ldiv_t) all have type long int. # D.11 STRING HANDLING Remark: The memset and strlen functions are moved from #D.11.2.2 and #D.11.4.3, respectively, into #D.11.6, and the other func- tions' sections in #D.11.2 and #D.11.4 are renumbered according- ly. # D.11.1 String function conventions The header declares several functions useful for mani- * pulating character arrays {--> and other objects treated as char- acter arrays}. # D.11.1 String function conventions <--O If copying takes place between objects that overlap, the behavior <--O is undefined. # D.11.2.1 The memcpy function * The memcpy function copies n characters from the {array --> ob- * ject} pointed to by s2 into the {array --> object} pointed to by s1. Remark: This change is general through this section. # D.11.2.1 The memcpy function N--> Copying between objects that overlap shall take place correctly. # {D.11.2.3 --> D.11.2.2} The strcpy function N--> If copying takes place between objects that overlap, the behavior N--> is undefined. # {D.11.2.4 --> D.11.2.3} The strncpy function N--> If copying takes place between objects that overlap, the behavior N--> is undefined. # {D.11.2.4 --> D.11.2.3} The strncpy function If the string pointed to by s2 is longer than n characters, the * result {may --> will} not be null-terminated. ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:31:29 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. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 6032 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024310; 20 May 86 19:42 EDT Received: from USENET by SMOKE.BRL.ARPA id a014507; 20 May 86 19:00 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#14 Message-ID: <1052@hou2d.UUCP> Date: 15 May 86 17:31:01 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 14 Today's Topics: MORE C standard differences Apr85-Feb86, part 4 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 4 of 9 To: utzoo!ihnp4!hou2d!osd # D.9.6.2 The fscanf function <--O e,f,g A floating point number is expected; the subsequent argu- <--O ment must be a pointer to floating. The input format for <--O floating point numbers is an optionally signed sequence <--O of digits, possibly containing a decimal point, followed <--O by an optional exponent field consisting of an E or an e, <--O followed by an optionally signed integer. N--> e,f,g A floating point number is expected; the corresponding N--> argument shall be a pointer to floating. The input for- N--> mat is as described for the strtod function. # D.9.6.2 The fscanf function n No input is consumed; the corresponding argument shall be a pointer to integer into which is written the number of characters read from the input stream so far by this call * to fscanf. {--> This is not counted as a match input item.} # D.9.6.2 The fscanf function <--O If an invalid conversion specifier follows the %, the result is <--O undefined. N--> If the conversion specifier is a lower-case letter that is not N--> described above, the behavior is undefined. If the conversion N--> specifier is any other character that is not described above, the N--> behavior is implementation-defined. # D.9.6.2 The fscanf function N--> If end-of-file is encountered during a conversion, the conversion N--> terminates. # D.9.6.2 The fscanf function * The fscanf function returns the number of input items {--> matched and} assigned ... # D.9.6.6 The sscanf function * int sscanf ({--> const} char *s, const char *format, ...); # D.9.6.7 The vfprintf function N--> The vfprintf function does not invoke the va_end function. Remark: And likewise for vprintf (#D.9.6.8) and vsprintf (#D.9.6.9). # D.9.7.1 The fgetc function * If the stream is at end-of-file, {or --> the end-of-file indica- * tor is set and fgetc returns EOF.} If a read error occurs, {--> the error indicator is set and} fgetc returns EOF. Remark: And likewise for getc (#D.9.7.5) and getchar (#D.9.7.6). # D.9.7.3 The fputc function * The fputc function returns the character written. If a {--> * write} error occurs, {--> the error indicator is set and} fputc returns EOF. Remark: And likewise for putc (#D.9.7.8) and putchar (#D.9.7.9). # D.9.7.11 The ungetc function * The ungetc function pushes the character specified by c {--> (converted to an unsigned char)} back onto the input stream * pointed to by stream. ... An intervening {--> fflush,} fseek, * {--> or rewind} erases any memory of a pushed-back character. ... N--> If the ungetc function is called twice on the same stream without N--> an intervening read, fflush, fseek, or rewind operation on that N--> stream, the behavior is undefined. * ... The ungetc function returns {c --> the character pushed * back}, or EOF {--> if the value of c equals that of the macro EOF or} if it cannot push the character back. # D.9.8.1 The fread function The file position indicator (if defined) is advanced by the * number of {bytes --> characters} successfully read. Remark: A similar change occurs for fwrite (#D.9.8.3), fseek (#D.9.9.1), and ftell (#D.9.9.2). # D.9.9.1 The fseek function * The fseek function {--> clears the end-of-file indicator and} un- does any effects of ungetc. # D.9.9.3 The rewind function * ... the {end-of-file and -->} error indicator is cleared ... # D.9.10.4 The perror function * {const char * --> void} perror (const char *s); # D.9.10.4 The perror function * {If s is not null, perror --> It} writes a line to the standard * error {file --> stream} thus: first {--> (if s is not a null pointer and the character pointed to by s is not the null charac- ter)}, the string pointed to by s followed by a colon and a * space; then an {--> appropriate} error message string followed by a new-line character. # D.9.10.4 The perror function * The contents of the error message strings are {--> the same as those returned by the strerror function with argument errno, which are} implementation-defined. # D.9.10.4 The perror function <--O If the argument is a null pointer, the perror function returns a <--O pointer to the message string and performs no output. N--> The perror function returns no value. N--> Forward references: the strerror function (#D.11.6.2). # D.10 GENERAL UTILITIES * The header declares {a --> three} types and several * functions of general utility {-->, and defines four macros}. The types declared are ... N--> idiv_t N--> which is a structure type that is the type of the value returned N--> by the idiv function, and N--> ldiv_t N--> which is a structure type that is the type of the value returned N--> by the ldiv function. N--> The macros defined are N--> EDOM , N--> ERANGE , N--> and N--> HUGE_VAL N--> which are described in #D.5.1; and N--> RAND_MAX N--> which expands to an integral constant expression, the value of N--> which is the maximum value returned by the rand function. # D.10.1 String conversion functions <--O Each of the functions described in this section accepts an op- <--O tional leading sequence of white-space characters (as specified <--O by the isspace function) in the input string. # D.10.1 String conversion functions N--> The function ans atof, atoi, and atol do not set errno on error. N--> If the value of the result cannot be represented, the behavior is N--> undefined. # D.10.1.1 The atof function <--O The function recognizes an optional sequence of white-space char- <--O acters, then an optional plus or minus sign, then a sequence of <--O digits optionally containing a decimal point, then an optional <--O letter e or E followed by an optionally signed integer. The <--O first unrecognized character ends the conversion. The string is <--O interpreted by the same rules as for a floating constant. N--> Except for the behavior on error, it is equivalent to N--> strtod(nptr, (char **)NULL) N--> ... Forward references: the strtod function (#D.10.1.4). ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:30:27 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6423 for JMS@ARIZMIS; Wed, 21-MAY-1986 10:41 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024357; 20 May 86 19:47 EDT Received: from USENET by SMOKE.BRL.ARPA id a014519; 20 May 86 19:00 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#17 Message-ID: <1055@hou2d.UUCP> Date: 15 May 86 17:32:24 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 17 Today's Topics: MORE C standard differences Apr85-Feb86, part 7 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 7 of 9 To: utzoo!ihnp4!hou2d!osd # D.11.3.1 The strcat function The strcat function appends a copy of the string pointed to by s2 * {--> (including the terminating null character)} to the end of the string pointed to by s1. # D.11.3.2 The strncat function The strncat function appends not more than n characters of the * string pointed to by s2 {--> (not including the terminating null character)} to the end of the string pointed to by s1. # D.11.3.2 The strncat function N--> The number of characters that may end up in the array pointed to N--> by s1 is strlen(s1)+n+1. N--> Forward references: the strlen function (#D.11.6.3). # D.11.4 {Length and -->} Comparison functions # D.11.4.1 The memcmp function N--> The contents of "holes" used as padding for purposes of alignment N--> within structure objects are indeterminate, unless the contents N--> of the entire object have been set explicitly by the calloc or N--> memset function. Unions and strings shorter than their allocated N--> space may also cause problems in comparison. # D.11.5.1 The memchr function * The memchr function locates the first occurrence of c {--> (con- verted to an unsigned char)} in the initial n characters of the object pointed to by s. # D.11.5.2 The strchr function * The strchr function locates the first occurrence of c {--> (con- verted to a char)} in the string pointed to by s. Remark: And the same change for strrchr (#D.11.5.5). # {--> D.11.5.7 The strstr function} N--> Synopsis N--> #include N--> char *strstr(const char *s1, const char *s2); N--> Description N--> The strstr function locates the first occurrence of the string N--> pointed to by s2 in the string pointed to by s1. N--> Returns N--> The strstr function returns a pointer to the located string, or a N--> null pointer if the string is not found. # {D.11.5.7 --> D.11.5.8} The strtok function <--O The strtok function considers the string pointed to by s1 to con- <--O sist of a sequence of zero or more text tokens separated by spans <--O of one or more characters from the string pointed to by s2. N--> A sequence of calls to the strtok function breaks the string N--> pointed to by s1 into a sequence of tokens, each of which is del- N--> imited by a character from the string pointed to by s2. The N--> first call in the sequence has s1 as its first argument, and is N--> followed by calls with a null pointer as their first argument. The separator string pointed to by s2 may be different from call to call. N--> The first call in the sequence searches s1 for the first charac- N--> ter that is NOT contained in the current separator string s2. If N--> no such character is found, there are no tokens in s1, and the N--> strtok function returns a null pointer. If such a character is N--> found, it is the start of the first token. N--> The strtok function then searches from there for a character that N--> IS contained in the current separator string. If no such charac- N--> ter is found, the current token extends to the end of the string N--> pointed to by s1, and subsequent searches for a token will fail. N--> If such a character is found, it is overwritten by a null charac- N--> ter, which terminates the current token. The strtok function N--> saves a pointer to the following character, from which the next N--> search for a token will start. N--> Each subsequent call, with a null pointer as the value of the N--> first argument, starts searching from the saved pointer and N--> behaves as described above. <--O The first call to the strtok function returns a pointer to the <--O initial character of the first token, and will have written a NUL <--O character into s1 immediately following the returned token. Each <--O subsequent call (with the value of the first argument null) re- <--O turns a pointer to a subsequent token. When no token remains in <--O s1, the strtok function returns a null pointer. N--> The strtok function returns a pointer to the first character of a N--> token, or a null pointer if there is no token. # {D.11.5.7 --> D.11.5.8} The strtok function N--> Example N--> #include N--> static char str[] = "?a???b,,,#c"; N--> char *t; N--> t = strtok(str, "?"); /* t points to the token "a" */ N--> t = strtok(NULL, ","); /* t points to the token "??b" */ N--> t = strtok(NULL, "#,"); /* t points to the token "c" */ N--> t = strtok(NULL, "?"); /* t is a null pointer */ # {--> D.11.6 Miscellaneous functions} # {D.11.2.2 --> D.11.6.1} The memset function * The memset function copies the value of c ({cast --> converted} * to an unsigned char) into each of the first n {bytes --> charac- ters} of the object pointed to by s. # {--> D.11.6.2 The strerror function} N--> Synopsis N--> #include N--> char *strerror(int errnum); N--> Description N--> The strerror function maps the error number in errnum to an error N--> message string. N--> Returns N--> The strerror function returns a pointer to the string, the con- N--> tents of which are implementation-defined. The array pointed to N--> is not modifiable by the program, but may be overwritten by a N--> subsequent call to the strerror function. # {D.11.4.3 --> D.11.6.3} the strlen function The strlen function computes the length of the string pointed to * by s {, not counting the terminating NUL character -->}. ... * The strlen function returns the number of {initial -->} charac- * ters {--> that precede the terminating null character}. # D.12.1 Components of time Many functions deal with a "calendar time" that represents the * current date {--> (according to the Gregorian calendar)} and time. # D.12.1 Components of time * int tm_mon; /* {month of the year --> months since January} - [0, 11] */ ... * int tm_yday; /* {day of the year --> days since January 1} - [0, 365] */ ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:32:04 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6575 for JMS@ARIZMIS; Wed, 21-MAY-1986 11:05 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024378; 20 May 86 19:49 EDT Received: from USENET by SMOKE.BRL.ARPA id a014528; 20 May 86 19:01 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#19 Message-ID: <1057@hou2d.UUCP> Date: 15 May 86 17:33:20 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 19 Today's Topics: MORE C standard differences Apr85-Feb86, part 9 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 9 of 9 To: utzoo!ihnp4!hou2d!osd # {E.5.2 --> E.6.2} Undefined behavior N--> * An attempt is made to modify a string literal (#C.1.1.4). # {E.5.2 --> E.6.2} Undefined behavior <--O * The value of a constant is not representable (#C.1.3). # {E.5.2 --> E.6.2} Undefined behavior N--> * For a function call with no function prototype declarator in N--> scope, the number of arguments or their types after the default N--> argument conversions do not match those of the formal parame- N--> ters (#C.3.2.2). N--> * A function that accepts a variable number of arguments is N--> called, but no prototype declarator wth the ellipsis notation N--> is in scope (#C.3.2.2). ... N--> * A function that accepts a variable number of arguments is de- N--> fined without the ellipsis notation (#C.7.1). N--> * A function prototype is in scope when a function is defined, N--> but a semantically equivalent prototype is not in scope every- N--> where the function is called (#C.7.1). # {E.5.2 --> E.6.2} Undefined behavior N--> * The result of the preprocessing concatenation operator ## is N--> not a valid token (#C.8.3). # {E.5.2 --> E.6.2} Undefined behavior * * A {--> library} function argument has an invalid value, unless * the behavior is specified explicitly (#{D.1.1 --> D.1.3}). # {E.5.2 --> E.6.2} Undefined behavior * * The value of {a register variable --> an object of automatic storage class that does not have volatile type} has been changed bwteen a setjmp and longjmp call (#D.6.2.1). # {E.5.2 --> E.6.2} Undefined behavior N--> * The type of the actual next argument in a variable argument N--> list disagrees with the type specified by the va_arg macro N--> (#D.8.1.2). N--> * A return occurs from a function with a variable argument list N--> initialized by the va_start macro before the va_end function is N--> invoked (#D.8.1.3). # {E.5.2 --> E.6.2} Undefined behavior N--> * A single conversion by the fprintf function produces more than N--> 509 characters of output (#D.9.6.1). ... N--> * A single conversion by the fscanf function consumes more than N--> 509 characters of input (#D.9.6.2). # {E.5.2 --> E.6.2} Undefined behavior N--> * The ungetc function is called twice on the same stream without N--> an intervening read, fflush, fseek, or rewind operation on that N--> stream (#D.9.7.11). # {E.5.2 --> E.6.2} Undefined behavior <--O * When called by the exit function, a function registered by the <--O onexit function fails to return the value returned by the onex- <--O it function at the time of registration (#D.10.4.2). # {E.5.2 --> E.6.2} Undefined behavior * * The result of {the abs --> an integer arithmetic} function {--> * (abs, idiv, or ldiv)} cannot be represented (#{D.5.6.1 --> D.10.6}). # {E.5.3.3 --> E.6.3.3} Characters N--> * The {correspondence --> mapping} of characters in the source N--> character set {--> in character constants} to characters in the N--> execution character set {--> (#C.1.3.4)}. # {E.5.3.5 --> E.6.3.5} Floating point. <--O * The direction of truncation when a negative floating-point <--O number is converted to an integer (#C.2.1.3). # {E.5.3.5 --> E.6.3.5} Floating point. <--O * Whether the presence in an expression of a float operand but no <--O double operand requires the operands to be converted to double. # {E.5.3.11 --> E.6.3.11} Preprocessing {control lines --> direc- tives} N--> * Whether white space between tokens in a macro argument used to N--> create a string literal is retained in the string or replaced N--> by a single space character (#C.8.3). # {E.5.3.12 --> E.6.3.12} Library functions N--> * The null pointer constant to which the macro NULL expands N--> (#D.1.1). # {E.5.3.12 --> E.6.3.12} Library functions N--> * The effect if the program redefines a reserved external iden- N--> tifier (#D.1.2). # {E.5.3.12 --> E.6.3.12} Library functions * * The sets of characters tested for by the {--> isalnum, isal- * pha,} iscntrl, {--> islower}, isprint, {--> and isupper} func- tion (#D.3.1). # {E.5.3.12 --> E.6.3.12} Library functions N--> * The values returned by the mathematics functions on domain er- N--> rors (#D.5). # {E.5.3.12 --> E.6.3.12} Library functions N--> * Whether a text line containing only a single space character N--> plus a terminating new-line character is converted on input to N--> a line consisting only of the terminating new-line character N--> (#D.9.2). N--> * The characteristics of file buffering (#D.9.3). N--> * Whether a zero-length file actually exists (#D.9.3). # {E.5.3.12 --> E.6.3.12} Library functions N--> * The contents of the error message strings returned by the N--> strerror function (#D.11.6.2). # {E.5.3.12 --> E.6.3.12} Library functions <--O * The era for the time function (#D.12.3). # {E.5.4 --> E.6.4} Common extensions N--> The inclusion of any extension that may cause a strictly conform- N--> ing program to become invalid renders an implementation noncon- N--> forming. Examples of such extensions are new keywords, prede- N--> fined macro names, or library functions with names that do not N--> begin with an underscore. # {--> E.6.4.1 Environment arguments} N--> In a hosted environment, the main function receives a third argu- N--> ment, char *envp[], that points to a null-terminated array of N--> pointers to char, each of which points to a string that provides N--> information about the environment for this execution of the pro- N--> cess (#B.1.2.2). Remark: With this inserted subsection, the other subsections of this section are renumbered. # {E.5.4.4 --> E.6.4.5} Writable string literals <--O String literals are arrays of char, not arrays of const char <--O (#C.1.4). N--> String literals are modifiable. Identical string literals shall N--> be distinct (#C.1.4). ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:32:54 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. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5907 for JMS@ARIZMIS; Wed, 21-MAY-1986 11:29 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024298; 20 May 86 19:40 EDT Received: from USENET by SMOKE.BRL.ARPA id a014489; 20 May 86 19:00 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#13 Message-ID: <1051@hou2d.UUCP> Date: 15 May 86 17:29:50 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 13 Today's Topics: MORE C standard differences Apr85-Feb86, part 3 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 3 of 9 To: utzoo!ihnp4!hou2d!osd # D.9.4.4 The tmpnam function * If the argument is not {null --> a null pointer}, it is assumed * to point to an array of at least L_tmpnam {bytes --> characters} ... # D.9.5.2 The fflush function The fflush function causes any unwritten data for the output * stream pointed to by stream to be {--> delivered to the host en- vironment to be} written to the file. # D.9.5.3 The fopen function * "w": create text file for writing, or truncate {--> to zero length}. Remark: The same change for "wb", "w+", and "w+b". # D.9.5.3 The fopen function However, output may not be directly followed by input without an * intervening {--> fflush,} fseek, or rewind, and input may not be * directly followed by output without an intervening {--> fflush,} fseek, or rewind, unless the input operation encounters end-of- file. # D.9.5.3 The fopen function <--O After the write operation, the file pointer is repositioned at <--O the end of the output file and the buffer is flushed. # D.9.5.3 The fopen function N--> When opened, a stream is fully buffered if and only if it does N--> not refer to an interactive device. # D.9.5.4 The freopen function The primary use of freopen is ... with ... stderr, stdin, or * stdout ..., as those identifiers need not be {lvalue expressions --> modifiable lvalues} (that may be assigned to by the fopen function). # D.9.5.5 The setbuf function <--O The setbuf function is used after the stream pointed to be stream <--O has been associated with an open file but before it is read or <--O written. It causes the array pointed to by buf to be used in- <--O stead of an automatically allocated buffer. If buf is a null <--O pointer, input/output on that stream will be completely unbuf- <--O fered. The macro BUFSIZ specifies the size in bytes of the array <--O that is needed. <--O The standard stream stdout is normally buffered if and only if <--O the output does not refer to a terminal; this default may be <--O changed by setbuf. The standard stream stderr is by default un- <--O buffered unconditionally; setbuf will set the state to whatever <--O is desired. When an output stream is unbuffered, information ap- <--O pears on the destination file or terminal as soon as written; <--O when it is buffered, characters are saved up and written as a <--O block. <--O ... The buffer must have a lifetime at least as great as the <--O open stream, so a stream must be closed before a buffer that has <--O automatic storage duration is deallocated upon block exit. N--> Except that it returns no value, the setbuf function is N--> equivalent to the setvbuf function invoked with the values _IOFBF N--> for type and BUFSIZ for size, or (if buf is a null pointer), with N--> the value _IONBF for type. # D.9.5.6 The setvbuf function int setvbuf(FILE *stream, char *buf, int type, * {int --> size_t} size); # D.9.5.6 The setvbuf function * The setvbuf function {is --> may be} used after the stream point- ed to by stream has been associated with an open file but before it is read or written. # D.9.5.6 The setvbuf function * ... _IOFBF causes input/output to be fully buffered {, if possi- * ble -->}; _IOLBF causes input/output to be line buffered {, if possible -->} ...; _IONBF causes input/output to be completely * unbuffered {, if possible -->}. # D.9.5.6 The setvbuf function * If buf is not a null pointer, the array it points to {will --> may} be used instead of an automatically allocated buffer. ... * {--> The contents of the array at any time are indeterminate.} ... The buffer must have a lifetime at least as great as the * open stream, so the stream {must --> should} be closed before a buffer that has automatic storage duration is deallocated upon block exit. # D.9.5.6 The setvbuf function The setvbuf function returns non-zero if an invalid value is * given for type or size {-->, or if the request cannot be honored}. # D.9.6.1 The fprintf function * An optional decimal {digit string --> integer} specifying a minimum "field width". ... The padding is with spaces unless * the field width {digit string --> integer} starts with a zero, in which case the padding is with zeros. * An {--> optional} "precision" ... The precision takes the form * of a period (.) followed by an {--> optional} decimal {digit * string --> integer}; {a null digit string --> if the integer is omitted, it} is treated as zero. # D.9.6.1 The fprintf function An optional h specifying that a following ... conversion specif- ier applies to a short int or unsigned short int argument (the argument will have been promoted ... and its value shall be * {cast --> converted} to a short int or unsigned short int before printing) ... # D.9.6.1 The fprintf function * c The {least significant byte of the -->} int argument is * converted to a {character --> char}, and {--> the result- ing character is} printed. # D.9.6.1 The fprintf function <--O If the character after the % is not a valid conversion specifier, <--O the behavior is undefined. N--> If the conversion specifier is a lower-case letter that is not N--> described above, the behavior is undefined. If the conversion N--> specifier is any other character that is not described above, the N--> behavior is implementation-defined. # D.9.6.1 The fprintf function * {--> #include } fprintf(stdout, "%s, %s %d, %.2d:%.2d\n", weekday, month, day, hour, min); ... #include * {--> #include } fprintf(stdout, "pi = %.5f\n", 4 * atan(1.0)); # D.9.6.2 The fscanf function * Conversion specifications, consisting {--> in sequence} of the character %, an optional assignment-suppressing character *, an * optional {numerical --> decimal integer that specifies the} max- imum field width, ... # D.9.6.2 The fscanf function ... The following conversion specifiers are valid: * d An {--> optionally signed} decimal integer is expected; ... # D.9.6.2 The fscanf function * ... the {subsequent --> corresponding} argument shall be a pointer to integer. Remark: This change is made throughout the section. # D.9.6.2 The fscanf function <--O i An integer is expected; the subsequent argument must be a <--O pointer to integer. The input is interpreted as an in- <--O teger constant, with an optional sign prefix and an op- <--O tional integer suffix. If the input field begins with <--O the characters 0x or 0X, the field is taken as a hexade- <--O cimal integer. Otherwise, if the input field begins with <--O the character 0, the field is taken as an octal integer. <--O Otherwise, the input field is taken as a decimal integer. N--> i An integer is expected; the corresponding argument shall N--> be a pointer to integer. The input format is as N--> described for the strtol function, with the value 0 for N--> the base argument. ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:29:24 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. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5643 for JMS@ARIZMIS; Wed, 21-MAY-1986 12:01 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024277; 20 May 86 19:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a014477; 20 May 86 18:59 EDT From: Orlando Sotomayor-Diaz Newsgroups: mod.std.c Subject: mod.std.c Digest V16#12 Message-ID: <1050@hou2d.UUCP> Date: 15 May 86 17:29:13 GMT Approved: osd@hou2d.UUCP To: info-c@BRL-SMOKE.ARPA From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 12 Today's Topics: MORE C standard differences Apr85-Feb86, part 2 of 9 ---------------------------------------------------------------------- Date: From: ihnp4!utzoo!lsuc!msb Subject: MORE C standard differences Apr85-Feb86, part 2 of 9 To: utzoo!ihnp4!hou2d!osd # D.3.1 Character testing functions * In an implementation that uses the {--> seven-bit} ASCII charac- ter set, the printing characters are those whose values lie * between 0x20 (space) and {0xFE --> 0x7E} (tilde); the control * characters are those whose values lie between 0 (NUL) and {0x17 * --> 0x1F} (US), and the character {0xFF --> 0x7F} (DEL). # D.3.1.1 The isalnum function * The isalnum function tests for any {letter or digit --> character for which isalpha or isdigit is true}. # D.3.1.2 The isalpha function * The isalpha function tests for any {letter --> character for which isupper or islower is true, or any of an implementation- defined set of characters for which none of iscntrl, isdigit, ispunct, or isspace is true}. # D.3.1.6 The islower function * The islower function tests for any lower-case letter {--> as de- fined in #B.2.1, or any of an implementation-defined set of char- acters for which none of iscntrl, isdigit, ispunct, or isspace is true}. Remark: Likewise for isupper (#D.3.1.10). # D.3.1.8 The ispunct function The ispunct function tests for any printing character except * space (' ') {, a digit, or a letter --> or a character for which isalnum is true}. # D.3.2.1 The tolower function If the argument is an upper-case letter, the tolower function re- * turns the corresponding lower-case letter {-->, if any}; ... Remark: Likewise for toupper (#D.3.2.2). # D.4 LIMITS {--> and} * The headers {--> and} define several macros * that ... were listed in {#B.2.4.1 --> #B.2.4.2}. # D.5 MATHEMATICS ... HUGE_VAL * which expands to a positive double expression {-->, not neces- sarily representable as a float}. # D.5.1 Treatment of error conditions * On a domain error, the {int --> integer expression} errno {is set to --> acquires the value of} the macro EDOM, and the function * returns {the value indicated --> an implementation-defined value}. Remark: The sentences that formerly gave the value that each function returned on a domain error are deleted, but I will not list them individually. # D.5.2.3 The atan function * The atan function returns the arc tangent in the range {[-pi/2, pi/2] --> (-pi/2, pi/2)}. Remark: In other words, the endpoints of the range are now impos- sible. # D.5.4.4 The log function * A domain error occurs if the argument is {zero or -->} negative. * {--> A range error occurs if the argument is zero.} Remark: Likewise for log10 (#D.5.4.5). # D.5.6 {--> Nearest integer,} absolute value, {nearest integer, -->} and {modulo --> remainder} functions Remark: The abs function is moved from #D.5.6.1 to #D.10.6.1. See below. The other functions' sections are renumbered accord- ingly. # D.6.1.1 The setjmp function * {--> If the return is from a direct invocation,} the setjmp func- * tion returns the value zero. {--> If the return is from a call to the longjmp function, the setjmp function returns a non-zero value.} # D.6.2.1 The longjmp function All accessible objects have values as of the time longjmp was * called, except that the values of objects of {storage class re- gister --> automatic storage class that do not have volatile type} and have been changed between the setjmp and longjmp calls are indeterminate. # D.7 SIGNAL HANDLING * Additional signals, {--> with macro definitions beginning with the letters SIG followed by an upper-case letter and} with signal numbers distinct from those listed, may also be specified by an implementation. # D.7 SIGNAL HANDLING N--> The names of the signal numbers reflect the following terms N--> (respectively): abort, floating-point exception, illegal instruc- N--> tion, interrupt, segment violation, and termination. Remark: Respectively, that's SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM. # D.7.1.1 The signal function N--> As the functions in the standard library are not guaranteed to be N--> reentrant and may modify objects with static storage duration, N--> they may not be used reliably in a signal handler that returns. # D.8 VARIABLE ARGUMENTS * The header declares a type {--> and a function} and * {--> defines} {several --> two} macros for advancing through a list of arguments ... # D.8 VARIABLE ARGUMENTS A function may be called with a variable number of arguments of * varying types. As described in {#C.7.1.1 --> #C.7.1}, its param- eter list contains one or more parameters. # D.8.1 Variable argument list access macros {--> and function} * The {capabilities --> va_start and va_arg macros} described in this section shall be implemented as macros, not as real func- tions. Remark: Va_end is now allowed to be a function, and this change applies throughout this section. # D.8.1.2 The va_arg macro * {--> If} the specified type {must agree --> disagrees} with the type of the actual next argument (as promoted ... into int, un- * signed int, or double) {-->, the behavior is undefined}. # D.8.1.2 The va_arg macro N--> The first invocation of the va_arg macro after that of the N--> va_start macro returns the value of the argument after that N--> specified by parmN. Successive invocations return the values of N--> the remaining arrguments in succession. # D.8.1.3 The va_end {macro --> function} * The va_end function {performs any processing so that --> facili- * titates} a normal return {may safely occur -->} from the function whose variable argument list was referenced by the expansion of * va_start that initialized the va_list ap. ... {--> If} the * va_end function {must be --> is not} invoked {after all arguments have been accessed --> before the return, the behavior is unde- fined}. # D.9.1 Introduction ... _IOFBF which expands to an integral constant expression, suitable for * use as the third argument to the setvbuf function {, to indicate that full buffering is desired -->}. Remark: The analogous phrases are deleted from the descriptions of _IOLBF, _IONBF, SEEK_CUR, SEEK_END, and SEEK_SET. # D.9.1 Introduction ... SYS_OPEN which expands to an integral constant expression that is the * minimum number of files that {may --> the implementation guaran- tees can} be open simultaneously. # D.9.2 Streams * A text stream is an ordered sequence of {bytes --> characters} composed into "lines" ... * A binary stream is an ordered sequence of {bytes --> characters} that can transparently record internal data. # D.9.2 Streams N--> Whether a text line containing only a single space character plus N--> a terminating new-line character is converted on input to a line N--> consisting only of the terminating new-line character is N--> implementation-defined. # D.9.3 Files If a file can support positioning requests ... then a "file * {pointer --> position indicator}" associated with the stream is ... Remark: This change of terminology applies throughout the sec- tion. # D.9.3 Files N--> When a stream is unbuffered, characters are intended to appear N--> from the source or at the destination as soon as written. When a N--> stream is fully buffered, characters may be accumulated and N--> transmitted to or from the host environment as a block when a N--> buffer is filled. When a stream is line buffered, characters may N--> be accumulated and transmitted to or from the host environment as N--> a block when a new-line character is encountered or when a buffer N--> is filled. Support for these characteristics is implementation- N--> defined, and may be controlled via the setbuf and setvbuf func- N--> tions. # D.9.3 Files N--> Whether a file of zero length (on which no characters have been N--> written by an output stream) actually exists is implementation- N--> defined. # D.9.3 Files * At program startup, three text {files --> streams} are {open --> predefined and need not be opened explicitly} -- "standard input" * ... "standard output" ... and "standard error" ... {--> When opened, the standard streams are fully buffered if and only if the stream does not refer to an interactive device.} ... # D.9.4.1 The remove function * The remove function returns {--> zero if the operation succeeds,} * non-zero if {the operation --> it} fails. # D.9.4.2 The rename function * The rename function returns {--> zero if the operation succeeds,} * non-zero if {the operation --> it} fails {-->, in which case if the file existed previously it is still known by its original name}. N--> Among the reasons the implementation may cause the rename func- N--> tion to fail are if the file is open or if it is necessary to N--> copy its contents to effectuate its renaming. # D.9.4.4 The tmpnam function * The tmpnam function generates a string that {can safely be used as the name of a temporary --> is not the same as the name of an existing} file. * ... a different {file name --> string} each time it is called * {--> up to TMP_MAX times. If it is called more than TMP_MAX times, the behavior is implementation-defined}. * ... The value of the macro TMP_MAX {specifies the minimum number of unique names that must be generated by the tmpnam function be- fore any names repeat, which -->} shall be at least 25. ------------------------------ End of mod.std.c Digest - Thu, 15 May 86 13:28:42 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. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 8848 for JMS@ARIZMIS; Wed, 21-MAY-1986 14:40 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/21/86 at 15:57:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024038; 20 May 86 19:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a014100; 20 May 86 18:44 EDT From: david%ukma.uucp@BRL.ARPA Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Re: allocating arrays Message-ID: <3423@ukma.UUCP> Date: 14 May 86 14:29:15 GMT Xref: brl-sem net.lang.c:1120 net.micro.pc:1202 net.unix:735 To: info-c@BRL-SMOKE.ARPA [My mailer doesn't know anything about dg_rtp.UUCP, could you please let uucpmap@cbosgd know of your existance????] In article <350@dg_rtp.UUCP> you write: >> allbery@ncoast.UUCP (Brandon Allbery) > >> | Consider an array of 15 pointers to arrays of doubles: >> | double (*parray[15])[]; >> | The following code to 'malloc' the actual double array barfs on Microsoft 'C', >> | with a 'different levels of indirection' warning on the '='. >> | The code passes through LINT, and compiles OK on UN*X 5.2 >> | char *malloc(); >> | parray[0] = (double*)malloc((unsigned)sizeof(double)*75); > >> double (*parray[15])[]; means: >> an indefinitely-sized array of (or a pointer to) >> an array of 15 >> (double *) > >Wrong. It means just what the original poster said it meant. It is an >array of 15 pointers to arrays of double. What the original poster is >mistaken about is that lint doesn't complain about the example. In >particular, given this example I respectively submit that you're full of it and that Brandon is correct. Using []'s in a declaration is SIMILAR to declaring a pointer, 'cept that the pointer is an internal constant in the compiler, and if you fill in a value inside the []'s it allocates some space. A stumbling point is when a [] declaration is an arg to a function, THAT gets translated to a * declaration... Some examples: char a[] = "this is a character string\n"; char b[]; (oh, they're both external decl's) Tell me tho, what USE is a the declaration of b[]???? Translating the decl to *b isn't doing what I SAY, and (on Unix anyway) what I SAY is what I MEAN. Anyway, compiling I get: Undefined: _main _b _main is undefined because I don't have a main() obviously. _b is undefined because it knew that somewhere there's a b[] and made a reference to it. Modifying it to read: char a[] = "this is a character string\n"; main() { char b[], *c; char *malloc(); printf("b = 0x%x\n", b); /* b = */ c = malloc(5); printf("b = 0x%x, c = 0x%x\n", b, c); } produces: b = 0x7fffe880 b = 0x7fffe880, c = 0x2800 (BTW, this is a Vax running 4.2BSD, and we have the "hated" pcc, a value like the one for b is a stack location) Originally I had the b[] decl by itself and the compiler swallowed it. (I have no idea what the compiler thought I wanted to do with a b[]...) But it didn't like it when I had the b = uncommented... (which is what I'd expect). Looking at the assembler output, b[] is a pointer to the top of the stack but there's no space allocated to it. There's only space allocated for the *c. > > void f(){ > double (*a[15])[]; > char *malloc(); > a[0] = (double *)malloc((unsigned)sizeof(double)*75); > } >lint (on our system at least) says > warning: illegal pointer combination > (4) Right. the pcc says "illegal lhs" or something to that effect. Which is correct... there's no space allocated to your a. > >I grant you, this isn't very informative, but lint *doesn't* like it, >that much is certain. Let's run a more blabbermouth tool over it. > ... [deleted, for the sake of brevity, some very interesting output] > >As you can see, this is an attempt to assign a pointer-to-double to a >pointer-to-array-of-double. In this case, it is easy to tell that this >is what is going on even without blabbermouth typecheckers. The >declaration of a is of the form (*[])[], making the type of a[0] (*)[], >a pointer to an array. The cast of the return value of malloc was >simply *, that is, a simple pointer. If you want your compiler to shut >up, you should make the cast read (double (*)[]). When the cast is >changed in this way, lint no longer complains. Changing the cast to >(double **) naturally still causes complaint. er... where did you get that program? I agree with it somewhat EXCEPT it's not making a distinction about CONSTANT pointers a la arrays. It's an interesting program nonetheless... I agree with you that the compilers need to produce better error messages. -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@uky.csnet Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2903 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:21 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/22/86 at 01:04:44 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024453; 20 May 86 19:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a014845; 20 May 86 19:12 EDT From: Davidsen Newsgroups: net.lang.c,net.unix-wizards Subject: Re: arguments in registers Message-ID: <743@steinmetz.UUCP> Date: 14 May 86 17:11:37 GMT Xref: brl-sem net.lang.c:1125 net.unix-wizards:1249 To: info-c@BRL-SMOKE.ARPA In article <109@ima.UUCP> johnl@ima.UUCP (John R. Levine) writes: >In article <1205@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >>In article <155@cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>>[Passing arguments in registers] would be fine if C had nested >>>procedures or inlines or something, but a disaster otherwise. >> The original "B" compiler for the GECOS operating system passed the first two arguments in registers and it worked fine. There are no inherent limitations, and it makes the code run much faster. Someone doing software metrics told me that 90% of the procedure calls in UNIX source code use <3 arguments, and running over about 50k lines of code by people at our site it looks as if that's true, even more so if you eliminate printf, which hopefully isn't called as often as the internal routines. There are three cases of action if the first N arguments are passed in registers: a) the values are never stored in memory and the procedure runs faster. b) the values are stored in memory when needed to preserve them during a procedure call, or when the registers are required for inline code. c) the compiler just stores the value in memory (stack of course) and goes on as if the calling program had done it. Note that in the worst case, the code to save the values has been moved from the calling routines to the called routine, making the code smaller, if not faster. In 1972 I produced a language called IMP from the original B, and it ran on the GE 600 series and the INtel 8080 (and could cross compile in either direction). If it can be done on an 8080, it can be done anywhere. The code was smaller and faster than that produced by any C compiler I've ever seen for the 8080, due in part to the frequent occurence of case (a) above, where the values were never stored. -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3033 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:32 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024518; 20 May 86 20:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a014864; 20 May 86 19:13 EDT From: D Gary Grady Newsgroups: net.lang.c,net.lang.apl Subject: Nial, an extended apl Message-ID: <1571@ecsvax.UUCP> Date: 16 May 86 15:27:43 GMT Xref: brl-sem net.lang.c:1126 net.lang.apl:20 To: info-c@BRL-SMOKE.ARPA I've been playing lately with the Nested Interactive Array Language NIAL (pronounced "kneel"). It allows arrays to contain other arrays of arbitrary type and dimensionality. It uses the normal ASCII character set and has about a billion reserved words. It also has the structural features missing from APL. (Anyone who thinks APL primitives in clever combinations are all-powerful is invited to write a program to compute a determinant in apl. And don't try to weasel out by insisting determinants are a Bad Thing.) The version I'm using (Q'Nial on an IBM PC) cleverly displays the structure of arrays by means of boxes drawn with the IBM extended character set. Using conventional ASCII, this means that if I type in the statement ("Tom 17)("Dick 9)("Harry 44) I see something like this: +-------------------+-----------------+--------------------+ | +---------+-----+ | +---------+---+ | +----------+-----+ | | | Tom | 17 | | | Dick | 9 | | | Harry | 44 | | | +---------+-----+ | +---------+---+ | +----------+-----+ | +-------------------|-----------------+--------------------+ Here's a Nial program: fibonacci IS OPERATION N { Fiblist get 0 1 ; WHILE last Fiblist < N DO (last Fiblist + last front Fiblist); ENDWHILE ; front Fiblist } Yes, it does look like an unholy union of APL, Lisp, and C. And that's not a bad description. I like the structured programming constructs and the ability to apply operators to even user-defined functions ("transformers" to user-defined "operators" in Nial terminology). I don't like the long list of reserved words (worse than Cobol), the confusing rules about how deeply into a structure an operator reaches, the equally confusing rules on precedence of monadic and dyadic operators (and the fact that ALL operators can be used in monadic or dyadic form; that is, + 1 2 is the same as 1 + 2!). Nial exists mainly as an expression of the nested rectangular array theory of Trenchard More. I don't know that it's of much value as a practical language right now, but there is some promise for the future. If you'd like more information try writing Nial Systems Limited, 20 Hatter St, Kingston, Ontario K7M 2L5. I'm not connected with them. -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3142 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:37 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024530; 20 May 86 20:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a015249; 20 May 86 19:27 EDT From: Larry Cipriani Newsgroups: net.lang.c Subject: What's wrong with printf() , exit() ? Message-ID: <117@danews.UUCP> Date: 11 May 86 12:31:22 GMT To: info-c@BRL-SMOKE.ARPA > What's wrong with > printf("usage: foo bar\n"), exit(1); > as above? > Aside from style, exit is a statement syntatically but , requires expressions. The compilers I've used will accept this and do what you'd expect. Why is that ? Is this a special exeption ? Compilers may exist that won't accept it. However, this: printf("uage: foo bar\n"), return 1 ; generates a syntactic error message. If a compiler accepts , exit() why not , return ? Maybe it's too complicated to do, and not worth the trouble. Some uses of , are transparent and useful. Such as multiple initial- izations in a for loop, e.g. for(i = 0 , j = 1; ...). Doing all the relevant initializations in one place is important. Or in a while loop: while(readresp(CMD), command) where readresp is a void function (and has to be) and command is side affected several routines down. Coding this without the , obscures the code (at least to me). -- Larry Cipriani Nothing is worse than having danews!lvc an itch you can never scratch Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3219 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:43 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024532; 20 May 86 20:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a015253; 20 May 86 19:28 EDT From: Larry Cipriani Newsgroups: net.lang.c Subject: Re: What's wrong with printf() , exit() ? (oops) Message-ID: <118@danews.UUCP> Date: 11 May 86 17:49:33 GMT To: info-c@BRL-SMOKE.ARPA I wrote: >> What's wrong with >> printf("usage: foo bar\n"), exit(1); >> as above? >> >Aside from style, exit is a statement syntatically but , requires >expressions. The compilers I've used will accept this and do >what you'd expect. Why is that ? Is this a special exeption ? Oops. I mistakenly believed exit and return were both reserved words in C but only return is. There may be compilers that won't accept it but they would be wrong. printf("usage: foo bar\n") , return 1 ; seems reasonably "within C's style". Comments ? -- Larry Cipriani Nothing is worse than having danews!lvc an itch you can never scratch Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3283 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:50 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024534; 20 May 86 20:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a015261; 20 May 86 19:28 EDT From: Lee Dickey Newsgroups: net.lang.c Subject: Re: Proliferation of operators (was: C Builtin Functions) Message-ID: <372@water.UUCP> Date: 16 May 86 12:33:18 GMT To: info-c@BRL-SMOKE.ARPA There are several APL's that admit data with tree structure. An older example of one of these is Honeywell's GCOS APL, which since the early 70's ran on its 66 series machines, and now runs on its DPS 8 line. GCOS APL allows things of the sort a <- 'now is the time' b <- 'next one' c <- 'the third' list <- (a;b;c) and more. A list may contain, as an element, any other list. You can construct a tree. Honeywell is not agressive in marketing this product. Today, there are two newer APL's that use strand notation, APL2 and STSC's production APL. Perhaps the best known of these is IBM's product: APL2. There, one uses "strand notation" and one types something like list2 <- 'now is the time' 'next one' 'the third' or list2 <- a b c Of course, allowing this sort of statement introduces a lot of power in the data, but introduces new complications in the syntactic analyzer. On the other hand, another new implementation is the one done by I.P.Sharp Associates. There one builds arrays in which each element of the array is a scalar (same as in APL). But there are new primitives called enclose and disclose. The result of enclose is always a scalar. Disclose is a left inverse of enclose. Then, for any data object, BLAT, BLAT <---> disclose enclose BLAT A fourth implementation is NIAL (Nested Interactive Array Language) developed by Mike Jenkins at Queens' University in Kingston. His language runs on UN*X machines and on IBM PC's. It appear to be a super set of APL, and uses keywords. It has rooted trees, and it has Pascal like structured statements. Perhaps the Sharp version is the most esthetically beautiful and has the simplest theory. The strand notation supported by APL2 may be easier to use if the for trees are simple, but I am told that some trees can not be modelled in this APL. NIAL has the advantage that it does not have to have a special keyboard, it has all the power of APL, and it has structured control statements. ---------------- Yo pays yer money an' yo takes yer choice. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3341 for JMS@ARIZMIS; Wed, 21-MAY-1986 23:54 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024623; 20 May 86 20:38 EDT Received: from USENET by SMOKE.BRL.ARPA id a015966; 20 May 86 19:56 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: Re: What's wrong with printf() , exit() ? (oops) Message-ID: <5470@alice.uUCp> Date: 17 May 86 04:22:37 GMT To: info-c@BRL-SMOKE.ARPA > Oops. I mistakenly believed exit and return were both reserved words > in C but only return is. There may be compilers that won't accept it > but they would be wrong. > > printf("usage: foo bar\n") , return 1 ; > > seems reasonably "within C's style". Comments ? return isn't an expression. You can't write printf("usage: foo bar\n") , if (!fflag) exit(1); either. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3420 for JMS@ARIZMIS; Thu, 22-MAY-1986 00:04 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a024625; 20 May 86 20:39 EDT Received: from USENET by SMOKE.BRL.ARPA id a015973; 20 May 86 19:56 EDT From: Andrew Koenig Newsgroups: net.unix,net.micro.att,net.lang.c Subject: Re: query: argument passing on UNIX PC, VAX, et al Message-ID: <5471@alice.uUCp> Date: 17 May 86 04:25:45 GMT Xref: brl-sem net.unix:749 net.micro.att:271 net.lang.c:1136 To: info-c@BRL-SMOKE.ARPA > I am interested in the precision used by various C compilers when > passing arguments on the stack to a called routine. For example: > > some_routine_or_main() > { > char a,b; > > foo(a,b) > } > > foo (a,b) > long a,b; > > { > printf("%#lx\t%#lx\n", a, b); > } > > I tried a program similar to the above on a vax and a UNIX PC > and in both cases the values of 'a' and 'b' were correctly > passed. Given that a long on both machines is 32 bits and a char > is 8 bits, from this I assumed that both compilers are expanding > 'a' and 'b' to 32 bits before putting them on the stack. I might > have expected this for the vax, but not for the UNIX PC (68000 > based). The definition of C is that char or short arguments are expanded to ints. Both the VAX and UNIX PC (and the 3B machines, for that matter) support 32-bit ints. Since subscripts are ints rather than longs, a machine that implements only 16-bit ints has a rather hard time dealing with arrays with more than 32767 elements. This is, of course, often the case on little machines like PDP-11 or 8086. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3287 for JMS@ARIZMIS; Tue, 27-MAY-1986 06:17 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:01:48 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010124; 27 May 86 8:45 EDT Received: from USENET by SMOKE.BRL.ARPA id a015938; 23 May 86 5:51 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: More extensions to C (was: Boolean Operators Slighted in C) Message-ID: <1483@mmintl.UUCP> Date: 20 May 86 22:54:02 GMT Posted: Tue May 20 18:54:02 1986 To: info-c@BRL-SMOKE.ARPA In article <826@bentley.UUCP> kwh@bentley.UUCP writes: >In article <2741@utcsri.UUCP> greg@utcsri.UUCP writes: >>In article <602@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>>3) Exchange operator. ... >> >>Good stuff. Even machines without an EXG can use a scratch register, which >>is better than using a user-supplied temp. > >This could be considered a special case of my ",," operator: to exchange x >and y, write "x = (y ,, (y = x))". I would prefer a syntax like "{x, y} = {y, x};" It's more readable. (BTW, a really good optimizing compiler can optimize out the temporary. I'm not fully up on what optimizers are doing these days, but I doubt that there are many compilers which do this. Optimizing it out is easier if it is declared locally ("{int temp = x; x = y; y = temp;}") instead of being declared at the top of the routine.) Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3341 for JMS@ARIZMIS; Tue, 27-MAY-1986 06:21 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:02:46 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a009978; 27 May 86 8:42 EDT Received: from USENET by SMOKE.BRL.ARPA id a015918; 23 May 86 5:51 EDT From: "Frank A. Adrian" Newsgroups: net.lang.c Subject: YANO (Yet Another New Operator) Message-ID: <304@apollo.mentor.UUCP> Date: 16 May 86 22:13:26 GMT To: info-c@BRL-SMOKE.ARPA Yes, I know the purists don't want their langauge munged around, but having been working on a program that uses several arrays of linked lists, I was wondering about: (A very long computataion which gets you to a pointer) ->= next; which of course is equivalent to (A...) = (A...)->next; Of course, this would be checked by lint (or some of the newer cc's) to make sure you are assiging a pointer field to the same type of pointer. With this construct, a nice list search could be written as: for(x = foo; x && (x->key != key); x ->= next); /* ^^^^^^^^^^^^^^^^^^^^ I know, non-portable, but it works for me */ return x; I know this is probably unnecessary for efficiency, as most optimizing compilers will put the left hand side in a register, but it does increase clarity in some cases, such as: a[x++] = a[x]->next; or a[x] = a[x++]->next; I have trouble remembering in what order the increment takes place. Is it before or after the assignment (No fair peeking in K&R!)? The semantics of a[x++] ->= next; is clear -- the increment takes place after the asignment. In any case, I don't think that this would mung up the language too bad, and comments about how tough it is to add "features" to compilers don't bother me at all (I don't have to write them, I just have to use them). Frank Adrian The opinions expressed here are in no way reflect those of ANY sane person or organization. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3551 for JMS@ARIZMIS; Tue, 27-MAY-1986 06:48 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:21:51 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010335; 27 May 86 8:49 EDT Received: from USENET by SMOKE.BRL.ARPA id a016202; 23 May 86 5:59 EDT From: ron@BRL-SEM.ARPA Newsgroups: net.lang.c Subject: Re: Infinite Loops Message-ID: <185@brl-sem> Date: 30 Apr 86 05:10:00 GMT To: info-c@BRL-SMOKE.ARPA > Unless you have a very unique optimizer, it is usually better to use the > for(;;) form rather than the while(1) form. Reason is: while(1) is > ALWAYS evaluated (ie. : is 1 TRUE? if so, continue) before each iteration, > whereas for(;;) compiles as a simple branch or jump instruction with no > test and no conditional branch. > Crapola. All the PCC impementations I've checked don't test the constant even when you don't turn the optimizer on. Our old PDP-11 Ritchie compiler does generate the test, but the standard -O optimizer removes it. Nothing unique here. -Ron Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3645 for JMS@ARIZMIS; Tue, 27-MAY-1986 06:50 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:22:16 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010253; 27 May 86 8:48 EDT Received: from USENET by SMOKE.BRL.ARPA id a015942; 23 May 86 5:52 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: using indentation rather than braces Message-ID: <1484@mmintl.UUCP> Date: 20 May 86 23:05:03 GMT Posted: Tue May 20 19:05:03 1986 To: info-c@BRL-SMOKE.ARPA In article <968@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: > >Forgive me if this is too obvious to mention, but it seems to me that using >the indentation information makes life much harder for programs like YACC >and LEX that act by creating C source code. Now they have to keep track of >what column they are outputting to... This isn't all that hard. Such programs must implicitly keep track of depth, frequently by recursion. Adding the additional machinery to make this explicit is not bad. One global variable, and update it every time you enter or exit a block in the generated code. >I just remember doing some assembly macros that tried to make their >expansion obvious by "display"ing the code they were generating to the >listing before actually generating it. There was real gore in getting the >columns lined up right, and in getting meaningful comments... Dealing with such issues in the macro processing portion of an assembler is another matter entirely. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3838 for JMS@ARIZMIS; Tue, 27-MAY-1986 07:08 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:49:18 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010381; 27 May 86 8:51 EDT Received: from USENET by SMOKE.BRL.ARPA id a016918; 23 May 86 7:41 EDT From: Roy Smith Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <2355@phri.UUCP> Date: 21 May 86 00:45:12 GMT Posted: Tue May 20 20:45:12 1986 To: info-c@BRL-SMOKE.ARPA In article <1463@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > Something which got forgotten in my original article: I would favor an > exchange operator. This one is quite frequently useful, and the > alternatives are ugly. Why don't we just invent a new language? We could call it PL/2. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3953 for JMS@ARIZMIS; Tue, 27-MAY-1986 07:27 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 08:57:31 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010478; 27 May 86 8:54 EDT Received: from USENET by SMOKE.BRL.ARPA id a016931; 23 May 86 7:42 EDT From: Guy Harris Newsgroups: net.lang.c Subject: Re: void * (was Re: malloc()) Message-ID: <3717@sun.uucp> Date: 20 May 86 18:36:17 GMT To: info-c@BRL-SMOKE.ARPA > So, although not necessarily synonyms, they ("char *" and "void *" - gh) > do have the same properties, except that "char *" conversions usually > require a cast to be acceptable. Well, 1) they don't have the same properties - if you dereference a "char *", you get a "char", while if you dereference a "void *", you get a "void", which means you can't dereference a "void *" without casting it to a pointer to some meaningful type (this, in answer to your question below, is presumably why "void *" was chosen) 2) the fact that "char *" conversions require a cast is NOT a characteristic of the language, but a characteristic of the compiler/"lint". A C compiler which never generated any warnings about pointer conversions would not be in violation of the language specification. As such, a C compiler could, if its author wanted it to, generate warning messages about "illegal pointer combination" and about "possible pointer alignment problem" for implicit conversions (i.e., conversions not involving casts) between "char *" and other pointers, and not generate them for implicit conversions between "void *" and other pointers. It could generate both warning messages for all implicit pointer conversions, and generate them for all explicit pointer conversions except those involving "void *". A compiler which did so would not assign "char *" and "void *" the same properties, since replacing objects of type "void *" with objects of type "char *" in some expressions would cause warnings to be issued. > What I had in mind was that "ALIGN *" would be a synonym for "int *" or > whatever happens to be the most restrictive pointer type. The "guarantee" > would be as good as the "guarantee" on an "int *". I.e., not very good. Again, you would have to trust "malloc" to know what it was doing, just as you would have to do if it returned "void *". Somewhere inside the guts of "malloc" there would probably be an conversion of a "char *" to a "void *" or an "ALIGN *", and you'd have to hope that the algorithm used by "malloc" guaranteed that the pointer being converted were aligned properly. > Well, what *is* the justification for adding "void *" to the language? To > allow people to shove pointers around without casts? No. One could allow people to shove pointers around with casts simply by removing some warning messages from some current C compilers. > To make lint shut up about malloc()? In a sense, yes. It also makes it possible to use "opaque pointers" without getting complaints from the compiler. We currently run our kernel through "lint" before it goes out the door; the "lint" rules in the 4.2BSD kernel "makefile" run the "lint" output through "egrep" to eliminate "possible pointer alignment problem" messages, since there are a number of cases where there are no such problems but we have no way to tell "lint" that. If "caddr_t" were "void *" instead of "char *", we wouldn't have to strip out all "possible pointer alignment problem" messages; any that appeared would indicate that there was a real problem in the code. > Or just to distinguish "generic pointers" from pointers that can be > dereferenced? (Could be done with a typedef. So could "void", but > they put it in anyway.) You can do "void" and "caddr_t" (or whatever you want to call a "generic pointer") with "typedefs", but you can't make the compiler recognize their unique properties that way. If you do "typedef int void;", the compiler will not recognize that casting something to "void" throws its argument away, and certainly won't recognize that "void foo();" declares a function which doesn't return a value. If you declared "caddr_t foop;", the compiler would let you dereference "foop" in an expression. As such, I presume by "distinguish" you mean "distinguish *for the reader of code*", not "distinguish for the compiler". That is one thing you can use "void *" to do, but it's not the only reason it was proposed. > I do not strongly object to the addition of "void *", but I am worried about > it "hiding" errors. (I'm one of those purists who thinks that programmers > *should* use casts to change types.) Yes, if some compiler implementer misses the obvious, it could be used to hide errors. (Unfortunately, I've seen a lot of cases where implementers miss the obvious.) If one assumes that the current PCC/"lint" rules for complaining about pointer conversions are correct, the correct extension of those rules to "void *" is: implicit conversions to and from "void *" should generate "illegal pointer combination" warnings (although they need not give "possible pointer alignment problem" warnings) explicit conversions (i.e., conversions with casts) should not give any "possible pointer alignment problem" warnings; if you specify the "-c" flag to older "lint"s, or the "-p" flag to newer ones (both of which turn on the "complain about all pointer casts" flag - older versions give "illegal pointer combination" warnings, and newer ones give "pointer casts may be troublesome"), it should probably continue to give warnings. This means that if you're going to toss pointers around casually, the compiler is at least going to warn you about it; you have to say "I know what I'm doing, shut up" by adding casts if you don't want errors. In fact, I would suggest that all conversions between pointers other than "void *" should get "illegal pointer combination" (or, perhaps, "questionable pointer combination", at least in some cases, since the C standard does permit certain combinations) warnings, even if casts are used. > Also, it's a misnomer; it has nothing to do with "void". I presume the reason why "void *" was chosen is, as stated above, that a pointer of type "void *" would, when dereferenced, yield an object of type "void", and as such dereferencing a "void *" would be illegal, just as using a function of type "void" as if it returned a value would be. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7690 for JMS@ARIZMIS; Tue, 27-MAY-1986 14:41 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 15:54:22 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a010532; 27 May 86 8:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a017096; 23 May 86 7:46 EDT From: Noemi Berry Newsgroups: net.lang.c Subject: Structure initialization rules question Message-ID: <696@moscom.UUCP> Date: 21 May 86 12:21:46 GMT To: info-c@BRL-SMOKE.ARPA Why is it that you can only initialize structures when they are global (outside of main() )? If you initialize a structure within a function you get an "No auto. aggregate initialization" error. I don't see anywhere in K&R where the structure initialization rules are explained. e.g.: *--------------------- Compiles struct XX { int i; } xx = { 0 }; main() { } ------------------------------* *--------------------- Doesn't compile main() { struct XX { int i; } xx = { 0 }; } -------------------------------------* Is there some good reason for this? (Is it a language inconsistency?) Is there something obvious I'm missing here?! noemi ----------- noemi berry {allegra|decvax|seismo}!rochester!moscom!noemi "On a souvent besoin de plus petit que soi" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7789 for JMS@ARIZMIS; Tue, 27-MAY-1986 14:41 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011201; 27 May 86 9:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a017275; 23 May 86 7:51 EDT From: "Donald L. Nash" Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <3414@ut-ngp.UUCP> Date: 20 May 86 17:44:23 GMT To: info-c@BRL-SMOKE.ARPA In article <1462@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > > o := as a synonym for =. Compilers could have an option to permit := only. > Why? "Since assignment is about twice as frequent as equality testing in typical C programs, it's appropriate that the operator be half as long." K&R, p. 17. Allowing := as a synonym is OK, if you prefer that operator, but why would you want to make it manditory? > > o Any sort of multi-level break statement. There is no syntacticly clean > way of adding this to C. > How about using goto? Some people may think that goto sucks wind, but it is a perfectly legitimate statement which can get you out of trouble, if properly used. > I do not support the following: > > o ^^ for logical exclusive or. Unlike the other "short-circuit" forms (&& > and ||), this doesn't save any execution -- both operands must be evaluated. So what if they both have to be evaluated? If you need to use some kludge to get ^^ (like !a != !b), you will still wind up evaluating both operands. That's just the way XOR works. Just because it requires more work is no reason to exclude it from the language. > > Frank Adams ihnp4!philabs!pwa-b!mmintl!franka > Multimate International 52 Oakland Ave North E. Hartford, CT 06108 I don't want to come off sounding like a fluff picker, so just for the benefit of those of you who care, I did agree with the rest of the article. If net traffic weren't such a big issue, I'd have included the rest of the article as well, with more agreeable comments added. Don Nash UUCP: ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!dlnash APRA: dlnash@ngp.CC.UTEXAS.EDU BITNET: cceu001@utadnx "If you can't say something nice, then don't" -- Thumper the rabbit Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7623 for JMS@ARIZMIS; Tue, 27-MAY-1986 14:42 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 15:49:06 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a025382; 27 May 86 16:32 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a013193; 27 May 86 16:18 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA24168; Tue, 27 May 86 16:18:16 edt Date: Tue, 27 May 86 16:18:16 edt From: Root Boy Jim Message-Id: <8605272018.AA24168@icst-cmr.ARPA> To: hropus!ka@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Braces Furthermore, Jim has correctly pointed out that the braces actually obscure the code for the human reader, since they add clutter without providing any new information about the program. This is *not* what I pointed out. I am against braces not because they delimit control flow statements, but because they group single statements into `blocks', which are equivalent to a single statement. I am also against control flow statements implicitly eating exactly one statement. The disadvantage to the one statement model is mismatched else's, as in: if (c1) if (c2) p(); else /* really matches c2 */ q(); In COBOL it is impossible to even write this statement because a period terminates the `if' statement, and would terminate the outer one as well. My model of structured programming parallels the Bourne shell constructs. Here, the `fi' statement (or endif, or end) is actually `part' of the `if'. It serves to delimit the range of the conditional. In fact, I still read `{' as `then', or `do' and `}' as `fi' or `end'. In fairness, C is better than most languages in this respect since it reduces begin and end to single characters. Agreed. I would like to see all control statements reduced to a symbolic token. If control statements could return values, we'd be 1/2 way there with `?:' for if-then-else. This is good enough that I do not agree with the extremes to which Jim goes to avoid braces. But C doesn't take the idea to its logical conclusion, which is to eliminate the delimiters entirely. No. The delimiters should stay. I don't trust editors to preserve formatting. This would be a disaster for portability. And white space would no longer be that. A certain amount of redundancy is necessary for cross checking. Fortunately, grouping by indentation has finally been adopted by at least one language. See the article on "Modcap" in the March issue of Sigplan Notices. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path) (Root Boy) Jim Cottrell "One man gathers what another man spills" Q: What do you call a group of UNIX bigots? A: White space. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7951 for JMS@ARIZMIS; Tue, 27-MAY-1986 14:51 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011238; 27 May 86 9:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a017876; 23 May 86 8:07 EDT From: Topher Eliot Newsgroups: net.lang.c,net.micro.pc Subject: Re: double (*parray[15])[]; Message-ID: <863@cyb-eng.UUCP> Date: 22 May 86 16:18:28 GMT To: info-c@BRL-SMOKE.ARPA (I have dropped net.unix from the newsgroups list). There has been some debate on what the declaration double (*parray[15])[]; means. David Herron seems to be arguing that it declares a zero-length array of some sort, which some people and/or compilers might interpret as being a pointer of the same sort. I admit I found his note a little hard to follow, so maybe I misunderstood him. But I thought I would add my bit of net volume in the form of an explanation of HOW I would go about parsing such a statement. My basic rule, which I have trusted for many years, is to parse it as if it were an expression, starting inside the parentheses, and obeying operator precedence rules: double (*parray[15])[]; ^^^^ 1. It's an array with 15 elements double (*parray[15])[]; ^^^^^^^^^^^ 2. It's an array of 15 pointers. double (*parray[15])[]; ^^^^^^^^^^^^^^^ 3. It's an array of 15 pointers to arrays (the sizes of these arrays being pointed at is not specified). double (*parray[15])[]; ^^^^^^^^^^^^^^^^^^^^^^ 4. It's an array of 15 pointers to arrays of doubles. There's another way to parse it, sort of from the outside in: double (*parray[15])[]; ^^^^^^^^^^^^^^^ 1. The expression (*parray[15])[] has type double. double (*parray[15])[]; ^^^^^^^^^^^^^ 2. The expression (*parray[15]) has type "array of double", with the size of the array unspecified. double (*parray[15])[]; ^^^^^^^^^^ 3. The expression parray[15] has type "pointer to array of double". double (*parray[15])[]; ^^^^^^ 4. parray has type "array of pointers to arrays of doubles", parray has 15 elements. Notice that both these methods are nice and methodical, and they both come up with the same result. I get the impression that at least one of the participants of this discussion parsed the declaration something along the lines of: double (*parray[15])[]; ^^ 1. It's a zero-length array of somethings. double (*parray[15])[]; ^ ^^ 2. It's a zero-length array of pointers to something. double (*parray[15])[]; ^^^^^^^^^^^^^^ 3. It's a zero-length array of pointers to 15-element arrays of something. double (*parray[15])[]; ^^^^^^^^^^^^^^^^^^^^^^ 4. It's a zero-length array of pointers to 15-element arrays of doubles. It is my contention that parsing a declaration this way is just plain wrong, but I admit it's an easy mistake to make, one that I myself made back before I had given this subject as much thought as I have. The original discussion involved lint and malloc; I have nothing to add to that aspect of it, so I am not repeating it here. Cheers, Topher Eliot Cyb Systems, Austin, TX (512) 835-2266 {gatech,harvard,ihnp4,nbires,seismo,ucb-vax}!ut-sally!cyb-eng!topher Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1048 for JMS@ARIZMIS; Tue, 27-MAY-1986 21:35 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 23:00:35 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011219; 27 May 86 9:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a017853; 23 May 86 8:06 EDT From: Lloyd Zusman Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1136@well.UUCP> Date: 22 May 86 18:10:30 GMT To: info-c@BRL-SMOKE.ARPA In article <2355@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: ... >> Something which got forgotten in my original article: I would favor an >> exchange operator. This one is quite frequently useful, and the >> alternatives are ugly. > > Why don't we just invent a new language? We could call it PL/2. ... or ADA++ Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1107 for JMS@ARIZMIS; Tue, 27-MAY-1986 21:41 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/27/86 at 23:06:42 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011274; 27 May 86 9:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a025042; 23 May 86 11:48 EDT From: Carl Micarelli <6063366%pucc.bitnet@BRL.ARPA> Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <602@pucc.BITNET> Date: 20 May 86 22:11:26 GMT To: info-c@BRL-SMOKE.ARPA In article <1462@mmintl.UUCP>, Frank Adams (franka@mmintl.UUCP) suggests adding the following to C: >o Any sort of multi-level break statement. There is no syntacticly clean >way of adding this to C. Good idea, but I don't think there's any syntactically clean way of implementing a multi-level break statement in C -- at least no way that's preferable to a goto. >There are several things which are not part of the language definition, but >which would be useful in compilers. These consist mostly of flagging >certain statements with (at least) warning messages. Requiring compilers to flag constructions that look like bugs is a good idea, but only if you establish a standard way of forcing the compiler to (selectively) shut up. >(Actually, I wouldn't be averse to a coding standard which forbade such >things [as if (v = e) ... ], in favor of if (v = e, v) ...) No! = is an operator, v=e has a value, and its value should be usable anywhere. Making up special rules -- even for the noble purpose of protecting programmers from carelessness or typos -- just complicates things. Carl Micarelli - BITNET: 6063366@pucc UUCP: ...allegra!psuvax1!pucc.bitnet!6063366 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3121 for JMS@ARIZMIS; Wed, 28-MAY-1986 02:04 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011393; 27 May 86 9:20 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a029062; 23 May 86 14:19 EDT Received: from nwc-143b.arpa by AOS.BRL.ARPA id a018135; 23 May 86 14:10 EDT Date: 23 May 86 10:57:00 PST From: sefunix@NWC-143B.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: Fwd to Usenet: FORTRAN-TO-C To: info-c Reply-To: sefunix@NWC-143B.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Some time ago, someone asked about a Fortan to C translation package. Since I don't know whether that was ever answered, here is the information. PRODUCT: FORTRIX-C COMPANY: Rapitech Systems, Inc. Montebello Corporate Park Suffern, NY 10901 (914) 368-3000 1-800-FORTRIX TELEX 509210 I hope this info helps. Gene Guglielmo SEFUNIX@NWC-143B.ARPA ------ Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3247 for JMS@ARIZMIS; Wed, 28-MAY-1986 02:21 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011428; 27 May 86 9:24 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a001134; 23 May 86 16:44 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA16533; Fri, 23 May 86 14:43:38 edt Date: Fri, 23 May 86 14:43:38 edt From: Root Boy Jim Message-Id: <8605231843.AA16533@icst-cmr.ARPA> To: alice!ark@ICST-CMR.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: malloc() > I don't think 'void *' is useless. What do you do on a machine > where it's NOT 'always legal to cast any pointer into a "char *"'? You don't implement C on it. When would this be illegal? If the machine was not byte addressable? I think not, because the 36 bit machine mentioned in K&R (Honeywell) obviously isn't. A decision would have to be made whether such a machine is big or little endian, but I don't see any other problem. Besides, there is nothing in the C spec that says that `character' data has to occupy only one byte. In fact, all types could occupy exactly the same amount of space on a given machine. Not the best strategy, but not illegal either. And better than no C at all. (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3343 for JMS@ARIZMIS; Wed, 28-MAY-1986 02:31 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011460; 27 May 86 9:25 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a009167; 26 May 86 4:49 EDT Received: from wiscvm.arpa by AOS.BRL.ARPA id a002025; 26 May 86 4:39 EDT Received: from (XBR2D995)DDATHD21.BITNET by WISCVM.WISC.EDU on 05/26/86 at 02:55:47 CDT Date: Mon, 26 may 1986, 09:45 B From: XBR2D995%DDATHD21.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA To: INFO-AMIGA@rutgers.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Cc: unix-sources@BRL-SMOKE.ARPA, info-c@BRL.ARPA, XBR2D995%DDATHD21.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: Problem with MANX/Aztec C (3.20a 26-Feb-86) and arrays on AMIGA. ---------------------------------------------------------------------------- This is a repost of my message from 21-May-1986. I repost it, because there are some problems on the net. By the way: whats wrong with INFO-AMIGA ??? PLEASE: Answer direct to . I'm not a member of all lists. ---------------------------------------------------------------------------- Hello, we have a serious problem with Aztec-C 3.20a and float arrays. The program at the end of my message compiles an links correctly, but gives a guru meditation (00000003.000097B0) wenn started. The program is compiled and linked with the following command: CC T3 LN T3.O -lm -lc The same program gives an assembler error when compiled with CC T3 +l We think the problem is related to the expression: z[k][m] = z[k][m] - z[k][i] * z[i][k] in the program. Reducing the "complexity" of the statement resolves both problems. Any people from Manx listening? Anybody got the same problem? Regards Martin My address: Martin Knoblauch Technische Hochschule Darmstadt Dept. for Physical Chemistry (PC 1) Petersenstrasse 20 D-6100 Darmstadt (West Germany) BITNET: ----------------------------T3.C------------------------------------- #include #include #undef NULL #include main() #define BOR 5 { int i,k,m; float a1,a2,a3; static float z[BOR][BOR]; printf(" programmstart now\n"); for(i=0;i Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <146@cs.qmc.ac.uk> Date: 20 May 86 10:49:26 GMT Posted: Tue May 20 10:49:26 1986 To: info-c@BRL-SMOKE.ARPA In article <169@comp.lancs.ac.uk> craig@comp.lancs.ac.uk (Craig Wylie) quotes: >>Using braces to indicated the structure of a program results in code that >>is quite difficult to read. (Try removing all indentation from any C >>program you choose and see how readable the result is.) Of course >>sensible programmers use indentation to indicate the structure of the >>program to the reader. I use programs like "cb" and "indent" to get my C programs indented according to what they *REALLY* mean, as opposed to what I intended them to mean (indicated by MY indenting). This can be quite illuminating.... -- William Roberts ARPA: liam@UK.AC.qmc.cs Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3524 for JMS@ARIZMIS; Wed, 28-MAY-1986 02:49 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013714; 27 May 86 10:44 EDT Received: from USENET by SMOKE.BRL.ARPA id a003999; 27 May 86 10:12 EDT From: "Joseph S. D. Yao" Newsgroups: net.lang.c Subject: Re: Followup to Very Tough C Riddle Message-ID: <396@hadron.UUCP> Date: 8 May 86 13:29:43 GMT To: info-c@BRL-SMOKE.ARPA AARRGGHHHHHHHHHHH!!!!! In article <140@delftcc.UUCP> sam@delftcc.UUCP (Sam Kendall) writes: > Even though it's not necessary for the riddle's solution, let's >take a look at the other possibility, which is for there to be a formal >parameter declaration of the form > type formal[][]; >Tony Li and Joe Yao mentioned this possibility, but they didn't think >it was legal. The passage mentioned in K&R that many people think >prohibits any adjacent pairs of empty brackets is this: > multi-dimensional array ... may be missing only for > the first member of the sequence. (section 8.4) >The passage that may allow `[ ] [ ]' for formal parameters is this >(first elipsis mine): [other ellipses mine -jsdy-] > ... [D]eclarations of formal parameters declared "array of ..." > are adjusted to read "pointer to ...". (section 10.1) > ... type formal[][]; "is adjusted to read" type (*formal)[]; >This second type is "pointer to array of unknown length". Sam, this is not legal, has never been legal, and (pray God) will never be legal. One may have the first member of the [] sequence empty because, from the rest, one can determine the size of each member of the array. One may not have pointers to or arrays of items of which one does not know the size. To see why this is so, tell me: what do arrname[1] or *++ptr reference???? By the way -- section 10.1 cited above refers, of course only to the outermost (first) []'s. Do you remember the long essay on this a year or two ago? [I don't ... if you have a copy, please send it to me ... ] -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3631 for JMS@ARIZMIS; Wed, 28-MAY-1986 02:57 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013770; 27 May 86 10:47 EDT Received: from USENET by SMOKE.BRL.ARPA id a004147; 27 May 86 10:16 EDT From: Walter Bright Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <1000@dataioDataio.UUCP> Date: 19 May 86 20:50:15 GMT To: info-c@BRL-SMOKE.ARPA In article <473@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: >What I'm waiting for is an interactive interpretive debugger that runs from >vi. The program would run interpretively until an error was encountered, >then place you at the appropriate line in the source file with the error >message displayed. Then you could go into insert mode, make the necessary >change, and resume execution. Normally interpreted languages, like APL, >often have such facilities. Are there insuperable difficulties with doing >this with a normally compiled language like C? (I'm sure it could be done >with FORTRAN, since FORTRAN interpreters are well-known... but why have we >seen no C interpreters?) Major difficulties are: 1) The preprocessor. At any line, a macro could be changed, which could change the meaning of the entire remainder of the source text. This means that 'incremental compiles' becomes 'compile from here to the end of the source text'. Of course, that means the parser must have the state of the parse saved at every line..., which obviously is impractical. 2) C isn't line oriented. This means that any line could be any part of a statement or expression. Thus, the parser must be able to back up from any point to find a 'synchronization point'. But C isn't backwardly parseable... Why BASIC and FORTRAN can be handled this way: 1) They don't have a preprocessor. 2) They are line oriented. All the parser has to do is back up to the beginning of the line (or in FORTRAN to the first line that isn't a line continuation). 3) Each line is more or less independently parseable from the rest of the program. Conclusion: The only fully functional, practical way is to do a reparse of the complete source file upon any changes (even on whitespace changes). Turbo Pascal works this way, instead of attempting to incrementally compile, Borland spent their efforts making the compile step really fast. An incremental compiler could be made if numerous assumptions and restrictions were made about what could be changed. I think the bugs and kludges that would result would make it impractical, however. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3798 for JMS@ARIZMIS; Wed, 28-MAY-1986 05:48 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022792; 27 May 86 15:03 EDT Received: from louie.udel.edu by SMOKE.BRL.ARPA id a011219; 27 May 86 14:55 EDT Received: from ccvax1 by Louie.UDEL.EDU id a029514; 27 May 86 12:50 EDT Received: by vax1.acs.udel.edu (4.12/4.7) id AA05982; Tue, 27 May 86 12:47:37 edt Date: Tue, 27 May 86 12:47:37 edt From: UFFNER Message-Id: <8605271647.AA05982@vax1.acs.udel.edu> To: info-c%brl-smoke.arpa@udel-louie.ARPA, phri!roy@vax1.acs.udel.edu.edu Subject: Re: What should be added to C > Why don't we just invent a new language? We could call it PL/2. We already have such a language. It's called "ADA" --- Tom Uffner tom%udel-cc-vax1@louie.ARPA Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3982 for JMS@ARIZMIS; Wed, 28-MAY-1986 05:58 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a026267; 27 May 86 17:55 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id aa14385; 27 May 86 17:39 EDT Received: from wiscvm.arpa by AOS.BRL.ARPA id a026124; 27 May 86 17:27 EDT Received: from (FULIGIN)UMASS.BITNET by WISCVM.WISC.EDU on 05/27/86 at 16:25:29 CDT Message-ID: <860526172949.00000634.AZZT.AA@UMass> Date: Mon, 26 May 86 17:29:49 EDT From: "Peter E. Lee" Subject: request for software pointers To: info-c@BRL.ARPA cc: info-cpm@AMSAA.ARPA Howdy, I work as a programmer in the psychology department at the University of Massachusetts (Amherst). My co-workers and I work on Gifford CompuPros running CP/M-80, CP/M-86, and MP/M-8/16, doing program development primarily in C (Aztec CII, and Optimizing C86). Unfortunately, we have been unable to to find any lint programs or pretty-printers that can run in a CP/M environment, which makes de-bugging even more of a hassle than usual. If anyone out there knows of such programs, either commercially available or in the public domain, or can find C source code to one or both, pointers would be greatly appreciated. Sincerely, -Peter E. Lee --- Please reply directly to : Fuligin%UMass.bitnet@WISCVM.ARPA Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3879 for JMS@ARIZMIS; Wed, 28-MAY-1986 06:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a025975; 27 May 86 17:07 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id aa13891; 27 May 86 16:47 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA24320; Tue, 27 May 86 16:48:53 edt Date: Tue, 27 May 86 16:48:53 edt From: Root Boy Jim Message-Id: <8605272048.AA24320@icst-cmr.ARPA> To: bentley!kwh@ICST-CMR.ARPA, info-c@BRL-SMOKE.ARPA Subject: Re: More extensions to C (was: Boolean Operators Slighted in C) >>5) Allow immediate constants. [Generalization of quoted strings.] >>... Why not int *p = &5 ... Does "&5" point to a character, short, int, unsigned, or long constant? (No fair using the left side of the assignment to disambiguate!) Good point. No proposal can claim to be perfect, and you just made an excellent case for feedback. We already have `L' as a suffix (for long). Why not go whole hog and add them all. Or maybe we need `*p = & (short) 5;'. BTW, it probably points to an int. Also a char & short on a little endian. >>6) Eliminate arrays altogether! You want to take them *out* of the language? I say let's put them *in*! As it stands, arrays are half-implemented. Well, I *would* like to see automatic dimensioning within functions. That's all I can think of that's missing. Don't even think about assignment or passing them as arguments. This never should have happened with structures either. >>And it wouldn't matter whether a variable was defined differently than it >>was declared (char x[] or char *x). I don't get it. If "char *x" is valid for all array/pointer variables, where does the memory come from, malloc()? No, it comes from the declaration `char x[10]', which is the same as `char $[10]; char *x = $;' where `$' is an invisible name. This loses space/time just to fix bad declarations. Forget it. >>8) Allow formal arguments to be declared AFTER the opening brace. >> This would allow prioritization of register variables. [register nesting suggestion deleted] (Sorry I had to quote so much here.) This has *nothing* to do with the C language; we are now in the realm of compiler implementation. Here's a Really! counter-proposal: compilers should allocate registers based on the last declaration instead of the first. (This is quite legal; "register" has no guaranteed semantics.) No way! Somebody goofed! There is no reason to go backwards when forwards is intuitive and came first. Lots of code has been written on the assumption that first is best. Have some respect. Better yet, Let's make the compilers smart enough to allocate registers on their own, and make the "register" keyword obsolete! (DEC did this.) No, let's make optimisers obsolete and make the programmer say what he means. I am willing for the compiler to optimise away it's own control structure jumps and such, but it should not waste time looking at my own code. If I put loop invariant code in a loop, I deserve to pay the price. Perhaps a separate program like lint that would tell you these things... "Warning: loop coded by bozoid pinhead at line 54" Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7474 for JMS@ARIZMIS; Wed, 28-MAY-1986 11:26 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/28/86 at 13:05:55 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a002729; 28 May 86 9:29 EDT Received: from brl-aos.arpa by SMOKE.BRL.ARPA id a025860; 28 May 86 9:10 EDT Received: from bbn-labs-b.arpa by AOS.BRL.ARPA id a001881; 28 May 86 9:01 EDT To: slezak@LLL-CRG.ARPA cc: info-c@BRL.ARPA Subject: Re: what printf returns Date: 28 May 86 08:57:44 EDT (Wed) From: Rick Genter If you examine the manual page for printf/fprintf/sprintf supplied with 4.2BSD, you'll note that it does not say that *printf returns anything. I believe that returning the character count is a holdover from Version 7 days. -------- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/506 rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbn-labs-b.ARPA (Internet old) ...!{decvax,linus}!bbnccv!rgenter (UUCP) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1331 for JMS@ARIZMIS; Wed, 28-MAY-1986 16:17 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/28/86 at 17:47:13 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a011376; 28 May 86 14:26 EDT Received: from USENET by SMOKE.BRL.ARPA id a003650; 28 May 86 14:04 EDT From: Brew Master Newsgroups: net.lang.c,net.lang.f77,net.wanted,net.sources Subject: FORTRAN -> C (or Pascal) Message-ID: <1488@cwruecmp.UUCP> Date: 23 May 86 19:02:23 GMT To: info-c@BRL-SMOKE.ARPA ***** This was previously posted without my Signature, sorry. ***** I know it has been discussed before, but are there any public domain or commercial FORTRAN to C or FORTRAN to Pascal translators? I know about FORTRIX, but I understand it costs $6000. (That is a little much since I only have convert one program!!) Any replies would be greatly appreciated! Sam Jadallah ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CSNet: Jadallah@Case ARPA: Jadallah%Case@CSnet-relay Usenet: ...!dexvax!cwruecmp!Jadallah Snail Mail: EB65, School of Medicine Case Western Reserve University Cleveland, OH 44106 "Curiosity didn't kill the cat, it was a poisoning." - E. Costello ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1457 for JMS@ARIZMIS; Wed, 28-MAY-1986 16:29 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/28/86 at 17:58:22 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012008; 28 May 86 14:43 EDT Received: from USENET by SMOKE.BRL.ARPA id a004626; 28 May 86 14:25 EDT From: Guy Harris Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <3754@sun.uucp> Date: 24 May 86 08:22:33 GMT To: info-c@BRL-SMOKE.ARPA > I also thought that casting anything into a (void*) would be a big > no-no. Lint, and maybe even the compiler, would issue loud warnings > every time one tried to do this. The key word here is "warnings". The X3J11 standard doesn't say what constructs may not give warnings; it merely states what is and isn't legal C. As long as the compiler produces code for it, X3J11 doesn't care how many complaints it puts out. Maybe C should be stricter about types (I think so), but it's too late for that. > This wouldn't matter since normal programs would never need to do it... Well, err, umm, "void *" is also useful for declaring objects used by several different modules, where each client of the object's implementation wants to store some private data in the object, and you can't get away with statically restricting the class of modules using this object. Dennis Ritchie's "streams" article in the BSTJ gives an example of this. A "queue" has pointers to "put" and "service" procedures, and a "void *" which provides private storage for those procedures. Replacing that "void *" with a "struct tty *", or a union of similar structures, would be ridiculous. Yes, you can't rely on the type system to check correctness. (Maybe something like Goedel's Incompleteness Theorem applies, where any type system strong enough that all programs written using it are "correct" is incomplete, in that there exist interesting and meaningful programs which cannot be written within this type system?) > For some perverse reason that I have never been able to understand, > X3J11 decided that any pointer could be converted to (void*) without > complaint. No, they just decided that it could be so converted in a legal C program. Appendix E.3 gives a list of warnings which many implementations might give; the situations listed are all legal C, but may not be desirable C. > (Lint complains too much about your code? Don't worry, just change > all the pointers to void* and it will shut up. (I assume you already > "#define CALL (void*)" and put CALL in front of all your function > calls so that you don't have to check any error statuses.) Perhaps > lint should have an option which redirects all output to /dev/null?) If you're worried about programmers trying to spoof "lint" you'd better find some way of preventing them from hiding all dubious code inside "#ifdef lint". C is not guaranteed to work in an environment where you have to ride herd on programmers. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1570 for JMS@ARIZMIS; Wed, 28-MAY-1986 16:41 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/28/86 at 18:11:54 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012086; 28 May 86 14:44 EDT Received: from USENET by SMOKE.BRL.ARPA id a004660; 28 May 86 14:26 EDT From: John Chambers Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <209@cdx39.UUCP> Date: 23 May 86 20:01:00 GMT To: info-c@BRL-SMOKE.ARPA > ... I happen to think that all code should be formatted such > that all funxions fit on a page. This is a good idea, but one I > seldom see adhered to. Not only do I agree, but I even think that all funxions (and even prosejurz) should fit into one screen-full. I mean, I can really only understand what I can have sitting before my eyeballs at one time. Do I follow my own advice? Are you kidding? Of course, it is easier with a 100-by-100 screen than with a 16-by-32 screen. [OK, so a screen-full IS just another kind of a page. I admit it.] -- John M Chambers (617-364-2000x7304) / cthulhu \ /usenet / inmet \ / news ...!{ harvax }!cdx39!{ jc \ mit-eddie / \ uucp \ mot[bos] / \root Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3017 for JMS@ARIZMIS; Thu, 29-MAY-1986 15:57 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/29/86 at 16:50:32 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012876; 28 May 86 15:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a004719; 28 May 86 14:28 EDT From: "Daniel R. Levy" Newsgroups: net.lang.c Subject: Re: expression, expression; Message-ID: <892@ttrdc.UUCP> Date: 22 May 86 05:12:11 GMT To: info-c@BRL-SMOKE.ARPA I think there may be at least one good reason NOT to do this, or at least to have expressions on different lines of the source code even if is legal--and that is for debugging. If you have code which is giving mysterious core dump problems, Murphy's law says sdb or adb will show the problem occurring on a line with multiple statements on it, and you'll just have to go back and edit the code into several lines each containing a single statement to pin down the problem. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3164 for JMS@ARIZMIS; Thu, 29-MAY-1986 16:13 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012956; 28 May 86 15:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a005157; 28 May 86 14:36 EDT From: KW Heuer Newsgroups: net.lang,net.lang.c Subject: Indentation instead of braces Message-ID: <845@bentley.UUCP> Date: 22 May 86 20:26:21 GMT Followup-To: net.lang To: info-c@BRL-SMOKE.ARPA In article <2783@utcsri.UUCP> utcsri!greg writes: >What about the following sort of thing, though ? ( this is >how I would write it in normal C ): > ... if( vogsphere == fuddle && !blasted ){ > while( sixteenvalvedualoverheadcam( bleen ) == '?') > infriddle( batman.utility_belt ); > if( total_confusion_estimated > MAX_CONFUSION ) > printf( >"Well I think you ought to know that I am getting really confused by %s\n", > reason_for_confusion[WOMBAT] > ); > return SAY_WHAT; > }else post_to_net_lang_c( silly_stuff_like_this ); No problem. Remove the braces, leave the indentation alone, and tack a backslash onto the first three lines of the printf statement. Earlier I wondered aloud about the proper interpretation of "if (c) x; y;" (without newlines). It seems to me that both x and y would be within the scope of the conditional (ditto for "\tif(c) x;\n\t\ty;\n"). Is this how it's done in existing languages with significant indentation (OCCAM)? Or is that syntax illegal, requiring a newline (my guess)? This feature is not likely to be incorporated into C in the foreseeable future, So I am directing followups to net.lang only. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4828 for JMS@ARIZMIS; Thu, 29-MAY-1986 20:15 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/29/86 at 21:43:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a008683; 29 May 86 22:34 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a004682; 29 May 86 21:29 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA00678; Thu, 29 May 86 17:31:01 edt Date: Thu, 29 May 86 17:31:01 edt From: Root Boy Jim Message-Id: <8605292131.AA00678@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Re: LINT as documentation In article <411@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >This is just one more argument for lint. > >True, lint often burps over "trivial" little problems like >passing a *int to a function that expects *char, among others, >but there are some real good reasons for using lint. A related issue is forgetting to declare malloc as returning a (char *) thus defaulting it to an (int), assuming that you will be casting the returned value anyway. Surprise! On 680[012]0's pointers are returned in `a0' while integers are returned in `d0'. Some attention must be paid to this as 68k's are reasonable machines. (Root Boy) Jim Cottrell What PROGRAM are they watching? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5049 for JMS@ARIZMIS; Thu, 29-MAY-1986 20:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/29/86 at 22:17:06 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012989; 28 May 86 15:10 EDT Received: from USENET by SMOKE.BRL.ARPA id a005181; 28 May 86 14:36 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: builtins and automatic defines Message-ID: <846@bentley.UUCP> Date: 22 May 86 22:31:13 GMT Keywords: #exclude To: info-c@BRL-SMOKE.ARPA In article <1243@utcs.uucp> utcs!flaps (Alan J Rosenthal) writes: >In article <816@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>I wonder if perhaps (and ) should be included by >>default, with an explicit "#exclude" to disable. (Cf. "#undef".) Probably >>tricky to implement -- don't do the automatic "#include" until checking for >>"#exclude", which must be at the top of the file (after whitespace)? > >Why bother? This would be very complicated and lead to many mistakes due >to an unclear definition of whitespace or whatever. It doesn't seem all that complicated to me, and probably seems simpler to the neophyte who doesn't understand why he gets "stderr undefined" when his program was working fine earlier. The mistakes could be easily caught by cpp: "#exclude must be at top of file". I meant for "whitespace" to include comments, otherwise I think it's quite clear (when restricted to the set of characters that can legally appear in a C program). >I have a file called "beginc", it's a shellscript, and it creates a file [which contains several #include's and #define's and the start of main()] >and then puts you in $EDITOR on the file. This approach is much better >than any #exclude op. It's more easily disabled or modified because you >don't have the reverse situation of deleting things by adding in lines. Perhaps. We already have the "delete by adding" situation with #undef, though the analogy isn't perfect (you can't completely cancel an #include, which is why #exclude would have to be first). On a related note, I've always despised the automatic cpp builtins (such as "#define unix 1" on UNIX(R) systems), because it effectively creates a new reserved word for each possible operating system, machine, etc. that your program might be compiled on. Older versions got around this by making the builtin definition be "#define unix unix", with a special kludge to prevent infinite recursion. I think the "who am i" testing should not use the same namespace as the macros. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5138 for JMS@ARIZMIS; Thu, 29-MAY-1986 21:08 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013044; 28 May 86 15:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a005194; 28 May 86 14:37 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: What's wrong with printf( ) , return ? Message-ID: <847@bentley.UUCP> Date: 22 May 86 22:41:33 GMT To: info-c@BRL-SMOKE.ARPA In article <123@danews.UUCP> danews!lvc writes: >I knew that return wasn't an expression. The fact that you can >do `control flow' with , seperating expressions makes me wonder >why this wasn't extended to include 'some' statements such as return. It makes about as much sense as "printf() + return". Comma in this context is an *operator*. A more serious argument would be to allow the statement "return ((void)printf())", which would make sense if "void" were a real datatype. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7068 for JMS@ARIZMIS; Fri, 30-MAY-1986 01:29 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/30/86 at 03:13:40 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013179; 28 May 86 15:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a005367; 28 May 86 14:39 EDT From: aglew%ccvaxa.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: A good use of a bad feature Message-ID: <2600050@ccvaxa> Date: 10 May 86 20:19:00 GMT Nf-ID: #R:mit-eddie.MIT.EDU:1853:ccvaxa:2600050:000:1093 Nf-From: ccvaxa.UUCP!aglew May 10 15:19:00 1986 To: info-c@BRL-SMOKE.ARPA >/* Written 10:49 am May 4, 1986 by root@icst-cmr in net.lang.c */ >You will find much disagreement on that point, I'm afraid. Fall thru is >more flexible. You can always break, but often cases are related so that >a particular case requires a superset of another case. It is to DMR's >credit that he realized this feature. I sure wouldn't have thought of it. >/* End of text from net.lang.c */ And what do you do if you have more than one case which is a superset of another? Eg. case A case B \ / \ / case C | | break Dup code or use gotos. The worst is when people use combinations of gotos and fall-through: case A: ... goto case_C; case B: ... /* fall through */ case C: case_C: ... break; There should be one way to do things. Special case constructs should only be used if they crop up frequently. I don't think fall through qualifies. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7182 for JMS@ARIZMIS; Fri, 30-MAY-1986 01:42 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013356; 28 May 86 15:18 EDT Received: from USENET by SMOKE.BRL.ARPA id a005382; 28 May 86 14:40 EDT From: aglew%ccvaxa.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <2600051@ccvaxa> Date: 15 May 86 06:06:00 GMT Nf-ID: #R:dataioDataio.UUCP:989:ccvaxa:2600051:000:592 Nf-From: ccvaxa.UUCP!aglew May 15 01:06:00 1986 To: info-c@BRL-SMOKE.ARPA I also noticed that C compilers on PCs are frequently better than UNIX issue. Little things like printing a bit of context with your errors, like: cahr stuff; Line EEE: ^ ^ Illegal declaration or obsolete initialization instead of telling you `invalid initialization on line 563'. Coming back to minicomputers is like going back to the Stone Age - big, fast, powerful monsters, but not quite as intelligent as their smaller successors. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7244 for JMS@ARIZMIS; Fri, 30-MAY-1986 01:48 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013404; 28 May 86 15:21 EDT Received: from USENET by SMOKE.BRL.ARPA id a005400; 28 May 86 14:40 EDT From: aglew%ccvaxa.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <2600052@ccvaxa> Date: 22 May 86 14:27:00 GMT Nf-ID: #R:cernvax.UUCP:314:ccvaxa:2600052:000:674 Nf-From: ccvaxa.UUCP!aglew May 22 09:27:00 1986 To: info-c@BRL-SMOKE.ARPA ~> Boolean data type in C I say `typedef unsigned char bool'... Instead of using macros like lxor, I do #define boolval(bv) ((bv)!=0) so I can get away with saying boolval(XXX) ^ boolval(YYY) and the like. Doesn't help with waning to be able to do BBBBB &&= CCCCC; "Equal rights for Booleans!" has been my cry for a while - but I meant it with respect to computer architectures, not C. After all, C can't be expected to be better than present day architectures - C is just structured assembly language. :-). On second though, :-(. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7346 for JMS@ARIZMIS; Fri, 30-MAY-1986 01:59 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a013434; 28 May 86 15:24 EDT Received: from USENET by SMOKE.BRL.ARPA id a005408; 28 May 86 14:40 EDT From: aglew%ccvaxa.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <2600053@ccvaxa> Date: 22 May 86 14:39:00 GMT Nf-ID: #R:mmintl.UUCP:1463:ccvaxa:2600053:000:1161 Nf-From: ccvaxa.UUCP!aglew May 22 09:39:00 1986 To: info-c@BRL-SMOKE.ARPA >/* Written 8:04 pm May 16, 1986 by franka@mmintl.UUCP in ccvaxa:net.lang.c */ >/* ---------- "Re: What should be added to C" ---------- */ >Something which got forgotten in my original article: I would favor an >exchange operator. This one is quite frequently useful, and the >alternatives are ugly. > >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Multimate International 52 Oakland Ave North E. Hartford, CT 06108 >/* End of text from ccvaxa:net.lang.c */ Why not go all the way and implement Dijkstra's concurrent assignment? i,j := j,i for a swap. Course, couldn't use commas, but you get the idea. Compilers can generate good code for this, and it makes programs with complicated pointer manipulations much clearer; I used to teach it, and the associated code generation algorithm, to U1s in classes I TAed, and it greatly reduced the noise level of assignments in the wrong order. #define swap(a,b) a,b := b,a does the exchange without having to type the name twice. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7423 for JMS@ARIZMIS; Fri, 30-MAY-1986 02:07 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014203; 28 May 86 15:44 EDT Received: from USENET by SMOKE.BRL.ARPA id a006817; 28 May 86 15:08 EDT From: augart Newsgroups: net.lang.c Subject: No!!! (was: Re: YANO (Yet Another New Operator)) Message-ID: <962@h-sc2.UUCP> Date: 25 May 86 05:15:17 GMT To: info-c@BRL-SMOKE.ARPA In article <304@apollo.mentor.UUCP> franka@.UUCP (Frank A. Adrian) writes: > a[x++] = a[x]->next; or a[x] = a[x++]->next; > >I have trouble remembering in what order the increment takes >place. Is it before or after the assignment (No fair peeking in K&R!)? This is merely a slightly more complicated version of the disgusting: x = 5; x = x++; In my example, different compilers will leave you with x == 5 or x == 6. In your example, "what order the increment takes place" depends upon what compiler you have. Steven Augart swa@xx.lcs.mit.edu (swa@xx.ARPA) Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8698 for JMS@ARIZMIS; Fri, 30-MAY-1986 04:47 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/30/86 at 06:24:43 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014284; 28 May 86 15:47 EDT Received: from USENET by SMOKE.BRL.ARPA id a006887; 28 May 86 15:09 EDT From: Kilsup Lee Newsgroups: net.lang,net.lang.c,net.lang.pascal,net.wanted Subject: Summary of Pascal-to-C translator Message-ID: <50@kaist.UUCP> Date: 22 May 86 09:37:14 GMT Keywords: pascal, C To: info-c@BRL-SMOKE.ARPA I received several response from very kind persons. I will summary them and I hope to be helpful to those who want them. ----------------------------------------------------------------------- Whitesmiths, Ltd 97 Lowell Road, Concord, pascal and c MA 01742 (617) 369-8499 compilers($700) Telex: 951708 SODTWARE CNCM Cross support (Additional $700) Note) Information provider -- Peter Ludemann ludemann@ubc-cs.uucp (ubc-vision!ubc-cs!ludemann) ludemann@cs.ubc.cdn (ludemann@cs.ubc.cdn@ubc.mailnet) ludemann@ubc.csnet (ludemann%ubc.csnet@CSNET-RELAY.ARPA) ----------------------------------------------------------------------- I have a friend, a student at Cornell, who worked last summer at Northwest Instrument Systems in Portland, Oregon (U.S.A.), and they used a program written by a professor at Oregon State in Corvallis, Oregon (I think, it may have been University of Oregon instead, in Eugene Oregon). Sorry I can't be of more help than this. I'm leaving school for the summer in a week so don't bother trying to reach me with mail at this address. Good luck. Stuart Williams 1234 S.W. 57th Ave. Portland, OR 97221 UUCP Sept. to May 20: ...ihnp4!wheaton!stuart ----------------------------------------------------------------------- From lewis@OREGON-STATE Sun May 18 00:06:57 1986 TGL inc at 503-745-7476 sells C source code to a Pascal-to0C translator for $7,500. It currently converts MT+, MS, UCSD, and Apollo Domain Pascal dialects to standard K&R C. ----------------------------------------------------------------------- From: Gregory Smith A pascal-to-C converter, which runs under UNIX, is made by Human Computing Resources Corporation 10 St. Mary Street Toronto, Ontario, M4Y 1P9 Canada 416-922-1937 It is HCR/PASCAL v4.1, and we are using it here now. ----------------------------------------------------------------------- Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3767 for JMS@ARIZMIS; Fri, 30-MAY-1986 13:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/30/86 at 14:50:31 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a017383; 30 May 86 15:30 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a022661; 30 May 86 15:11 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA02681; Fri, 30 May 86 15:10:22 edt Date: Fri, 30 May 86 15:10:22 edt From: Root Boy Jim Message-Id: <8605301910.AA02681@icst-cmr.ARPA> To: bentley!kwh@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Re: C vs. FORTRAN In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: >Right now Fortran has four things over C: Of which I'd like to address the first two. >o A richer set of floating point operators, including exponentiation and > the so-called "in-line" functions (many of which ARE in C). I think you mean "builtin" rather than "inline". I don't even consider that a significant difference, much less an advantage of FORTRAN. Exponentiation in general is syntactically neater in FORTRAN but semantically identical on most machines. Exponentiation with integer exponents is a problem in C; it isn't even available as a library function! When the exponent is constant (usually 2 or 3 in practice) it could easily be coded inline, but it's not clear whether that's sufficient justification for making it an operator. DMR has said that he didn't add exponentiation to the language for the simple reason that computers don't do them as a primitive. The only recourse is for the code generator to call a function. Thus, we have two ways of generating the same code. Integer exponentiation is a trivial loop: int ipower(j,k) { int m = 1; while (k--) m *= j; return m;} You also need a floating version. I always disliked exponentiation because a**b**c does b**c first. >o A way of passing different-sized multidimensional arrays to the same > subroutine. (For instance, right now it is not possible to write a > function in C that will invert a matrix of arbitrary size without use > of some "trick," like making the incoming matrix one-dimensional and > hard-coding the subscript computation or using arrays of pointers to > pointers.) Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent to the one-dimensional "trick", but it's hidden from the user. FORTRAN lets you use a variable as a bound in an array declaration, in this special case. That probably wouldn't be too hard to add to C; in fact it might be possible to generalize it to allow *any* nonstatic array declaration to have variable size (within reason). Not a variable *size*, but a variable *shape*. Users don't want to have to do this themselves. Another advantage of FORTRAN is implicit DO loops in I/O statements, and the related ability to use (constant, at least) repeat counts in FORMATs. I had a program that made this painfully clear when it was translated from FORTRAN to C. Well, you could put the printf in a do loop. Of course, we used to have contests about what certain I/O statements would do with certain format statements. Printf is crystal clear by comparison. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Root Boy) Jim Cottrell Quick, sing me the BUDAPEST NATIONAL ANTHEM!! Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1926 for JMS@ARIZMIS; Sat, 31-MAY-1986 05:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/31/86 at 07:07:05 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022789; 31 May 86 7:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a010199; 31 May 86 7:41 EDT From: Ray Butterworth Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <113@watmath.UUCP> Date: 29 May 86 13:05:43 GMT To: info-c@BRL-SMOKE.ARPA > Ah, but if you have a function prototype such as: > extern void free(void *); > and then try to free a pointer to a struct, you are implicitly casting > the struct pointer to a void *. Generating an error on this would > make void * fairly useless. But if I were king, free() wouldn't take a (void*). Almost the only place (void*) would be used is by malloc(). There is a need for two special types of generic pointers: one which is guaranteed to be aligned and can be cast into any other pointer, and one which has no such guarantee and can have any other pointer cast into it. (void*) clearly fits the former. (char*) almost fits the latter (perhaps a new (pointer) type should have been introduced). X3J11 defeated the niceness of all this by extending their definition of (void*) to fit both requirements. I really don't understand why they would do such a thing. It gains nothing and loses a lot. Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4289 for JMS@ARIZMIS; Sat, 31-MAY-1986 10:57 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/31/86 at 11:38:28 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a017983; 29 May 86 0:46 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a012745; 29 May 86 0:33 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA28277; Thu, 29 May 86 00:34:54 edt Date: Thu, 29 May 86 00:34:54 edt From: "UNIX 4.2 BSD" Message-Id: <8605290434.AA28277@icst-cmr.ARPA> To: guy@sun.ARPA, info-c@BRL-SMOKE.ARPA Subject: Warnings > I also thought that casting anything into a (void*) would be a big > no-no. Lint, and maybe even the compiler, would issue loud warnings > every time one tried to do this. The key word here is "warnings". The X3J11 standard doesn't say what constructs may not give warnings; it merely states what is and isn't legal C. As long as the compiler produces code for it, X3J11 doesn't care how many complaints it puts out. There are those of us who consider it bad practice for the compiler to utter ary a peep. Even when we indulge in other bad practices. I bet you are one. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (Root Boy) Jim Cottrell What UNIVERSE is this, please?? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4398 for JMS@ARIZMIS; Sat, 31-MAY-1986 10:58 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020723; 29 May 86 8:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a018557; 29 May 86 7:51 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <1677@umcp-cs.UUCP> Date: 24 May 86 04:11:17 GMT To: info-c@BRL-SMOKE.ARPA The real reason for `void *', which everyone seems to be missing, is that it provides a generic pointer type. Of course, if you need such a thing, you can usually get away with union all_possible_ptrs { char *ifchar; unsigned char *ifuchar; short *ifshort; unsigned short *ifushort; int *ifint; unsigned int *ifunit; long *iflong; unsigned long *ifulong; float *iffloat; double *ifdouble; }; but it is conceivable that this might be insufficent on a machine with special structure pointers. On such a machine, this union might be (say) 30 bits wide, whereas a generic pointer might be 34 bits. Thus `void *'. Besides, do you really *want* to use such a union? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5649 for JMS@ARIZMIS; Sat, 31-MAY-1986 12:45 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/31/86 at 14:29:01 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a020793; 29 May 86 8:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a018797; 29 May 86 7:58 EDT From: Davidsen Newsgroups: net.lang.c Subject: Re: LINT as documentation Message-ID: <762@steinmetz.UUCP> Date: 22 May 86 20:24:10 GMT To: info-c@BRL-SMOKE.ARPA In article <411@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >This is just one more argument for lint. > >True, lint often burps over "trivial" little problems like >passing a *int to a function that expects *char, among others, >but there are some real good reasons for using lint. > These are *NOT* trivial problems! This is the type of things which destroys portability. On a number of machines, the format of a data pointers is not at all the same, and passing a wrong type pointer may break the program completely. These machines include Honeywell (I bet you care), DG, and Cray. I was part of X3J11 for two years and had it beaten into me why we needed the "void *" pointer and forced casts. If you think these are trivial problems you perhaps lack experience with a wide enough variety of machines. Portability is the *best* reason for lint. There are better debugging tools available these days. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen / sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward" Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 5811 for JMS@ARIZMIS; Sat, 31-MAY-1986 13:02 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021545; 29 May 86 8:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a018920; 29 May 86 8:01 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <6716@utzoo.UUCP> Date: 22 May 86 16:39:27 GMT To: info-c@BRL-SMOKE.ARPA One (relatively minor) defect of grouping by indentation is that it is sometimes useful to use indenting violations to flag unusual situations. The obvious example is a classic one: temporary debugging code not indented at all, to make it easy to find and remove later. More seriously, any grouping-by-indenting scheme should be studied carefully for ways in which minor typos could seriously alter the meaning of the program in non-obvious ways. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 8012 for JMS@ARIZMIS; Sat, 31-MAY-1986 17:55 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 05/31/86 at 19:29:31 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021605; 29 May 86 8:30 EDT Received: from USENET by SMOKE.BRL.ARPA id a018934; 29 May 86 8:01 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: void * (was Re: malloc()) Message-ID: <6725@utzoo.UUCP> Date: 23 May 86 17:42:21 GMT To: info-c@BRL-SMOKE.ARPA > > Also, it's a misnomer; it has nothing to do with "void". > > I presume the reason why "void *" was chosen is, as stated above, that a > pointer of type "void *" would, when dereferenced, yield an object of type > "void", and as such dereferencing a "void *" would be illegal... I believe a contributing reason was the desire to avoid introducing new keywords. (Yes, I know, X3J11 has managed to introduce a few; it remains true that there is a preference for avoiding it.) Every new keyword is bound to break some existing programs. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 1648 for JMS@ARIZMIS; Mon, 2-JUN-1986 06:04 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 07:54:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014421; 28 May 86 15:51 EDT Received: from USENET by SMOKE.BRL.ARPA id a007282; 28 May 86 15:17 EDT From: Ray Butterworth Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <8@watmath.UUCP> Date: 22 May 86 13:43:28 GMT To: info-c@BRL-SMOKE.ARPA > Well, what *is* the justification for adding "void *" to the language? To > allow people to shove pointers around without casts? (Shudder!) To make > lint shut up about malloc()? Or just to distinguish "generic pointers" from > pointers that can be dereferenced? (Could be done with a typedef. So could > "void", but they put it in anyway.) > > I do not strongly object to the addition of "void *", but I am worried about > its "hiding" errors. (I'm one of those purists who thinks that programmers > *should* use casts to change types.) Also, it's a misnomer; it has nothing > to do with "void". When I first heard of (void*), I thought it was a wonderful idea. malloc() and realloc() would return this type and it would be guaranteed to be properly aligned and assignable to any other type of pointer without complaint. This much turned out to be true. I also thought that casting anything into a (void*) would be a big no-no. Lint, and maybe even the compiler, would issue loud warnings every time one tried to do this. This wouldn't matter since normal programs would never need to do it, and the warnings would only be generated when malloc() and realloc() were compiled. Unfortunately this turned out to be false. For some perverse reason that I have never been able to understand, X3J11 decided that any pointer could be converted to (void*) without complaint. There was no need for this additional usage since the standard also guarantees that any pointer may be correctly cast to (char*). It adds nothing useful and makes it much easier to code undetectible errors. (Lint complains too much about your code? Don't worry, just change all the pointers to void* and it will shut up. (I assume you already "#define CALL (void*)" and put CALL in front of all your function calls so that you don't have to check any error statuses.) Perhaps lint should have an option which redirects all output to /dev/null?) Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1927 for JMS@ARIZMIS; Mon, 2-JUN-1986 06:40 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 08:24:29 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id ab00570; 2 Jun 86 9:07 EDT Received: from USENET by SMOKE.BRL.ARPA id a000226; 31 May 86 5:48 EDT From: Doug Gwyn Newsgroups: net.lang.c Subject: Why (void *) Message-ID: <256@brl-sem.ARPA> Date: 1 Jun 86 02:53:45 GMT To: info-c@BRL-SMOKE.ARPA "The use of void * ("pointer to void") as a generic object pointer type has been adopted from C++, a dialect of C developed at AT&T Bell Laboratories. Adoption of this type was stimulated by the desire to specify function prototype arguments that either quietly convert arbitrary pointers (as in fread) or complain if the argument type does not exactly match (as in strcmp)." - from the Draft Rationale for Draft ANSI C Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 2144 for JMS@ARIZMIS; Mon, 2-JUN-1986 07:12 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 08:45:19 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa00834; 2 Jun 86 9:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a002069; 1 Jun 86 5:40 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: What should be added to C, call it PL/2 Message-ID: <264@brl-sem.ARPA> Date: 1 Jun 86 06:52:39 GMT To: info-c@BRL-SMOKE.ARPA You don't want to call it PL/2 anyway because it's not PL/1 it is PL/I. You should call it PL/II. -Ron Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 2037 for JMS@ARIZMIS; Mon, 2-JUN-1986 07:12 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 08:32:10 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a000834; 2 Jun 86 9:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a002065; 1 Jun 86 5:40 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: More extensions to C Message-ID: <263@brl-sem.ARPA> Date: 1 Jun 86 06:50:28 GMT To: info-c@BRL-SMOKE.ARPA In article <856@bentley.UUCP>, kwh@bentley.UUCP (KW Heuer) writes: > > >(BTW, a really good optimizing compiler can optimize out the temporary. I'm > >not fully up on what optimizers are doing these days, but I doubt that there > >are many compilers which do this. Optimizing it out is easier if it is > >declared locally ("{int temp = x; x = y; y = temp;}") instead of being > >declared at the top of the routine.) > > Unfortunately, I think the "clue" gets lost before the optimizing phase. > Eh? Unless you have a machine that has an exchange operator, the compiler is going to have to allocate a temporary anyhow. I can't see yow a compiler could generate better code for x,,y than what most compilers (even before optimization do for {register temp =x; x=y; y=temp}. -Ron INEWS SUCKS INEWS SUCKS INEWS SUCKS INEWS SUCKS Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2306 for JMS@ARIZMIS; Mon, 2-JUN-1986 07:20 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 09:01:56 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id ab00834; 2 Jun 86 9:19 EDT Received: from USENET by SMOKE.BRL.ARPA id a002073; 1 Jun 86 5:41 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: Min/max and bool Message-ID: <265@brl-sem.ARPA> Date: 1 Jun 86 06:55:40 GMT To: info-c@BRL-SMOKE.ARPA > (a) is the biggie. Why add bool when "typedef enum { FALSE, TRUE } bool;" > works fine? (Relying on ANSI C's treatment of enums as real ints). Because it wouldn't work. FALSE=0, TRUE= anything else. -Ron Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2402 for JMS@ARIZMIS; Mon, 2-JUN-1986 07:28 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 09:13:55 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id ac00834; 2 Jun 86 9:20 EDT Received: from USENET by SMOKE.BRL.ARPA id aa02077; 1 Jun 86 5:41 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: Casting a postdecrement operand Message-ID: <266@brl-sem.ARPA> Date: 1 Jun 86 07:01:03 GMT To: info-c@BRL-SMOKE.ARPA In article <1273@ulysses.UUCP>, jss@ulysses.UUCP (Jerry Schwarz) writes: > In article <114@romp.UUCP> lwh@romp.UUCP (lwh) writes: > > ((struct abc *)cbap)++; > >to increment cbap by 500. It appears that the ANSI standard doesn't say > >anything about the legality of this syntax. > > "++" requires an lvalue. A cast produces a value but not an lvalue, > so this is not legal in ANSI (or in K&R ) C. I find this disgusting but ( *((struct abc **)&cbap) )++; would work. INEWS SUCKS INEWS SUCKS INEWS SUCKS INEWS SUCKS Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 2830 for JMS@ARIZMIS; Mon, 2-JUN-1986 08:26 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021687; 29 May 86 8:32 EDT Received: from USENET by SMOKE.BRL.ARPA id a018952; 29 May 86 8:02 EDT From: Henry Spencer Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <6726@utzoo.UUCP> Date: 23 May 86 18:31:59 GMT To: info-c@BRL-SMOKE.ARPA > Yes, I know you said "sometimes re-doing", but that is often impossible, > under the press of circumstance. The press of circumstance must be firmly resisted if it's going to lead to shoddy work. I agree that there is considerable incentive to get things close enough to correct that major revision at the last minute isn't needed. > ... Beyond a certain minimum size, design/code/debug is faster than > code/debug. Ah, but is design/code/debug/release/withdraw/revise/really-release faster than code/debug/try/code/debug/release? :-) More seriously, I do acknowledge the need to have some idea of where you're going before you set out to get there. And the degree of advance planning needed is indeed a function of project size. But getting where you're going and then discovering that you really want to be somewhere else should be treated as a predictable part of the development process, not as a rare and surprising exception. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 2981 for JMS@ARIZMIS; Mon, 2-JUN-1986 08:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021773; 29 May 86 8:34 EDT Received: from USENET by SMOKE.BRL.ARPA id a019419; 29 May 86 8:13 EDT From: friesen%psivax.uucp@BRL.ARPA Newsgroups: net.lang.c,net.micro.pc Subject: Re: double (*parray[15])[]; Message-ID: <1220@psivax.UUCP> Date: 24 May 86 17:54:31 GMT To: info-c@BRL-SMOKE.ARPA In article <863@cyb-eng.UUCP> topher@cyb-eng.UUCP (Topher Eliot) writes: >There has been some debate on what the declaration > double (*parray[15])[]; >means. David Herron seems to be arguing that it declares a zero-length >array of some sort, which some people and/or compilers might interpret as >being a pointer of the same sort. [Topher Eliot's parse] > > double (*parray[15])[]; > ^^^^ >1. It's an array with 15 elements > > double (*parray[15])[]; > ^^^^^^^^^^^ >2. It's an array of 15 pointers. > > double (*parray[15])[]; > ^^^^^^^^^^^^^^^ >3. It's an array of 15 pointers to arrays (the sizes of these arrays being >pointed at is not specified). > > double (*parray[15])[]; > ^^^^^^^^^^^^^^^^^^^^^^ >4. It's an array of 15 pointers to arrays of doubles. > This is indeed correct, and the problem with this declaration stems from #3. The declaration declares an array of pointers to entities of *undefined* size(not zero size). Due to the way pointer arithmetic is defined in "C" this is not kosher(the compiler cannot determine how much to add to the pointer). At least one compiler I know of "accepts" this declaration by treating the unspecified arrays as having size 1, thus making the declaration eqiuvalent to: double *parray[15]; /* Array of pointers to double */ Since this is likely what the user really wanted anyway this works out, but it is still wrong! -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ?? Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3091 for JMS@ARIZMIS; Mon, 2-JUN-1986 08:59 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a021852; 29 May 86 8:37 EDT Received: from USENET by SMOKE.BRL.ARPA id a019691; 29 May 86 8:18 EDT From: Barry Shein Newsgroups: net.lang.c Subject: Re: questions from using lint Message-ID: <666@bu-cs.UUCP> Date: 25 May 86 18:41:16 GMT To: info-c@BRL-SMOKE.ARPA Re: To design then code, code then design, a little of each iteratively? etc. Obviously it depends on the problem, let's ignore the trivial cases. One major consideration to always take into account is "who is the customer?" When I am programming something by request/contract of someone else a whole different set of rules come into play. Before I start coding the User's Manual is written, delivered to the 'customer' and agreed to, preferably in writing. 99% of the heartache I've encountered in coding for someone else had to do with delivering the more or less finished product and having the "customer" suddenly get this surge of creativity upon playing with the program (gee, why can't you make a "few little changes" to...) At least I can point to the User's Manual that was signed off and possibly at that point offer to negotiate a new project. They don't like it, but they can usually understand it. If there are other potential complexities I would go for a Maintainer's (or System Administrator's) guide. This was important in one case where I was building a data-base system and I sincerely felt they did not understand that they needed more disk to do what they wanted. I sent over some pre-docs with "worksheets" to estimate disk needs and asked them to please have someone work through them with me a little as in conversations I saw them waving their hands and all they seemed to be thinking about was the price of the disk(s). And so on... I think the most dangerous thing that happens to a program that did not have enough aforethought is the sudden realization that the data structure(s) involved were not powerful enough to do the job, this can ripple through an entire software system and practically require ground-up re-write. I've had it happen. With the hope of not immediately starting the obvious flame-fest, people who code in FORTRAN are most liable to this failure as they are strongly motivated to make every problem work in terms of scalars and arrays. Not that they *can't* represent a binary tree, but because of the unnaturalness of that in FORTRAN they will tend to try to ignore that option until it is too late. Often if FORTRAN is their only language they aren't very sophisticated in recognizing the problem, but that's another issue. Generally, in a reasonably well-coded program the algorithms are fairly easy to replace (how hard would it be to change sort methods for example) as it involves re-writing a specific module and generally leaving the rest alone. A change in data structures, however, can almost never be localized in effect. At the very least, besides the issue at hand, input and output (and storage/retrieval) routines usually have to be re-written. The conclusion would be, therefore, design your data structures carefully and with aforethought. If you don't want to design all the algorithms beforehand keep things modular and recognize what pieces you may want to replace later. TRAP: Changing the algorithm CAN sometimes demand changing the data structure. When in doubt, sketch it out. In defense of the iterative process this is often actually used to explore possibilities to use in the design. If the code used in the "experiments" happens to get used in the final project, all the more better, but don't let the tail wag the dog. -Barry Shein, Boston University Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3299 for JMS@ARIZMIS; Mon, 2-JUN-1986 09:31 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022302; 29 May 86 8:51 EDT Received: from USENET by SMOKE.BRL.ARPA id a019699; 29 May 86 8:18 EDT From: Barry Shein Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <667@bu-cs.UUCP> Date: 25 May 86 19:07:48 GMT To: info-c@BRL-SMOKE.ARPA Re: User wants interactive, interpreted environment for C development I believe the product SAFE/C from Catalytix Corp (Cambridge, MA?) provides this. I have never used it but from what I have read and heard (a friend was one of the developers) that is the basic idea of the product. If someone has used this product I would be interested in your impressions. It is available on a variety of machines and I believe is meant to be portable but the marketing interest would probably have to be there, I dunno, ask em. I think the main problem I would expect from such a product would be the memory model. I suspect that memory management errors (eg. over-running a malloc()'d area) could be hard to detect within the interpreted environment unless carefully and specifically checked for (in which case, what if I *want* to do some sort of overlaying/equivalencing.) The point is (forgive me) that in the interpreted environment things would point around differently than in the final compiled environment. This is one reason why the lack of explicit pointers in LISP is a good thing (I know, most lisps can allow an internals person to do an (addr x), but it is highly disrecommended for several reasons in a program.) I remember speaking about this with my friend when he was developing and, although he agreed that yes indeed, that's a problem, they had some compromise (I forget, maybe something like enabling/disabling intensive checking with lintish /*SCREWMEM*/ statements, or maybe that's just what they were considering at the time, this goes back a coupla-few years.) I believe one of the main goals of the product was to provide extensive run-time checking during development/testing. -Barry Shein, Boston University Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3642 for JMS@ARIZMIS; Mon, 2-JUN-1986 09:35 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022907; 29 May 86 9:11 EDT Received: from USENET by SMOKE.BRL.ARPA id a020558; 29 May 86 8:36 EDT From: Michael Meissner Newsgroups: net.lang.c Subject: Re: Structure initialization rules question Message-ID: <366@dg_rtp.UUCP> Date: 25 May 86 18:08:39 GMT To: info-c@BRL-SMOKE.ARPA In article <696@moscom.UUCP> noemi@moscom.UUCP writes: > > Why is it that you can only initialize structures when they are global > (outside of main() )? If you initialize a structure within a function > you get an "No auto. aggregate initialization" error. I don't see > anywhere in K&R where the structure initialization rules are explained. Under K&R (probably in appendix A where the real rules are spelled out) it mentions that only aggreates (read arrays and structures) with static storage (read static and global) can be initialized. Ansi X3J11 (as of the last meeting) allows initializing auto and register aggregates, providing all members are constant. The last constraint avoids some nasty problems with regard to order of evaluation, and makes compilers unduely complex. As to why you could not initialize an auto aggregate, I think it was because the PDP-11 did not have a block copy instruction, or that DMR did not consider structures full fledged items (remember no structure arguments, structure assignment, etc.). Michael Meissner, Data General ...{ decvax, ihnp4, ... }!mcnc!rti-sel!dg_rtp!meissner Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3492 for JMS@ARIZMIS; Mon, 2-JUN-1986 09:43 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022541; 29 May 86 8:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a020032; 29 May 86 8:25 EDT From: Smith Newsgroups: net.lang.c Subject: The cost of large uninitialized static/global arrays Message-ID: <2810@utcsri.UUCP> Date: 21 May 86 20:41:50 GMT To: info-c@BRL-SMOKE.ARPA If you are programming in C and are worried about the size of your executable file and the time required to load this file off disk ie as with an editor or other frequently used utility, consider a reasonably large C program with a declaration of a global or static array which is pretty big relative to the size of the executable program. For example consider a program of around 80K with a 64K array declared but uninitialized until run time eg: something like: char *bigarray[16384]; Depending on the linker/loader/compiler we may end up with the executable program occupying 80K+64K on disk. Where 64K of the disk space is NULL. Hence everytime we execute it, it takes nearly twice as long to load off disk! And, what does it do during that time? It loads NULL's into memory! What a complete waste of time and space. Especially if you are executing the program frequently, nearly half of the load time is wasted, not to mention nearly half the space occupied by each copy of the dormant executable file. While this may be obvious to many experienced assembly language programmers, it may not be obvious to other programmers. I had learnt the lesson while programming in 8080 for my old H-8 where memory and disk space were scarce but had completely forgotten about it because of the large amount of memory now available on most machines. It only just hit me again when I happened to look at a uuencoded copy of one of my programs. The uuencoding was nearly all blanks ie compressed NULLs. Some compilers/linkers/loaders may avoid this problem by not storing large uninitialized static/global data in the executable file, but rather expanding it at load time. In the case of MS-DOS this appears not to be done. So, the lesson learned is to allocate your large uninitialized static/global space at run time and then you do not have to worry about how smart the loader is. This is probably one major factor why some C programs compile to a large executable file on one machine but to a significantly smaller file on another. Peter Ashwood-Smith University Of Toronto. Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 3789 for JMS@ARIZMIS; Mon, 2-JUN-1986 09:49 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 11:28:14 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id ad00834; 2 Jun 86 9:22 EDT Received: from USENET by SMOKE.BRL.ARPA id a002081; 1 Jun 86 5:41 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <267@brl-sem.ARPA> Date: 1 Jun 86 07:15:03 GMT To: info-c@BRL-SMOKE.ARPA In article <113@watmath.UUCP>, rbutterworth@watmath.UUCP (Ray Butterworth) writes: > There is a need for two special types of generic pointers: one which > is guaranteed to be aligned and can be cast into any other pointer, and > one which has no such guarantee and can have any other pointer cast > into it. (void*) clearly fits the former. (char*) almost fits the > latter (perhaps a new (pointer) type should have been introduced). > X3J11 defeated the niceness of all this by extending their definition > of (void*) to fit both requirements. I really don't understand why > they would do such a thing. It gains nothing and loses a lot. Eh? "void *" is a pointer that is big enough to hold any other pointer. It makes no attempt at alignment. Nowhere in C is there any guarantees on alignment. You assign an unaligned char into an int pointer on some machines it will work, some it won't be aligned right, and some will generate bizarre pointers as a result. It is a feature of MALLOC that it never puts anything into that void* it returns that isn't aligned, but that is extremely implentation dependant. -Ron Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 3696 for JMS@ARIZMIS; Mon, 2-JUN-1986 09:59 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a022977; 29 May 86 9:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a020657; 29 May 86 8:38 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <2786@utcsri.UUCP> Date: 18 May 86 16:22:37 GMT To: info-c@BRL-SMOKE.ARPA In article <131@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >In article <989@dataioDataio.UUCP> bjorn@dataio.UUCP writes: >> The state-of-the-art in compilers has progressed on PCs, >> so why hasn't anyone come up with a better compiler for >> UNIX, or have I just not heard of it? >> >Comparisons like that are *totally meaningless* - What about the quality of ^^^^^ depending on how many compiles you have to wait through. >the generated code? What "optimisations" do the compilers perform? Do both >produce much the same symbolic information for debugging? What's involved in >linking object modules in the two progams? How many passes over the source >code/expanded code/"parse trees" does each compiler do? The 4BSD compiler has >at least 5 - 6 if you count linking. First there's the preprocessor, then >the compiler proper has probably two passes, the assembler has another two >for good measure (depending on how you look at the assembler). Then there's >your configuration - how much memory does each system have? How much core >does each compiler use/need? How much paging or swapping goes on during >compilation? How much disk traffic - intermediate files etc - is done? > Give me a break. Sure, having a separate pre-processor will slow the compiler down considerably, but is it an advantage?????? It only gives you a certain amount of convenience in implementing the compiler. Consider that the cpp has to do lexical analysis as sophisticated as that done by the compiler, in order to do `#if's. It makes a *lot* of sense to have the cpp/lexer/parser in a single pass - Much code can be shared. When you find an identifier, for example, you go look it up in the #define table before saying you have found an identifier/keyword - as opposed to going through everything twice. Consider the single character i/o that will be saved - even if it is done through a pipe. The only disadvantage is that the cpp and compiler symbol tables must live together in the same process. If compiler A has more passes than compiler B, it doesn't mean 'A' is better or more sophisticated - It could just mean that the implementors of B did a better job. Your argument that the 4.2 compiler is slower because it generates better code makes sense, but I haven't the slightest idea which one is better in this area. I know of one *big* reason why the UNIX compiler would be easy to beat - it produces human-readable assembler. If it produced a binary-coded assembler, the costs of (1) writing out all that text (2) reading in all that text [twice] and (3) *lexing* and *parsing* all that &*!@#@ TEXT and looking up all those mnemonics [twice!] would be saved, and no functionality would be lost. Of course, you would want a binary-to-human assembler translator as a utitility... This makes even more sense for any compiler that may have to run off floppies - the full assembler text can be considerably larger than the C program, so you would be rather limited in what you could compile if full assembler were used. -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3959 for JMS@ARIZMIS; Mon, 2-JUN-1986 10:04 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023104; 29 May 86 9:16 EDT Received: from USENET by SMOKE.BRL.ARPA id a021595; 29 May 86 8:55 EDT From: cg%myrias.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <250@myrias.UUCP> Date: 23 May 86 20:38:51 GMT To: info-c@BRL-SMOKE.ARPA Jim @ Strathclyde missed the point about the DataLight compiler running faster on an IBM PC-AT than the standard BSD compiler does on a VAX. The result is not a comparison of machines, but a comparison of compilers. What contortions the compiler goes through is irrelevant - how long it takes and how good the resulting code is are what's important. We all know that most UN*X C compilers are hogs! I will re-iterate the question that was asked: Why aren't there any decent C compilers provided with UN*X systems? (Perhaps there are, and I just don't know about them. By decent I mean that they give meaningful error messages, never crash or abort, generate good code, and run quickly.) Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 3838 for JMS@ARIZMIS; Mon, 2-JUN-1986 10:16 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a023056; 29 May 86 9:15 EDT Received: from USENET by SMOKE.BRL.ARPA id a021460; 29 May 86 8:53 EDT From: franka%mmintl.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1497@mmintl.UUCP> Date: 23 May 86 02:03:38 GMT To: info-c@BRL-SMOKE.ARPA In article <5498@alice.uUCp> ark@alice.UUCP writes: >Frank Adams says: > >> As has been noted, one should use restraint in adding new features to a >> language. What follows is a list of the features I would support adding to >> the *next* version of C (after the current standard is complete). > >OK, let's see his examples of "restraint:" > >> o Min and max operators. These would get used all over the place. These >> should be usable to the left of the assignment operator, as most but not all >> C operators are. > >What would it mean to use these on the left of an assignment, >and why would you want to use it? It would mean what it usually means. If "\/" is the minimum operator, then "a \/= b" would mean "a = a \/ b". I find it hard to believe that anyone with any programming experience would need to ask why you would want to use it. >> o An andif clause for if statements. > >What does it do and how would you use it? You would write: if (A) { X } andif (B) { Y } else { Z } This is equivalent to: if (!(A)) goto _Z; X if (B) { Y } else { _Z: Z } >> o The ability to define multi-line pre-processor macros, using #begdef and >> #enddef statements. #if and other conditionals in the body of the >> definition would be evaluated when the macro was not interpreted, not when >> it is encountered. > >Why would you want to use it? To write more sophisticated macros. For example, one could write a copy macro which would invoke strcpy in most cases, but a word copy routine to copy an array of structures whose size is a multiple of a word. Such a macro would be machine dependant -- this is exactly the reason for making it a macro, instead of hard coding the calls. >> o A typeof operator, similar to sizeof. > >What would its value be? Why would you want to use it? "typeof(x)" would be a type, which is the type that x was declared as. This is for use primarily in macros. >> o := as a synonym for =. Compilers could have an option to permit := only. > >Why bother? Confusing "=" and "==" in if statements is a common mistake. If "=" is not a legal operator, this error becomes very rare. >> o Permit a continue statement in switch, meaning that the next label should >> be fallen through to. Compilers and/or lint could produce when a program >> falls through without a continue statement. > >A continue statement is already legal in a switch, as long as that >switch is enclosed in a for or while. It means go on to the next >iteration of the enclosing loop. Are you proposing to change this? Yes. >> o Any sort of multi-level break statement. There is no syntacticly clean >> way of adding this to C. > >C already has a multi-level break statement. It's spelled "goto." >Putting a goto in a costume doesn't disguise it. You weren't reading very carefully. This was on my list of things which should *not* be added. >> o Elimination of the eight-character truncation of internal variable names >> done by some compilers. (This may be in the current spec; I haven't read >> that document.) The entire length of a variable name should be significant. > >Most compilers do this already. So let's make it part of the standard, and those of us who like to write portable code can start using it. >The trouble with adding new features to C is that there is a very >strong incentive not to use them. After all, any program that >uses some new feature is only going to run on machines that support >that feature. I don't think I'm going to be using only one compiler >for the rest of my life and would like to avoid changing my code >every time the environment hiccups. This is the whole point of having a standard. It gives you some assurance that compilers which use the features will be available. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 4121 for JMS@ARIZMIS; Mon, 2-JUN-1986 10:19 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a028153; 29 May 86 11:43 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a026002; 29 May 86 11:27 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29441; Thu, 29 May 86 11:28:20 edt Date: Thu, 29 May 86 11:28:20 edt From: Root Boy Jim Message-Id: <8605291528.AA29441@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Re: questions from using lint The conclusion would be, therefore, design your data structures carefully and with aforethought. If you don't want to design all the algorithms beforehand keep things modular and recognize what pieces you may want to replace later. -Barry Shein, Boston University Another excellent article Barry! One thing I might add is that it has been said (I always forget by who) `show me your data structures and the program becomes trivial'. Down with flowcharts! (Root Boy) Jim Cottrell Will this never-ending series of PLEASURABLE EVENTS never cease? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 4235 for JMS@ARIZMIS; Mon, 2-JUN-1986 10:28 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a029876; 29 May 86 13:04 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a027283; 29 May 86 12:47 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29669; Thu, 29 May 86 12:48:11 edt Date: Thu, 29 May 86 12:48:11 edt From: Root Boy Jim Message-Id: <8605291648.AA29669@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA Subject: Humor Re: SAFE/C I remember speaking about this with my friend when he was developing and, although he agreed that yes indeed, that's a problem, they had some compromise (I forget, maybe something like enabling/disabling intensive checking with lintish /*SCREWMEM*/ statements, or maybe that's just what they were considering at the time, this goes back a coupla-few years.) I believe one of the main goals of the product was to provide extensive run-time checking during development/testing. -Barry Shein, Boston University Is the /*SCREWMEM*/ directive anything like the BASIC `poke' statement :-) (Root Boy) Jim Cottrell I'll eat ANYTHING that's BRIGHT BLUE!! Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 5256 for JMS@ARIZMIS; Mon, 2-JUN-1986 12:58 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 14:31:40 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id aa01009; 29 May 86 13:51 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a028521; 29 May 86 13:34 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29800; Thu, 29 May 86 13:34:33 edt Date: Thu, 29 May 86 13:34:33 edt From: Root Boy Jim Message-Id: <8605291734.AA29800@icst-cmr.ARPA> To: bentley!kwh@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Re: What's wrong with printf( ) , return ? In article <123@danews.UUCP> danews!lvc writes: >I knew that return wasn't an expression. The fact that you can >do `control flow' with , seperating expressions makes me wonder >why this wasn't extended to include 'some' statements such as return. It makes about as much sense as "printf() + return". Comma in this context is an *operator*. A more serious argument would be to allow the statement "return ((void)printf())", which would make sense if "void" were a real datatype. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint You are mesmerized by control flow. In LISP or FORTH, *every* statement/function/word returns a value *regardless* of what it does (magically) to the program counter. Consider that most if's can be transformed as follows (assuming true and false are expressions: if (c) c ? true; true : else false; false; We are halfway there. Now consider LISPish control flow in C: typedef int (*PFI)(); C_if(si,oui,non) register PFI si, oui, non; { return (*si)() ? (*oui)() : (*non)(); } C_while(cond,body) register PFI loop, body; { register int result; while((*loop)()) result = (*body)(); return(result); } We should probably add argument arguments (for arguments sake) in argv format natch! Oops, we need to have one of these for each data type! Hey, why don't I just use LISP? Well I do like the data structures and operators. My point is that control flow is not magic, that any statement can return a value. (Root Boy) Jim Cottrell Is a tattoo real, like a curb or a battleship? Or are we suffering in Safeway? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 6461 for JMS@ARIZMIS; Mon, 2-JUN-1986 15:04 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/02/86 at 16:49:24 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a001238; 29 May 86 14:03 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a029128; 29 May 86 13:48 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA29847; Thu, 29 May 86 13:48:50 edt Date: Thu, 29 May 86 13:48:50 edt From: Root Boy Jim Message-Id: <8605291748.AA29847@icst-cmr.ARPA> To: ccvaxa!aglew@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Re: A good use of a bad feature > >/* Written 10:49 am May 4, 1986 by root@icst-cmr in net.lang.c */ > >You will find much disagreement on that point, I'm afraid. Fall thru is > >more flexible. You can always break, but often cases are related so that > >a particular case requires a superset of another case. It is to DMR's > >credit that he realized this feature. I sure wouldn't have thought of it. > >/* End of text from net.lang.c */ > > And what do you do if you have more than one case which is a superset of > another? Eg. Exactly what you illustrate. > case A case B > \ / > \ / > case C > | > | > break > > Dup code or use gotos. The worst is when people use combinations of gotos > and fall-through: If used indiscriminately. C's beauty is that it is *basically* structured, with allowance for escape when necessary. > case A: > ... > goto case_C; > case B: > ... > /* fall through */ > case C: > case_C: > ... > break; > > There should be one way to do things. There is. > Special case constructs should only be used if they crop up frequently. They do. > I don't think fall through qualifies. It does. Fall thru can simulate non fall thru, but not vice versa. I have seen several programs (yours maybe?) with #define when break;case & #define otherwise break;default > Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew > 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Well, at least you made up a mickname for yourself. (Root Boy) Jim Cottrell We are now enjoying total mutual interaction in an imaginary hot tub... Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6613 for JMS@ARIZMIS; Mon, 2-JUN-1986 15:11 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a007603; 29 May 86 19:07 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a003989; 29 May 86 18:52 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA16559; Fri, 23 May 86 14:59:26 edt Date: Fri, 23 May 86 14:59:26 edt From: Root Boy Jim Message-Id: <8605231859.AA16559@icst-cmr.ARPA> To: danews!lvc@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Re: What's wrong with printf() , exit() ? > What's wrong with > printf("usage: foo bar\n"), exit(1); > as above? > Aside from style, exit is a statement syntatically but , requires expressions. The compilers I've used will accept this and do what you'd expect. Why is that ? Is this a special exeption ? Compilers may exist that won't accept it. However, this: printf("uage: foo bar\n"), return 1 ; generates a syntactic error message. If a compiler accepts , exit() why not , return ? Maybe it's too complicated to do, and not worth the trouble. Some uses of , are transparent and useful. Such as multiple initial- izations in a for loop, e.g. for(i = 0 , j = 1; ...). Doing all the relevant initializations in one place is important. Or in a while loop: while(readresp(CMD), command) where readresp is a void function (and has to be) and command is side affected several routines down. Coding this without the , obscures the code (at least to me). Why does it have to be a void function? In fact, conceptually, this makes no sense and would be logically the same as writing: while ( ,command) which to my compiler (VAX 4.2BSD) is a syntax error. Taking a closer look at the comma operator reveals that is is relatively unnecessary, seemingly created for the sole purpose of multiple clauses in the `for' statement. This reminds me of a similar technique used in APL, ,0 RHO , used to reshape (read cast) the second exp (which is eval'ed first) into a null vector, which is concatenated onto the first exp. The same syntax could have been used in C at the expense of runtime: for ((i = 1) + (j = p); i < j; ++i + j++) The comma operator merely throws the left value away, no combining done. Note to Doug Gwyn: Hey, this is really the `Omega' function (look ma, no x) i wrote about awhile back, but it's not the Boolean one. Larry Cipriani Nothing is worse than having danews!lvc an itch you can never scratch (Root Boy) Jim Cottrell "One man gathers what another man spills" Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 6909 for JMS@ARIZMIS; Mon, 2-JUN-1986 15:35 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003630; 30 May 86 8:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a010169; 30 May 86 7:40 EDT From: "Ron Natalie " Newsgroups: net.lang.c Subject: Re: malloc() Message-ID: <252@brl-sem.ARPA> Date: 29 May 86 19:12:57 GMT To: info-c@BRL-SMOKE.ARPA In article <1677@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek) writes: > The real reason for `void *', which everyone seems to be missing, > is that it provides a generic pointer type. > > Of course, if you need such a thing, you can usually get away with > > union all_possible_ptrs { Sorry Chris, but you've missed the point of void * a bit. First, UNIONS are only half citizens so you'd have to encapsulate it in a structure, so things like MALLOC can return it. Also, having written code on a rather strangely addressed machine, it won't work for the case every one makes for void * (malloc). The typical use: void * malloc(); short *x; x = (short *) malloc(sizeof (short)); On the HEP, two problems arise. The small order bits of the address actually indicate the partial word size saying: union { int *u_intp; short *u_shortp; } un; short *x; int *malloc(); un.u_intp = malloc(sizeof (short)); x = un.u_shortp; will cause unpredicatble results when x is used. We got this from experience becuase the 4.2 kernel we were porting uses the above construct all over the place, assuming that pointers are universal accross all types. -Ron Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7003 for JMS@ARIZMIS; Mon, 2-JUN-1986 15:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a003736; 30 May 86 8:23 EDT Received: from USENET by SMOKE.BRL.ARPA id a011670; 30 May 86 8:01 EDT From: Bob Bickford Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-ID: <1157@well.UUCP> Date: 27 May 86 04:47:58 GMT To: info-c@BRL-SMOKE.ARPA [WHAT line ea In a previous article, an anonymous person writes: > > > You people fail to realize that some of us out here don't like lint. > > It complains too much about what I do. I refuse to go any further > > than generating no compiler warnings. I know what I'm doing. When I > > goof, I'll fix it myself. I refuse to add extra casts to keep lint > > happy. > > Of course, an expert like yourself would not consider stooping to making modifications to lint which match your programming preferences. And, of course, since you're omnipotent (at least within your machine) then there is no point in indirectly soliciting the impartial opinion of another competent programmer: if there are any bugs, well by God you put them there on purpose! > > > > Before you start flaming my style, let me say I am quite good. > > I am also quite philosophical and attentive to coding style. > > My outlook is just different. I program for myself. If it is applicable > > to you, fine. I have my own criteria which I rarely see embraced by > > others waving standardization flags. > > And of course the desires of your employer to have a working product that will remain usable even if you suffer an untimely death are completely irrelevant to your criteria.... What the heck, if another person can't figure out a few tens of thousands of lines of code without your help, why they must not be a very good programmer! > > > > Most of the code I have written was intrinsically non-portable. I *do* > > appreciate portability as a spectrum concept, but not as a binary one. > > Define 'spectrum' and 'binary' as used in this context. Responding to the above (and more like it) Greg Paris writes: > > Sorry I enclosed so much of the original article above, but I found it > so surprisingly bizzare, I just couldn't leave any of it out. I have > two things to say about it: 1) I'm glad that Mr. XYZZY doesn't work > here; 2) I'd never recommend him being hired as a programmer, anywhere. > -- > ++------------------------------------------------------------------++ > || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || > ++------------------------------------------------------------------++ > I, for one, thoroughly agree with you. Individual programming style is one thing; complete contempt for rational coding practice is quite another. -- Robert Bickford {lll-crg,hplabs}!well!rab Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7303 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:10 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004680; 30 May 86 8:43 EDT Received: from USENET by SMOKE.BRL.ARPA id a012000; 30 May 86 8:08 EDT From: KW Heuer Newsgroups: net.lang.c Subject: C vs. FORTRAN (was: What should be added to C) Message-ID: <853@bentley.UUCP> Date: 26 May 86 18:29:38 GMT To: info-c@BRL-SMOKE.ARPA In article <1594@ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes: >Right now Fortran has four things over C: Of which I'd like to address the first two. >o A richer set of floating point operators, including exponentiation and > the so-called "in-line" functions (many of which ARE in C). I think you mean "builtin" rather than "inline". I don't even consider that a significant difference, much less an advantage of FORTRAN. Exponentiation in general is syntactically neater in FORTRAN but semantically identical on most machines. Exponentiation with integer exponents is a problem in C; it isn't even available as a library function! When the exponent is constant (usually 2 or 3 in practice) it could easily be coded inline, but it's not clear whether that's sufficient justification for making it an operator. >o A way of passing different-sized multidimensional arrays to the same > subroutine. (For instance, right now it is not possible to write a > function in C that will invert a matrix of arbitrary size without use > of some "trick," like making the incoming matrix one-dimensional and > hard-coding the subscript computation or using arrays of pointers to > pointers.) Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent to the one-dimensional "trick", but it's hidden from the user. FORTRAN lets you use a variable as a bound in an array declaration, in this special case. That probably wouldn't be too hard to add to C; in fact it might be possible to generalize it to allow *any* nonstatic array declaration to have variable size (within reason). Another advantage of FORTRAN is implicit DO loops in I/O statements, and the related ability to use (constant, at least) repeat counts in FORMATs. I had a program that made this painfully clear when it was translated from FORTRAN to C. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7401 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:18 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004764; 30 May 86 8:46 EDT Received: from USENET by SMOKE.BRL.ARPA id a012015; 30 May 86 8:08 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: expression, expression; Message-ID: <854@bentley.UUCP> Date: 26 May 86 18:47:36 GMT To: info-c@BRL-SMOKE.ARPA In article <892@ttrdc.UUCP> ttrdc!levy (Dan Levy) writes: >I think there may be at least one good reason NOT to do this ...: for >debugging. If you have code which is giving mysterious core dump problems, >Murphy's law says sdb or adb will show the problem occurring on a line with >multiple statements on it ... Well, what *I* do is look at the *instruction* where it bombed, rather than the statement. Of course, for less sophisticated users (or when using a too-smart debugger that won't disassemble) that may not be an option. This brings up an interesting question, though. Given that the language is almost completely free-format, why should a debugger be line-oriented rather than statement- or expression-oriented? (Probable answer: it's trivial to "point to" a line.) Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7177 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:21 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004531; 30 May 86 8:41 EDT Received: from USENET by SMOKE.BRL.ARPA id a011994; 30 May 86 8:08 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <852@bentley.UUCP> Date: 25 May 86 23:36:13 GMT To: info-c@BRL-SMOKE.ARPA In article <1462@mmintl.UUCP> mmintl!franka (Frank Adams) proposes: >> o Min and max operators. These would get used all over the place. These >> should be usable to the left of the assignment operator, as most but not all >> C operators are. In article <5498@alice.uUCp> alice!ark responds: >What would it mean to use these on the left of an assignment, >and why would you want to use it? I think he means that in addition to MIN and MAX there should be MIN= and MAX= operators. I think this is a good reason for making them operators rather than functions. "x MIN= y" is clearer than "if (x > y) x = y", since the latter can easily be misread as "x MAX= y", besides being subject to side effects. >> o An andif clause for if statements. > >What does it do and how would you use it? More specifically, how does it differ from "&&"? >> o The ability to define multi-line pre-processor macros, using #begdef and >> #enddef statements. #if and other conditionals in the body of the >> definition would be evaluated when the macro was not interpreted, not when >> it is encountered. The m4 preprocessor already has this functionality, and more. Of course, if using C without UNIX(R), you may not have m4... >> o A typeof operator, similar to sizeof. > >What would its value be? Why would you want to use it? Presumably "typeof(variable)" would be syntactically a dataype, so it's not really appropriate to call this an "operator". There's one obvious use, "p = (typeof(*p) *)malloc(sizeof(*p))". I guess you could also use it in "#define swap(x,y) {typeof(x) temp; temp=x; x=y; y=temp;}". I don't know that either of these is very useful, though. >> o := as a synonym for =. Compilers could have an option to permit := only. To help catch "=" vs. "==" errors? Or just to make PASCAL users happy? (And then we could make "<>" a synonym for "!=", and ...) >> o Permit a continue statement in switch [to denote fall-through]. I'll address this elsewhere. >> o Any sort of multi-level break statement. No! If you have code that seems to require a multi-level break, you should think some more about the problem you're trying to solve. If it's really necessary, use a goto. (I very seldom use even a one-level break, except as the unique exit point in a "for (;;)" loop when it's too far from either end to conveniently convert it into a "while" or "do".) >The trouble with adding new features to C is that there is a very >strong incentive not to use them. After all, any program that >uses some new feature is only going to run on machines that support >that feature. I don't think I'm going to be using only one compiler >for the rest of my life and would like to avoid changing my code >every time the environment hiccups. Does this mean you don't use enum, void, or struct assignment? The "best" solution is to add the features to the official definition of the language, but avoid using them in your code until "all" machines support those features. >>exchange operator. This one is quite frequently useful, and the >>alternatives are ugly. Taking into consideration how bad the alternatives are, it *might* be a good idea to make this a builtin operator; perhaps ":=:". Either Andy's suggestion of a concurrent assignment operator (could this possibly be made a variant of struct assignment?) or my ",," operator would be more powerful, if you don't have to worry about side effects. (How often do you need "a[i++] SWAP a[j++]" anyway?) >>I do not support the following: >> >>o ^^ for logical exclusive or. I agree with you here. If both sides are true booleans (value zero or one), either "^" or "!=" will do. If not, then the user can just use the standard "cast to boolean", namely "... != 0". There's no loss of efficiency since that's exactly how the compiler evaluates an integer in a boolean context, and it probably makes the code easier to read, too. >>o Doing anything about the array/pointer relationship. What we have now is >>a mess, but any attempt to fix it will produce a worse mess, either in the >>language or with existing code. Well, the change from "=OP" to "OP=" also broke existing code, but was done quite nicely by phasing it in slowly. I think it's possible to implement arrays cleanly and introduce the changes gradually, but it's questionable whether this should be done to C. One could instead create a new language "D" (or "P" if you prefer that sequence), which fixes several problems in C without trying to be syntactically a superset of it. A C-to-D translation program would be a big plus. >>o A separate boolean data type (sigh). This is a good thing to have in a >>language, but not a good thing to add to C as it exists. I'm not sure why not. Assuming all the implicit int/bool conversions stay, I think the only problems are (a) it isn't really necessary, and (b) it adds a new reserved word (breaking any programs that use "typedef int bool"!). >>o There should be an option to flag statements of the form if (v = e) ... >>(Actually, I wouldn't be averse to a coding standard which forbade such >>things, in favor of if (v = e, v) ...) Urgh. Are you talking about removing the assignment-has-a-value feature completely, or a special case for "if (v = e)"? (I always write this as "if ((v = e) != 0)" to make it clear that I didn't mean "if (v == e)".) Actually, the main argument in favor of valued assignment is to allow such things as "while ((c = getchar()) != EOF)". This really doesn't look so bad with the unvalued assignment "while (c = getchar(), c != EOF), so it may not be such a bad idea. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Wait until you see *my* complete list of ideas! Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 7529 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:29 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004806; 30 May 86 8:48 EDT Received: from USENET by SMOKE.BRL.ARPA id a012021; 30 May 86 8:09 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Indentation and braces Message-ID: <855@bentley.UUCP> Date: 26 May 86 18:55:10 GMT To: info-c@BRL-SMOKE.ARPA In article <146@cs.qmc.ac.uk> qmc-cs!liam (William Roberts) writes: >I use programs like "cb" and "indent" to get my C programs >indented according to what they *REALLY* mean, as opposed to >what I intended them to mean (indicated by MY indenting). This >can be quite illuminating.... I presume you then compare it to the original. Yes, that's a useful trick. However, if indentation always reflects your intention, then eliminating the braces and making indentation significant would prevent this type of bug in the first place! Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7745 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005103; 30 May 86 8:55 EDT Received: from USENET by SMOKE.BRL.ARPA id a012179; 30 May 86 8:13 EDT From: John Bruner Newsgroups: net.lang.c Subject: Re: Throwing one away Message-ID: <7076@mordor.ARPA> Date: 27 May 86 20:41:42 GMT To: info-c@BRL-SMOKE.ARPA "The management question, therefore, is not *whether* to build a pilot system and throw it away. You *will* do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down. "Hence *plan to throw one away; you will, anyhow.*" [emphasis in the original] Frederick P. Brooks, Jr. *The Mythical Man-Month* Addison-Wesley, 1975 ISBN 0-201-00650-2 -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7636 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:45 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004877; 30 May 86 8:52 EDT Received: from USENET by SMOKE.BRL.ARPA id a012025; 30 May 86 8:09 EDT From: KW Heuer Newsgroups: net.lang.c Subject: Re: More extensions to C Message-ID: <856@bentley.UUCP> Date: 26 May 86 19:34:12 GMT To: info-c@BRL-SMOKE.ARPA In article <1483@mmintl.UUCP> mmintl!franka (Frank Adams) writes: >In article <826@bentley.UUCP> kwh@bentley.UUCP writes: >>[Swap] could be considered a special case of my ",," operator: to exchange >>x and y, write "x = (y ,, (y = x))". > >I would prefer a syntax like "{x, y} = {y, x};" It's more readable. Yes, for a swap. The real power of ",," is for removing explicit temporary once-only variables in general; for example, it allows the function int pop() { int temp1; struct stack *temp2; temp1 = stk->top; temp2 = stk->next; free(stk); stk = temp2; return (temp1); } to be abbreviated to the macro #define pop() (stk->top,,(stk=(stk->next,,free(stk)))) (A sort of generalization of the postfix operators. "++x" means "x=x+1", but "x++" means "x,,(x=x+1)".) >(BTW, a really good optimizing compiler can optimize out the temporary. I'm >not fully up on what optimizers are doing these days, but I doubt that there >are many compilers which do this. Optimizing it out is easier if it is >declared locally ("{int temp = x; x = y; y = temp;}") instead of being >declared at the top of the routine.) Unfortunately, I think the "clue" gets lost before the optimizing phase. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Received: From WISCVM(SMTPUSR2) by ARIZMIS with RSCS id 7832 for JMS@ARIZMIS; Mon, 2-JUN-1986 16:52 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005136; 30 May 86 8:57 EDT Received: from USENET by SMOKE.BRL.ARPA id a012203; 30 May 86 8:14 EDT From: Stuart Cracraft Newsgroups: net.lang.c Subject: more intelligent error reporting in C compiler Message-ID: <26@pyrla.UUCP> Date: 27 May 86 15:51:00 GMT To: info-c@BRL-SMOKE.ARPA Does anyone know of any implemented C compilers wherein error reporting is done cleverly (and tersely). So often it seems that C compilers produce a maelstrom of error messages when a simple little brace or parenthesis is misplaced. Stuart Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 7948 for JMS@ARIZMIS; Mon, 2-JUN-1986 17:05 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005186; 30 May 86 8:59 EDT Received: from USENET by SMOKE.BRL.ARPA id a012363; 30 May 86 8:17 EDT From: augart Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <963@h-sc2.UUCP> Date: 27 May 86 11:09:57 GMT To: info-c@BRL-SMOKE.ARPA >>> o The ability to define multi-line pre-processor macros, using #begdef and >>> #enddef statements. #if and other conditionals in the body of the >>> definition would be evaluated when the macro was not interpreted, not when >>> it is encountered. >> >>Why would you want to use it? > >When your macro won't fit on a line, and/or you want to use #if's etc >as part of the macro, obviously. If your macro won't fit on a line, you can already handle this problem by finishing off each line except the last with a backslash. The other addition would be a win, though. Steven Augart swa@xx.lcs.mit.edu Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 8976 for JMS@ARIZMIS; Mon, 2-JUN-1986 19:13 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005484; 30 May 86 9:13 EDT Received: from USENET by SMOKE.BRL.ARPA id a012908; 30 May 86 8:32 EDT From: Guy Harris Newsgroups: net.lang.c Subject: Re: C vs. FORTRAN (was: What should be added to C) Message-ID: <3770@sun.uucp> Date: 27 May 86 21:28:43 GMT To: info-c@BRL-SMOKE.ARPA > That probably wouldn't be too hard to add to C; in fact it might be possible > to generalize it to allow *any* nonstatic array declaration to have variable > size (within reason). Where "within reason" presumably includes "not inside a structure declaration". Even just having "auto" arrays with variable size would mean that the offset of an "auto" variable from the stack/frame pointer would not necessarily be a constant. What about in a "typedef" (or would that be treated as a static declaration)? -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 9080 for JMS@ARIZMIS; Mon, 2-JUN-1986 19:25 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005526; 30 May 86 9:14 EDT Received: from USENET by SMOKE.BRL.ARPA id a013069; 30 May 86 8:35 EDT From: K A Gluck Newsgroups: net.lang.c Subject: Simple c question - pointer to array Message-ID: <118@rruxg.UUCP> Date: 27 May 86 22:19:18 GMT To: info-c@BRL-SMOKE.ARPA Ok if i have a struct which is named in a typedef as T, I know how to get an array of pointers to T: T *a[20]; what I want is a pointer to an array of T's. How do I do it, please mail I will post final answer. -kurt rruxg!kurt Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9182 for JMS@ARIZMIS; Mon, 2-JUN-1986 19:33 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005570; 30 May 86 9:17 EDT Received: from USENET by SMOKE.BRL.ARPA id a013231; 30 May 86 8:40 EDT From: Dean Elsner Newsgroups: net.lang.c Subject: Re: What should be added to C, call it PL/2 Message-ID: <36@mit-prep.ARPA> Date: 28 May 86 02:40:03 GMT To: info-c@BRL-SMOKE.ARPA Sorry, I don't think you can call it PL/2! IBM was going to call PL/1 "NPL" (New Programming Language?) until National Physical Laboratories told them not to. They then registered names PL/1 ... PL/100 (!). I don't think they reserved PL/0. I don't know what 'registered' means here, but I presume trademarked. This is from memory, and may be wrong. x@prep.ai.mit.edu (Dean Elsner) Disclaimer: I am not me. Much. Often. -- x@prep.ai.mit.edu (Dean Elsner) Disclaimer: I am not me. Much. Often. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9251 for JMS@ARIZMIS; Mon, 2-JUN-1986 19:43 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a005630; 30 May 86 9:20 EDT Received: from USENET by SMOKE.BRL.ARPA id a013521; 30 May 86 8:48 EDT From: Mike Wexler Newsgroups: net.lang.c Subject: Re: Boolean Operators Slighted in C Message-ID: <392@peregrine.UUCP> Date: 27 May 86 22:19:47 GMT Keywords: if boolean integer To: info-c@BRL-SMOKE.ARPA In article <822@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > Boolean quantities form an important abstract data type distinct from > counters, sets, real numbers, etc. By not making the distinction, > the language encourages usage errors, the most notorious being > if ( a = b ) > stuff; > >True. It is easily found tho. ------ How do I easily find these? Given the following pseudocode fragment int xyz(parameter1,parameter2) { ... if (big_expression_1=big_expression_2) statement; ... } Where the "=" should be a "==" and the function is producing unexpected results how would you easily track down this failure. By easily I mean more easily than compiling the program and noticing the error about using an arithmetic expression where a boolean one was supposed to be. If this isn't what you meant by easily, what did you mean? -- Mike Wexler Email address:(trwrb|scgvaxd)!felix!peregrine!mike Tel Co. address: (714)855-3923 ;-) Internet address: ucivax@ucbvax.BERKELY.EDU!ucivax%felix!mike@peregrine :-( Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9354 for JMS@ARIZMIS; Mon, 2-JUN-1986 19:57 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a012125; 30 May 86 13:09 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a019394; 30 May 86 12:53 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA02213; Fri, 30 May 86 12:49:02 edt Date: Fri, 30 May 86 12:49:02 edt From: Root Boy Jim Message-Id: <8605301649.AA02213@icst-cmr.ARPA> To: dataiodataio!bright@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: C Interpreters > In article <473@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: > >What I'm waiting for is an interactive interpretive debugger that runs from > >vi. The program would run interpretively until an error was encountered, > >then place you at the appropriate line in the source file with the error > >message displayed. Then you could go into insert mode, make the necessary > >change, and resume execution. Normally interpreted languages, like APL, > >often have such facilities. Are there insuperable difficulties with doing > >this with a normally compiled language like C? (I'm sure it could be done > >with FORTRAN, since FORTRAN interpreters are well-known... but why have we > >seen no C interpreters?) "The C Journal" (V1#4 Winter 1986) is crawling with them. Well at least four. > Major difficulties are: > > 1) The preprocessor. At any line, > a macro could be changed, which could change the meaning of the entire > remainder of the source text. This means that 'incremental compiles' becomes > 'compile from here to the end of the source text'. Of course, that means > the parser must have the state of the parse saved at every line..., which > obviously is impractical. What you say is true, but not insurmountable. It would seem to suffice to build a linked list of pointers to the beginning of each statement. If a macro changes any statement so that it is incomplete, a broader parse would have to be redone. > 2) C isn't line oriented. This means that any line could be any part of > a statement or expression. Thus, the parser must be able to back up from > any point to find a 'synchronization point'. But C isn't backwardly > parseable... Even if reparsing had to be done, you might still resynchronize well before the EOF, probably at the end of the function. As a related issue, try disassembling an instruction stream starting in the middle of an instruction some time. It resynch's pdq. > Why BASIC and FORTRAN can be handled this way: > > 1) They don't have a preprocessor. > > 2) They are line oriented. All the parser has to do is back up to the > beginning of the line (or in FORTRAN to the first line that isn't a > line continuation). > > 3) Each line is more or less independently parseable from the rest of > the program. > > Conclusion: > > The only fully functional, practical way is to do a reparse of the complete > source file upon any changes (even on whitespace changes). Turbo Pascal > works this way, instead of attempting to incrementally compile, Borland > spent their efforts making the compile step really fast. > > An incremental compiler could be made if numerous assumptions and > restrictions were made about what could be changed. I think the bugs > and kludges that would result would make it impractical, however. Some restrictions could be made that would avoid the problems you mention. Most people use macros as symbolic character constants and small localized `statement functions' (to borrow a term). More exotic macros are rarely used. (Root Boy) Jim Cottrell Psychoanalysis?? I thought this was a nude rap session!!! Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9439 for JMS@ARIZMIS; Mon, 2-JUN-1986 20:04 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014106; 30 May 86 13:54 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a020139; 30 May 86 13:31 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA02385; Fri, 30 May 86 13:31:10 edt Date: Fri, 30 May 86 13:31:10 edt From: Root Boy Jim Message-Id: <8605301731.AA02385@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, x@mit-prep.ARPA Subject: Trademarks Sorry, I don't think you can call it PL/2! IBM was going to call PL/1 "NPL" (New Programming Language?) until National Physical Laboratories told them not to. They then registered names PL/1 ... PL/100 (!). I don't think they reserved PL/0. I don't know what 'registered' means here, but I presume trademarked. This is from memory, and may be wrong. x@prep.ai.mit.edu (Dean Elsner) Disclaimer: I am not me. Much. Often. I believe that a trademark must be associated with a particular product. Now, why doesn't Johns Hopkins University's Applied Physics Laboratory sue IBM & Ken Iverson over the name APL :-) (Root Boy) Jim Cottrell Is it clean in other dimensions? Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9509 for JMS@ARIZMIS; Mon, 2-JUN-1986 20:15 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015349; 30 May 86 14:32 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a021279; 30 May 86 14:20 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA02565; Fri, 30 May 86 14:19:48 edt Date: Fri, 30 May 86 14:19:48 edt From: Root Boy Jim Message-Id: <8605301819.AA02565@icst-cmr.ARPA> To: info-c@BRL-SMOKE.ARPA, well!rab@ICST-CMR.ARPA Subject: Re: Re: questions from using lint > In a previous article, an anonymous person writes: > > > You people fail to realize that some of us out here don't like lint. > > > It complains too much about what I do. I refuse to go any further > > > than generating no compiler warnings. I know what I'm doing. When I > > > goof, I'll fix it myself. I refuse to add extra casts to keep lint > > > happy. > > > What? You mean after all that I am anonymous. > Of course, an expert like yourself would not consider stooping to > making modifications to lint which match your programming preferences. > And, of course, since you're omnipotent (at least within your machine) > then there is no point in indirectly soliciting the impartial opinion > of another competent programmer: if there are any bugs, well by God you > put them there on purpose! Or at least not you. > > > > > > Before you start flaming my style, let me say I am quite good. > > > I am also quite philosophical and attentive to coding style. > > > My outlook is just different. I program for myself. If it is applicable > > > to you, fine. I have my own criteria which I rarely see embraced by > > > others waving standardization flags. > > > > And of course the desires of your employer to have a working product > that will remain usable even if you suffer an untimely death are completely > irrelevant to your criteria.... What the heck, if another person can't > figure out a few tens of thousands of lines of code without your help, > why they must not be a very good programmer! Exactly. There is not all that much you can do to a language to render it unintellible. Besides, my style is actually intended to `increase' readability, not detract from it. You didn't address my points. > > > > > > Most of the code I have written was intrinsically non-portable. I *do* > > > appreciate portability as a spectrum concept, but not as a binary one. > > > > Define 'spectrum' and 'binary' as used in this context. Your most reasonable statement. In short, there are no blacks or whites, only shades of grey. There are `safe' things to do, and these are generally called `portable'. Then there are more risky things to do. They `may' be portable to `some' machines, but then they may not be either. We all know the list, byte order, sizes & formats of pointers, etc. There are also `reasonable' and `unreasonable' architectures. Intels `small model' and `large model' is outrageous. It is not necessarily the `machine' that is brain-damaged, just the high level language mapping that is. I mean, the PDP-11 has a 18 or 22 bit physical address space crammed into a 16 bit virtual address space. But did PDP-11 C ever have a small or large model? No! Remapping was done via magic system calls. It is also possible to choose a bad model on a good machine. Motorola 68k's with 16 bit ints are a goood example. > Responding to the above (and more like it) Greg Paris writes: > > > > Sorry I enclosed so much of the original article above, but I found it > > so surprisingly bizzare, I just couldn't leave any of it out. I have > > two things to say about it: 1) I'm glad that Mr. XYZZY doesn't work > > here; 2) I'd never recommend him being hired as a programmer, anywhere. > > -- > > ++------------------------------------------------------------------++ > > || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || > > ++------------------------------------------------------------------++ > > > I, for one, thoroughly agree with you. Individual programming style > is one thing; complete contempt for rational coding practice is quite > another. It is ironic that out in the real world it was I who bothered everybody else about their coding practices. Now that I am on the net, I am beseiged with a bunch of portability freaks. I don't believe in total absolute portability. And I don't care either. If I want to move it, I fix it. If you want to move it, you fix it. Sure, it's nice to snarf up a copy of whiz-bang from net.sources and have it compile and run nary an edit. And portable techniques will in the long run help you avoid bugs, but it's a tradeoff. Programs are never finished, merely abandoned. Running lint does take time, and the extra casts actually muddy up the code. I don't even have the time to do the things I want, so why should I go to extra length to do the things I don't? In addition, if a program won't port, you have to look at it. This is a good thing to do every once in awhile. > Robert Bickford {lll-crg,hplabs}!well!rab (Root Boy) Jim Cottrell My uncle Murray conquered Egypt in 53 B.C. And I can prove it too!! Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 9596 for JMS@ARIZMIS; Mon, 2-JUN-1986 20:23 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a016823; 30 May 86 15:17 EDT Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a022346; 30 May 86 14:56 EDT Received: by icst-cmr.ARPA (4.12/4.7) id AA02639; Fri, 30 May 86 14:55:11 edt Date: Fri, 30 May 86 14:55:11 edt From: Root Boy Jim Message-Id: <8605301855.AA02639@icst-cmr.ARPA> To: bentley!kwh@seismo.css.gov, info-c@BRL-SMOKE.ARPA Subject: Re: What should be added to C Cc: ~f@ICST-CMR.ARPA >> o The ability to define multi-line pre-processor macros, using #begdef and >> #enddef statements. #if and other conditionals in the body of the >> definition would be evaluated when the macro was not interpreted, not when >> it is encountered. The m4 preprocessor already has this functionality, and more. Of course, if using C without UNIX(R), you may not have m4... Howabout just porting MACRO-11 to UNIX without the assembler part? >> o := as a synonym for =. Compilers could have an option to permit := only. To help catch "=" vs. "==" errors? Or just to make PASCAL users happy? (And then we could make "<>" a synonym for "!=", and ...) And `#' as a synonym for `!=' for BASIC users :-) >The trouble with adding new features to C is that there is a very >strong incentive not to use them. After all, any program that >uses some new feature is only going to run on machines that support >that feature. I don't think I'm going to be using only one compiler >for the rest of my life and would like to avoid changing my code >every time the environment hiccups. Does this mean you don't use enum, void, or struct assignment? The "best" solution is to add the features to the official definition of the language, but avoid using them in your code until "all" machines support those features. Yes. I might use void, (and actually did `#define void ' for documentation purposes) because I can see it has a use. I might use structure assignment, but would *never* pass one as an argument or return one. Enums I shy away from, but only because of my inexperience with them. I also avoid from unions and bitfields. C has undergone four major phases. Original C was too permissive with structure members and pointer types, and lacked a few data types. Next came K&R C. We now have added enums, voids, and structure manipulation. Since not all C compilers are UNIX based, some have only implemented K&R C, or even a subset of that. Therefore they are seldom used in portable code. The fourth phase is in progress, ANSI C. Things should stabilize after this is done. >>exchange operator. This one is quite frequently useful, and the >>alternatives are ugly. my ",," operator would be more powerful, Please explain. >>o A separate boolean data type (sigh). This is a good thing to have in a >>language, but not a good thing to add to C as it exists. I'm not sure why not. Assuming all the implicit int/bool conversions stay, I think the only problems are (a) it isn't really necessary, and (b) it adds a new reserved word (breaking any programs that use "typedef int bool"!). Never! Just another type incompatibility to worry about. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Wait until you see *my* complete list of ideas! As long as you don't believe any of them it's OK :-) (Root Boy) Jim Cottrell Hold the MAYO & pass the COSMIC AWARENESS... Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 0791 for JMS@ARIZMIS; Mon, 2-JUN-1986 22:34 MST Received: from BRL-AOS.ARPA by wiscvm.wisc.edu on 06/03/86 at 00:24:15 CDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a014830; 2 Jun 86 15:56 EDT Received: from USENET by SMOKE.BRL.ARPA id a002553; 2 Jun 86 15:45 EDT From: ed gokhman Newsgroups: net.lang.c Subject: re: what should be added to C Message-ID: <1333@mtx5a.UUCP> Date: 28 May 86 20:32:51 GMT To: info-c@BRL-SMOKE.ARPA C++ makes a few interesting enhancements to its C subset. While playing with C++, I found at least two new features to be very usefull: 1. inline specifier. This is a better alternative to macros in that you may have return values for multi-statement macros. Plus, of cause, having a frequently used feature defined in language proper is nice. 2. Reference variables, e.g. int& i, used to provide call by reference and implemented as a pointer to a variable that is dereferenced every time it is used. I would rather see C++ and Concurrent C making their way into the ANSI standard, but, if it is unfeasible, at least their usefull additions to the "old C" should see the world. Ed Gokhman Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 0895 for JMS@ARIZMIS; Mon, 2-JUN-1986 22:44 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015231; 2 Jun 86 16:10 EDT Received: from USENET by SMOKE.BRL.ARPA id a002902; 2 Jun 86 15:52 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: static arguments Message-ID: <1756@umcp-cs.UUCP> Date: 31 May 86 10:01:26 GMT To: info-c@BRL-SMOKE.ARPA In article <170@njitcccc.UUCP> ron@njitcccc.UUCP (Ron DeBlock) writes: >[Someone] accidently declared the arguments to his function as >static [...]. I realize that it really makes no sense to do that, >but the compiler did not flag the "error". [...] The question is, >are static arguments legal even though they make no sense? No. >If not, why doesn't the compiler flag the problem? It is buggy. The 4.3BSD C compiler, whatever its faults, gets this one right: it complains about an `illegal class'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1007 for JMS@ARIZMIS; Mon, 2-JUN-1986 22:53 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015297; 2 Jun 86 16:12 EDT Received: from USENET by SMOKE.BRL.ARPA id a003065; 2 Jun 86 15:56 EDT From: Walter Bright Newsgroups: net.lang.c Subject: Re: What should be added to C : if (a=b) Message-ID: <1008@dataioDataio.UUCP> Date: 29 May 86 17:09:42 GMT To: info-c@BRL-SMOKE.ARPA In article <446@cad.BERKELEY.EDU> keppel@pavepaws.UUCP (David Keppel) writes: > How about an option to lint(1) (this doesn't help the people who > don't have lint) that looks for conditional clauses with assignment > but no test. Thus > if ( (a = expr) == value ) { ... > would pass cleanly thru lint, while > if ( a = expr ) { ... > would generate a message indicating a potential problem. Datalight C generates a warning for this: if ( a = expr) { ^ Warning: possible unintended assignment. In fact, it will also generate the same warning for stuff like: !(a = expr) (e1 == e2 && e3 = e4) etc. > There could be a "lint comment" /* BOOLTESTED */ or some such: > if ( a = expr ) { /* BOOLTESTED */ > that would also serve as documentation to say to another reader of > the code "Yes, I really meant '=' and not '=='". The BOOLTESTED is unnecessary. Simply write: if ((a = expr) != 0) { which will not trigger the warning. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1085 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:01 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015534; 2 Jun 86 16:25 EDT Received: from USENET by SMOKE.BRL.ARPA id a003076; 2 Jun 86 15:56 EDT From: Walter Bright Newsgroups: net.lang.c Subject: Re: Error recovery (long) Message-ID: <1009@dataioDataio.UUCP> Date: 29 May 86 17:15:51 GMT To: info-c@BRL-SMOKE.ARPA In article <312@uw-nsr.UUCP> john@uw-nsr.UUCP (John Sambrook) writes: >While on the subject of compilers, I would like to share two other features >of this compiler that I find useful. >The second feature is the ability to declare certain data structures as >"read only." This is done via a compiler switch "-R" and applies to all >data structures that are initialized to a constant value within the >compilation unit. > > int a = 1; /* "read only" */ > main() { > int b; /* "read / write" */ > > b = a; /* this is legal */ > a = 2; /* this is not */ > } The declaration for a can be made 'read only' by declaring it as follows: const int a = 1; Doing an assignment to a will then cause a syntax error when compiling. This is in the draft ANSI C spec. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1130 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:06 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015562; 2 Jun 86 16:29 EDT Received: from USENET by SMOKE.BRL.ARPA id a003679; 2 Jun 86 16:08 EDT From: ed gokhman Newsgroups: net.lang.c Subject: Re: Simple c question - pointer to array Message-ID: <1338@mtx5a.UUCP> Date: 30 May 86 19:29:00 GMT Posted: Fri May 30 15:29:00 1986 To: info-c@BRL-SMOKE.ARPA > Ok if i have a struct which is named in a typedef as T, I > know how to get an array of pointers to T: T *a[20]; > what I want is a pointer to an array of T's. Kurt, All you need is to express the declaration in English and then to convert it token by token. If precedence of the i-th token is higher then (i-1)-th the result of translation of first i-1 tokens must be parenthesized. In order of decreasing precedence "valid" English tokens and their C-conversions are (S stands for the string resulting from the previous step in English-C conversion (possibly, parenthesised)): English C -------------------------------------------------- is function returning S () array of N S [ N ] pointer to *S =================================================== For example, English C -------------------------------------------------- X is a pointer to an array of 20 Ts ... a pointer to an array of 20 Ts X an array of 20 Ts *X > precedence of [] is higher then *, so >*X should be parenthesizied. an array of 20 Ts (*X) Ts (*X)[] ... T (*X)[] =================================================== Similarly, "X is a pointer to an array of 10 pointers to functions returning pointers to arrays of 11 int" would be int (*(*(*X)[10])())[11] Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1178 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:10 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015621; 2 Jun 86 16:31 EDT Received: from USENET by SMOKE.BRL.ARPA id a003855; 2 Jun 86 16:11 EDT From: Andrew Koenig Newsgroups: net.lang.c Subject: re: what should be added to C Message-ID: <5565@alice.uUCp> Date: 31 May 86 15:38:46 GMT To: info-c@BRL-SMOKE.ARPA > I would rather see C++ and Concurrent C making their way > into the ANSI standard, but, if it is unfeasible, at least > their usefull additions to the "old C" should see the > world. No, no, NO! The purpose of a standards committee is to codify current practice, not to engage in wholesale language redesign. C++ is an evolving language. Its present form should NOT be frozen into something like ANSI C. Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1279 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:20 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015738; 2 Jun 86 16:47 EDT Received: from USENET by SMOKE.BRL.ARPA id a004241; 2 Jun 86 16:19 EDT From: D Gary Grady Newsgroups: net.lang.c Subject: Re: C vs. FORTRAN (was: What should be added to C) Message-ID: <1636@ecsvax.UUCP> Date: 31 May 86 15:44:11 GMT Posted: Sat May 31 11:44:11 1986 To: info-c@BRL-SMOKE.ARPA In article <478@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: >All my FORTRAN books call these *intrinsic* functions. This is equivalent >in meaning to "built-in." An "in-line" function sounds more like what would >be meant by FORTRAN's *statement* function . . . The term "intrinsic" is relatively new to FORTRAN; my late-60s manuals have never heard of it. "Intrinsic" and "in-line" (the older term, still in use among us aging geezers) are synonyms, meaning function names known to and handled by the compiler (or at least eligible for such treatment). For what it's worth, IBM's VS FORTRAN language reference manual uses "intrinsic" and "in-line" more-or-less interchangeably. "Built-in," on the other hand, is poorly defined and could reasonably be interpreted to mean functions that are a defined part of the FORTRAN language and hence "built in" to it. You're right, of course, that this no longer belongs in net.lang.c, and I'm sorry I started it (by trying to point out what changes to C would make it a better successor to FORTRAN as a language for science and engineering). -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1230 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:22 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015629; 2 Jun 86 16:33 EDT Received: from USENET by SMOKE.BRL.ARPA id a003889; 2 Jun 86 16:12 EDT From: Gregory Smith Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <2875@utcsri.UUCP> Date: 31 May 86 00:03:25 GMT To: info-c@BRL-SMOKE.ARPA In article <1723@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes: >In article <2786@utcsri.UUCP> greg@utcsri.UUCP (I) write: >>... having a separate pre-processor will slow the compiler down >>considerably, but is it an advantage?????? It only gives you a >>certain amount of convenience in implementing the compiler. > >Not so! There is another advantage. The preprocessor can be used >alone, or in combination with programs other than the C compiler. >This is the `software tools' philosophy: if you can make a clean >conceptual break in a task, make that break programmatically; you >then have a set of tools that may be useful in surprising ways. It may also be surprising in useless ways ;-) The problem with cpp is that it is rather C-specific - it knows the C comments, and string formats, and that 123.e+12 does *not* contain an 'e' which is a candidate for #define expansion ( at least it should :-) ). Constrast to m4 which is a much more general beasty. In general, though, I agree with this idea. > >>If compiler A has more passes than compiler B, it doesn't mean 'A' >>is better or more sophisticated - It could just mean that the >>implementors of B did a better job. > >Or that the implementors of B were aiming for speed, while those of >A were aiming for reusability. Or that A runs on smaller machines; >this is probably the real reason for those multi-pass PDP-11 compilers. >They just turned out to be a good idea (in some ways). > Yes, and yes. >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1351 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:26 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015772; 2 Jun 86 16:50 EDT Received: from USENET by SMOKE.BRL.ARPA id a004700; 2 Jun 86 16:32 EDT From: Chris Torek Newsgroups: net.lang.c Subject: Re: Casting a postdecrement operand Message-ID: <1764@umcp-cs.UUCP> Date: 1 Jun 86 09:04:02 GMT To: info-c@BRL-SMOKE.ARPA Incidentally, if you really *do* want to take a pointer `p' to type `x', but treat it as a pointer to type `y', the construct *(y **)&p works (as long as `p' is addressable). Thus ((struct abc *)cbap)++; is not legal, but (*(struct abc **)&cbap)++; is (again, if cbap is addressable). What it means is machine dependent! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu Received: From WISCVM(SMTPUSR1) by ARIZMIS with RSCS id 1422 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:31 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015862; 2 Jun 86 17:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a004718; 2 Jun 86 16:33 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1514@mmintl.UUCP> Date: 30 May 86 11:58:19 GMT Posted: Fri May 30 07:58:19 1986 To: info-c@BRL-SMOKE.ARPA In article <852@bentley.UUCP> kwh@bentley.UUCP writes: >>>o There should be an option to flag statements of the form if (v = e) ... >>>(Actually, I wouldn't be averse to a coding standard which forbade such >>>things, in favor of if (v = e, v) ...) > >Urgh. Are you talking about removing the assignment-has-a-value feature >completely, or a special case for "if (v = e)"? (I always write this as >"if ((v = e) != 0)" to make it clear that I didn't mean "if (v == e)".) > >Actually, the main argument in favor of valued assignment is to allow such >things as "while ((c = getchar()) != EOF)". This really doesn't look so >bad with the unvalued assignment "while (c = getchar(), c != EOF), so it >may not be such a bad idea. Actually, I was not proposing removing the assignment-has-a-value feature anywhere (although I would not put it into a new language I was designing). The proposal was that it be avoided in if's (and probably while's as well) as a coding standard. That is, it would be legal, but not recommended. In fact, I only use the results from an assignment in two cases. One is to assign the same value to multiple variables, and the other is in the if/while case under discussion here. (Yes, I also normally use "if ((v = e) != 0)"). I may stop using it in this latter case, in favor of the comma operator as described above. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1491 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:39 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015873; 2 Jun 86 17:06 EDT Received: from USENET by SMOKE.BRL.ARPA id a004731; 2 Jun 86 16:33 EDT From: Frank Adams Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1518@mmintl.UUCP> Date: 30 May 86 14:02:40 GMT Posted: Fri May 30 10:02:40 1986 To: info-c@BRL-SMOKE.ARPA In article <450@cad.BERKELEY.EDU> faustus@cad.UUCP writes: [Concerning andif] >I think this looks cleaner, but in any case it isn't an often-encountered >situation and the semantics aren't obvious. There is no disputing matters of taste. I find it is an often-encountered situation, and that the semantics are obvious. >You can write arbitrarily large macros by putting backslashes at the end of >lines. This is ugly but it works. This doesn't let you use "#if" in the body of the macro, as my example would require. To fully explicate, my example would be: #begdef copy(to, from, number) #if sizeof(from) % WORD_SIZE == 0 copyword(to, from, number * sizeof(from) / WORD_SIZE) #else strncpy(to, from, number * sizeof(from)) #endif #enddef > > Confusing "=" and "==" in if statements is a common mistake. If "=" is not > > a legal operator, this error becomes very rare. > >It's also an extra character to type. If you are prone to this sort of >error, just run your code through grep if | grep = | grep -v == ... Thanks but no thanks. If one added a separate step to the compilation process for each type of relatively common error, nothing would ever get done. Again, please note that I did not propose outlawing "=" as a default -- you would have to specify an option to exclude it. > > This is the whole point of having a standard. It gives you some assurance > > that compilers which use the features will be available. > >If the standard has all the things you enumerate, not many people will follow >it and it will be worse than no standard at all. This is not consistent with the experience in promulgating standards for other languages. FORTRAN 77 differs from the old standard rather more than the relatively modest set of changes I proposed; it has been widely adopted, essentially all new FORTRAN compilers adhere to the standard, and such compilers have been made available for most machines still in use on which an older compiler is available. Again, I want to emphasize that my proposals are not things to be included in the current standard (X3J11), but the next one. It is both too late to include changes of this magnitude in that standard, and inappropriate to make this kind of change in the initial standardization of the language. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1548 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:42 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015876; 2 Jun 86 17:08 EDT Received: from USENET by SMOKE.BRL.ARPA id a004848; 2 Jun 86 16:36 EDT From: aglew%ccvaxa.uucp@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Datalight faster than 4.2, why? Message-ID: <2600061@ccvaxa> Date: 30 May 86 18:58:00 GMT Nf-ID: #R:dataioDataio.UUCP:989:ccvaxa:2600061:000:1089 Nf-From: ccvaxa.UUCP!aglew May 30 13:58:00 1986 To: info-c@BRL-SMOKE.ARPA >/* Written 3:49 pm May 28, 1986 by chris@umcp-cs.UUCP */ >In article <2786@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >>... having a separate pre-processor will slow the compiler down >>considerably, but is it an advantage?????? It only gives you a >>certain amount of convenience in implementing the compiler. > >Not so! There is another advantage. The preprocessor can be used >alone, or in combination with programs other than the C compiler. >This is the `software tools' philosophy: if you can make a clean >conceptual break in a task, make that break programmatically; you >then have a set of tools that may be useful in surprising ways. Unfortunately, there is no longer a clean conceptual break between the C pre-processor and the compiler: `sizeof' can be used in pre-processor constant-expressions. I very much doubt that a cpp that parses enough of C to understand sizeof will be useful in non-C-related applications. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Received: From WISCVM(SMTPUSER) by ARIZMIS with RSCS id 1623 for JMS@ARIZMIS; Mon, 2-JUN-1986 23:50 MST Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015882; 2 Jun 86 17:09 EDT Received: from USENET by SMOKE.BRL.ARPA id a004927; 2 Jun 86 16:39 EDT From: Tainter Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1978@ihlpg.UUCP> Date: 31 May 86 18:34:00 GMT To: info-c@BRL-SMOKE.ARPA > Why not use the Ada style of putting a label before the loop body - it's > like giving a name to the loop: > complicated_loop: for(;;) { > {{{{{ > break complicated_loop; > }}}}} > } > No, it's not really much different from a goto. > Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew It is that little bit different though. And it is a definate WIN! When you see a "break