MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Re: ANSI C idea: structure literals (and short constants) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 4501 for SXJVK@ALASKA; Fri, 11 Mar 88 13:04 AST Received: by UWAVM (Mailer X1.25) id 3101; Fri, 11 Mar 88 14:03:16 PST Date: Wed, 9 Mar 88 17:05:26 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Alan J Rosenthal <flaps@dgp.toronto.EDU> Subject: Re: Re: ANSI C idea: structure literals (and short constants) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> decot@hpisod2.HP.COM (Dave Decot) wrote: >The problem of deciding what their type is solved for now (and possibly >always) by stating in the standard that such syntax has no inherent type >and must be cast or assigned to the desired type. henry@utzoo.uucp (Henry Spencer) responded: >[expletive deleted] Speaking as a user and an implementor, this is an >abortion if there ever was one. decot@hpisod2.HP.COM (Dave Decot) responded: >Thank you for the feedback. But I wonder if you would be so kind as to >elaborate on this comment ... >I'm afraid it is not clear to me that all usages of structure constants >are self-explanatory. They're not, but the point is that this is a totally new meaning for a cast. Usually, a cast is a unary operator. Here, it's part of the description, like a declaration. To be specific: "(int)f" is an expression that gets an int-ish value for the floating expression f. It doesn't change f. In your proposal, (struct a){...} and (struct b){...} imply different values for {...}. This is very inconsistent, even worse than the inconsistencies between casting pointers and casting numerical types. Also, your (struct ..) cast will produce an lvalue, which is also a big inconsistency. I think it's clear that a new syntax, such as Karl Heuer's, is required. I would prefer a symbol rather than a keyword, but that's just me. (But: how about any of backquote, dollar, at (@), or right square bracket? Perhaps unary comma? Perhaps if the `&' is immediately followed by an opening brace?) ajr -- If you had eternal life, would you be able to say all the integers?
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Are the criteria for Unix and PC compilers different? [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 4971 for SXJVK@ALASKA; Fri, 11 Mar 88 14:24 AST Received: by UWAVM (Mailer X1.25) id 3283; Fri, 11 Mar 88 15:24:19 PST Date: Wed, 9 Mar 88 19:49:39 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Ray Butterworth <rbutterworth@watmath.waterloo.EDU> Subject: Re: Are the criteria for Unix and PC compilers different? Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <22314ad9@ralf.home>, Ralf.Brown@B.GP.CS.CMU.EDU writes: > In article <1106@silver.bacs.indiana.edu>, backstro@silver.bacs.indiana.edu (Dave White) writes: > }When will they > }realize that some of us really want the option of using 32-bit ints to > }port Unix-born code? > > #define int long > Need I say more? Yes. I think "Unix-born" is a euphemism for "badly written" or "non-portable". Code that assumes that "int" is 32 bits is usually written because the programmer was lazy. By making everything "int" he can avoid having to make many declarations and having to include header files. In particular, instead of having code like: extern int func1(); extern int x; int func2(a) int a; { blah; blah; } he will probably have: extern x; func2(a) { blah; blah; } or maybe even x; func2(a) { blah; blah; } "#define int long" won't help much with this code.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 5037 for SXJVK@ALASKA; Fri, 11 Mar 88 14:38 AST Received: by UWAVM (Mailer X1.25) id 3334; Fri, 11 Mar 88 15:36:27 PST Date: Thu, 10 Mar 88 03:51:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Daniel A. Glasser" <dag@chinet.uucp> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Okay, I've now been flamed and roasted via mail, news and even on the phone for my posting about NULL and 0. If it were not for noisy and slow connections between the system I do my posting from and where I actually am, I would have written that to be the safest, you must cast NULL whenever you use it in a call. It was my recollection, and I did not have my K&R handy to check it out when I posted my message, that the C specification in K&R stated that when pointers to different objects had different representations, all pointers were passed in the "universal" pointer representation, just as char is promoted to int, float to double, so would (foo *) be promoted to the equivilent of (void *), and then moved back into a (foo *) representation when used at the other end. Having delt with compilers that did this, I assumed that the language had this orthoginality. I'm sorry, I aplogise to everyone who's life I have ruined with my posting. I made my posting not out of a lust for power, but because in my everyday work, I get about 3 calls a week passed to me from the tech. support people where I work from customers who are porting VAX unix code to the Atari ST using our compiler where ints are 16 bits, pointers 32 bits, and they often INSIST that K&R allows them to use 0 or NULL without casts in function calls expecting pointers. They get upset when I tell them that that is not the case. If it makes you feel any better, I'll retract what I said. However, the #ifndef ... #endif or the #undef should be used, and the EXPLICIT casting of any use of NULL in a parameter list should be stressed. <flame on> Please note that of over 100 programs that I have gathered from the network source groups, not one of them that I have actually looked at has cast NULL to any kind of pointer when using it in calls. Not one! Not even the GNU stuff that I've looked at. In other words, though proper usage uses casts on NULL, common usage does not. <flame off> -- Daniel A. Glasser dag@chinet.UUCP One of those things that goes "BUMP!!! (ouch!)" in the night. ...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 5172 for SXJVK@ALASKA; Fri, 11 Mar 88 15:02 AST Received: by UWAVM (Mailer X1.25) id 3419; Fri, 11 Mar 88 16:00:18 PST Date: Wed, 9 Mar 88 17:20:17 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Alan J Rosenthal <flaps@dgp.toronto.EDU> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Doug Gwyn <gwyn@brl.arpa> wrote about NULL, and said that the proper definition of it is ``#define NULL 0''. dag@chinet.UUCP (Daniel A. Glasser) wrote: >Your use of NULL === 0 promotes unportable code ... [moralizing deleted] > >On machines were sizeof int != sizeof(void *), the above definition will >not work on older style function calls (without prototypes) or in var-arg >situations. Requiring sizeof int == sizeof(void *) is not a viable >solution... > > #define NULL ((void *)0) >On older compilers, replace 'void' with 'char'. This allows the use of >a short NULL representation when the compiler is smart enough to use it >but forces passing of NULL in argument lists as a pointer sized object. This doesn't require sizeof(int) == sizeof(void *). The assumption is that you always cast NULL before passing it. Casting is still required if NULL is defined as ((void *)0); you can't assume that all pointers have the same size or representation. Passing a pointer to void to a routine that expects a pointer to struct gosh is as big a mistake as passing an int to a routine that expects a pointer to struct gosh. By the way, if you call f(0) where f expects a char *, the requirement for it to work is not simply that sizeof(int) == sizeof(char *), but also that (int)0 and (char *)0 have the same bit representation. With respect to your phrase "a pointer sized object" - there is no such thing in C. There may happen to be such a thing in a particular implementation of C due to hardware considerations. (Obviously, it is usually advantageous to represent all pointers in the same way (but not always); therefore this is a common occurrence.) ajr -- If you had eternal life, would you be able to say all the integers?
rsalz@bbn.com (Rich Salz) (03/12/88)
In regard to all those BITNET lossage messages, i.e.: Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 5037 for SXJVK@ALASKA; Fri, 11 Mar 88 14:38 AST Received: by UWAVM (Mailer X1.25) id 3334; Fri, 11 Mar 88 15:36:27 PST Date: Thu, 10 Mar 88 03:51:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Daniel A. Glasser" <dag@chinet.uucp> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> .... I sent a note to info-c-request@brl.arpa, info-c@ndsuvm1.bitnet, and sxjvk@alaska.bitnet. Feel free to roast the BITNET sites, but don't flame at info-c-request too much. I am curious, tho, if the user does not exit or has never logged on, how the !@#$ they managed to subscribe to the info-c list? -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: SUN Env. Vars. [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 5915 for SXJVK@ALASKA; Fri, 11 Mar 88 17:46 AST Received: by UWAVM (Mailer X1.25) id 3816; Fri, 11 Mar 88 18:43:38 PST Date: Thu, 10 Mar 88 17:08:55 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Stuart A. Werbner" <stu@linus.uucp> Subject: SUN Env. Vars. Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Hello fellow SUN/UNIX enthusiasts. Could someone please mail me a list of all environment variables recognized by the Sun 3.x Operating System (and resident commands and utilities). If not, could someone please tell me how to (easily) find such a list. Thank you.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Why I won't use ANSI C [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 5993 for SXJVK@ALASKA; Fri, 11 Mar 88 17:53 AST Received: by UWAVM (Mailer X1.25) id 3930; Fri, 11 Mar 88 18:50:46 PST Date: Wed, 9 Mar 88 18:31:07 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Ray Dunn <ray@micomvax.uucp> Subject: Re: Why I won't use ANSI C Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <671@cresswell.quintus.UUCP> Richard A. O'Keefe writes: >At the last count, I have made 8 attempts to send e-mail to Doug Gwyn. >Here's what I've tried to send: > Thank you very much for your postings in comp.lang.c. > I very much appreciate the work you put into them. > Richard included this in response to a flame I wrote criticising Doug on a number of points. To a certain extent I agree with the sentiments expressed above by Richard even though (if anyone cares) I sometimes vent my frustration at some of Doug's idiosyncratic responses. If you hold yourself up as an authority, as Doug does, you must be very careful to maintain your credibility. Unfortunately, Doug often appears to not know when to keep his mouth firmly shut and leave things well alone. He appears to always need to justify everything he says or is trivially criticised for, even if this means getting into arguments which at best, border on the specious or untenable. Now, fair enough, this is Doug, and he can only act as his personality dictates, but it *is* sometimes annoying, and it leaves him open to this sort of complaint (which he should probably learn to "verbally" ignore). More important however, in my mind it denegrates the "quality" of his postings and his credibility as an authority. *Perhaps* he does not fully realize the *responsibility* of the position he has voluntarily undertaken. What does it matter if *I* spout off, who am I, but Doug has positioned himself such that his readers should be able to rely on the veracity of his remarks. He should thus be careful what he says and how he says it. Earlier gurus of 4 or 5 years ago, who, apart from the fact that they did not seem to have any axe to grind as Doug often appears to have, would rarely resort to sarcasm and downright dismissal of others views! [Mind you, Chris Torek seems to be getting a littly crotchetty in his old age these days! (:-)]. I could go on, I'll spare you though (whew!) except to say that I *do* believe that we should remember that Doug's position on the ANSI committee gives him a certain power, but *not* necessarily a superior opinion on the contentious issues we all discuss (argue? shout about? go to sleep over?...). If anyone wants to follow up this posting, please choose an appropriate news group. Don't ask me, I don't know what's appropriate, but we'd better leave this group for crying about the message rather than shooting the messengers (:-). Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Portable asm [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6325 for SXJVK@ALASKA; Fri, 11 Mar 88 19:35 AST Received: by UWAVM (Mailer X1.25) id 4131; Fri, 11 Mar 88 20:34:45 PST Date: Wed, 9 Mar 88 17:42:12 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: David Collier-Brown <daveb@geac.uucp> Subject: Re: Portable asm Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <7501@sol.ARPA> quiroz@cs.rochester.edu (Cesar Quiroz) writes: | Herman Rubin has consistently criticized in this group high-level | language designers/implementors for not producing the portable | assembler he wishes to use [several paragraphs deleted] | My personal guess is that, were he to try, Rubin would come out with | a language in the general class of C/Bliss/BCPL. The exercise would | be fruitful still: no more negative comments, once he realizes that | language designers are not (totally) crazy, and that "progress in | programming", if anything, means getting *away* from the vagaries of | the hardware. Published last year (or maybe the one before) in Dr. Dobb's: a subset-language of C which was in fact an assembler for a 68k machine. And the idea is to get away from the vagaries without losing the capabilities. The latter is surprisingly hard, the turing machine notwithstanding. --dave (doesn't anyone read any more?) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: The D Programming Language [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6343 for SXJVK@ALASKA; Fri, 11 Mar 88 19:42 AST Received: by UWAVM (Mailer X1.25) id 4152; Fri, 11 Mar 88 20:37:31 PST Date: Wed, 9 Mar 88 14:50:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: BEATTIE <twb@hoqax.uucp> Subject: Re: The D Programming Language Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> I have been trying to ignore this D discussion but it seems to be going on forever. Why is this D discussion in the C group?
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Why NULL is 0 [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6390 for SXJVK@ALASKA; Fri, 11 Mar 88 19:43 AST Received: by UWAVM (Mailer X1.25) id 4221; Fri, 11 Mar 88 20:40:44 PST Date: Fri, 11 Mar 88 23:34:09 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was ris@umd5.umd.EDU From: "Louis A. Mamakos" <louie@trantor.umd.EDU> Subject: Re: Why NULL is 0 Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes: >However, if I were writing a C compiler, I would choose a size for all >pointers equal to the size of the largest possible pointer. Please don't do this. On, for example, our Unisys 1100 machine, a "regular" pointer is 8 bytes long (2 words, 72 bits). A pointer to a function is 64 bytes long (8 words, 288 bits). Yes, this is a word-addressable machine with 4 9-bit bytes per word. The existing semantics work just fine if you don't assume programmer brain-damage. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: How not to write a loop [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6452 for SXJVK@ALASKA; Fri, 11 Mar 88 19:44 AST Received: by UWAVM (Mailer X1.25) id 4316; Fri, 11 Mar 88 20:43:52 PST Date: Thu, 10 Mar 88 13:36:07 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Gerald Edgar <gae@osupyr.uucp> Subject: Re: How not to write a loop Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Lengthy discussion about loops such as: >>> float x; >>> for (x = 0; x < 20; x += .5) printf("%f\n", x); How about this: float x; for (x = 0; x < 19.75; x += .5) printf("%f\n", x); -- Gerald A. Edgar TS1871@OHSTVMA.bitnet Department of Mathematics gae@osupyr.UUCP The Ohio State University ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae Columbus, OH 43210 70715,1324 CompuServe
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Why NULL is 0 [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6461 for SXJVK@ALASKA; Fri, 11 Mar 88 19:45 AST Received: by UWAVM (Mailer X1.25) id 4332; Fri, 11 Mar 88 20:43:57 PST Date: Fri, 11 Mar 88 23:28:50 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: David Keppel <pardo@june.cs.washington.EDU> Subject: Re: Why NULL is 0 Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes: >However, if I were writing a C compiler, I would choose a size for all >pointers equal to the size of the largest possible pointer. This would >allow code that passed uncasted NULL to work correctly, provided NULL >is a type as large as a pointer. This is not because dpANS says it >should be so, but because so much code would break if it were not. >Perhaps ANSI should add the restriction that all pointer types must be >the same size in an effort to "codify common existing practice." My guess is that you would want to do this only if you didn't care whether your compiler produced efficient code or made "reasonable" time/space efficiency tradeoffs. I know we've gone over this a lot, and perhaps the topic should be redirected to comp.arch or some such, but (if nobody minds too much) could somebody who understands please tell me what kind of efficiency you lose (in runtime, codespace, and dataspace) in trying to make everything the most general pointer type (on existing architectures)? I'd sure like to know. ;-D on (Well it looked like luminous phosphor when I wrote it) Pardo
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Another \"D\" idea: RPN (and more) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6470 for SXJVK@ALASKA; Fri, 11 Mar 88 19:45 AST Received: by UWAVM (Mailer X1.25) id 4349; Fri, 11 Mar 88 20:44:04 PST Date: Tue, 8 Mar 88 16:51:00 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: justin@inmet.uucp Subject: Re: Another \"D\" idea: RPN (and more) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> /* Written 4:29 pm Mar 3, 1988 by gwyn@brl-smoke.UUCP in inmet:comp.lang.c */ In article <12088@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: >I think that the one thing that really detracts from C is the fact that it >isn't RPN. Reverse-polish-notation has a lot of benefits. First of all, >we'd get the support of all the HP calculator lovers, all the FORTH users, >and compiler writers would find it easier to write compilers since RPN is >easier to parse. This idea isn't totally off-the-wall, but it would move the D language away from being a revised C and toward something markedly different. /* End of text from inmet:comp.lang.c */ God, it's finally happened. I had heard about this trend, but I couldn't believe it. But it's really true. Nobody on the net (except in talk.bizarre) is capable of recognizing sarcasm without a row of smileys at the end! Come on, people, *think* about what you're reading. If we really have lost the ability to tell what tone the article was written in, it means that English on the net has degenerated a lot more than I thought. -- Justin du Coeur
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6354 for SXJVK@ALASKA; Fri, 11 Mar 88 19:46 AST Received: by UWAVM (Mailer X1.25) id 4167; Fri, 11 Mar 88 20:37:39 PST Date: Wed, 9 Mar 88 17:20:17 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Alan J Rosenthal <flaps@dgp.toronto.EDU> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Doug Gwyn <gwyn@brl.arpa> wrote about NULL, and said that the proper definition of it is ``#define NULL 0''. dag@chinet.UUCP (Daniel A. Glasser) wrote: >Your use of NULL === 0 promotes unportable code ... [moralizing deleted] > >On machines were sizeof int != sizeof(void *), the above definition will >not work on older style function calls (without prototypes) or in var-arg >situations. Requiring sizeof int == sizeof(void *) is not a viable >solution... > > #define NULL ((void *)0) >On older compilers, replace 'void' with 'char'. This allows the use of >a short NULL representation when the compiler is smart enough to use it >but forces passing of NULL in argument lists as a pointer sized object. This doesn't require sizeof(int) == sizeof(void *). The assumption is that you always cast NULL before passing it. Casting is still required if NULL is defined as ((void *)0); you can't assume that all pointers have the same size or representation. Passing a pointer to void to a routine that expects a pointer to struct gosh is as big a mistake as passing an int to a routine that expects a pointer to struct gosh. By the way, if you call f(0) where f expects a char *, the requirement for it to work is not simply that sizeof(int) == sizeof(char *), but also that (int)0 and (char *)0 have the same bit representation. With respect to your phrase "a pointer sized object" - there is no such thing in C. There may happen to be such a thing in a particular implementation of C due to hardware considerations. (Obviously, it is usually advantageous to represent all pointers in the same way (but not always); therefore this is a common occurrence.) ajr -- If you had eternal life, would you be able to say all the integers?
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6493 for SXJVK@ALASKA; Fri, 11 Mar 88 19:48 AST Received: by UWAVM (Mailer X1.25) id 4373; Fri, 11 Mar 88 20:47:33 PST Date: Wed, 9 Mar 88 23:59:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Pablo Halpern <pablo@polygen.uucp> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> From article <3351@chinet.UUCP>, by dag@chinet.UUCP (Daniel A. Glasser): > A better way to do it, in each place you want to define NULL, > is: > > #ifndef NULL > #define NULL ((void *)0) > #endif > > On older compilers, replace 'void' with 'char'. This allows the use of > a short NULL representation when the compiler is smart enough to use it > but forces passing of NULL in argument lists as a pointer sized object. Do NOT replace 'void' with 'char' for old compilers unless you are prepared to cast every use of NULL to the pointer type you are assigning (or comparing, etc.). Most compilers will complain of a pointer type missmatch since (char *) doesn't match (int *) or (struct foo *) etc.. I agree that for ANSI compilers, the above is correct, since (void *) DOES match (int *) by definition. For compilers that don't support (void *), you must have a compiler-specific definition of NULL: #define NULL 0 /* If sizeof(int) == sizeof(char *) */ or #define NULL 0L /* if sizeof(long) == sizeof(char *) */ This avoids pointer type missmatches because all compilers let you compare any pointer agains integer zero. Since the above #defines are necessarily machine (and compiler) specific, I put these types of declarations in a file called "machine.h" which contains machine and compiler-dependent declarations and is different for each compiler I use. "machine.h" is #include'd in all of my source files. Pablo Halpern mit-eddie \ Polygen Corp. princeton \ polygen!pablo 200 Fifth Ave. bu-cs / Waltham, MA 02254 stellar /
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: nasty evil pointers [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6417 for SXJVK@ALASKA; Fri, 11 Mar 88 19:47 AST Received: by UWAVM (Mailer X1.25) id 4265; Fri, 11 Mar 88 20:41:06 PST Date: Thu, 10 Mar 88 00:46:25 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Dave White <backstro@silver.bacs.indiana.EDU> Subject: Re: nasty evil pointers Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <13100003@bucc2> brian@bucc2.UUCP writes: > >It would be nice if we could check every pointer as >it was used... > > >If pointer >pointed, say, into the operating system or the text space, the function >would print a message and exit(). Otherwise it would return. > >Without source to the compiler it could >be a major project. Does anybody know a way this could be done, perhaps with >something like lex? > Lattice C 3.0 (and, I suppose, more recent versions) allow the size of the stack and the size of the heap to be specified at runtime -- one uses an argument of the form =ssize/heapsize which the runtime startup routine digests before calling main(). Given such a beast, Lattice can provide isxxxx() functions that determine whether a passed pointer points within an expected space. However, the programmer must call them explicitly. This makes it possible to determine when a wild pointer endangers the machine. It has the disadvantage that the proper heapsize might need to be fudged, as well as the stacksize.... developing code for 8086's anf friends is painful enough... The sanest way to do what you want automatically is to build it into the compiler itself. Because compilers frequently call internal functions not made available to the user, and because of the difficulty of cases like the one you mention, it just isn't practical to write a pre-processor for this -- you'd be halfway to rewriting the compiler! >--- > When the going gets weird, the weird turn pro. No, they just bring out an Optimizing Turbo 5.0 version :-) -- backstro@silver.bacs.indiana.edu
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: sizeof(char) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6374 for SXJVK@ALASKA; Fri, 11 Mar 88 19:49 AST Received: by UWAVM (Mailer X1.25) id 4203; Fri, 11 Mar 88 20:38:02 PST Date: Wed, 9 Mar 88 17:52:54 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Ray Butterworth <rbutterworth@watmath.waterloo.EDU> Subject: Re: sizeof(char) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <2809@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > >In article <1988Feb25.202237.8688@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >>Most machines cannot handle bits with anywhere near the efficiency > >>with which they handle bytes; the appropriate base unit for efficient code > >>*is* the byte. > > "Word-addressible cannot handle bytes with anywhere near the efficiency > with which they handle words; the appropriate base unit for efficient code > is the word." Right? > > On a word-addressible machine, there is a perceived need to address objects > smaller than one word; hence most C compilers give you access to individual > bytes via "char". (There may be some that define char as a machine word, but > I'm not familiar with any.) Similarly, on byte-addressible machines there is > a (less) perceived need to address objects smaller than one byte. The Honeywell Bull GCOS-8 C compiler packs chars into individual bytes for arrays and structure, but individual external, static, or auto char variables occupy a full word. Accessing words (36 bits) on this machine is easy. Accesing individual bytes is not (typically a 3 word instruction is needed to access individual bytes). Certainly as far as this machine is concerned, there is no reason to say that sizeof(char) should be 1, any more than it should be 9. If C left the units of sizeof up to the implementor it would solve a lot of problems (e.g. none of the multi-byte character mess that is now in the proposed standard, and the problems of having to have functions that know about the two different types of strings). Other than allowing sloppily written code to continue to be written, I can see no reason whatsoever for requiring that sizeof(char) be 1. In Japan it could be 2, while on machines that do a lot of bit manipulation it could be 16. Both are appropriate for their needs. Compiler writers that want to continue to support their old code that assumed sizeof(char)==1 are free to write their compilers with that same assumption. But requiring sizeof(char)==1 on all compilers imposes a needless limit on the language and forces implementors to use various messy kluges and indefficiencies.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: How not to write a loop [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6425 for SXJVK@ALASKA; Fri, 11 Mar 88 19:49 AST Received: by UWAVM (Mailer X1.25) id 4281; Fri, 11 Mar 88 20:41:13 PST Date: Wed, 9 Mar 88 03:11:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Hume Smith <850347s@aucs.uucp> Subject: Re: How not to write a loop Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> ok@quintus.UUCP (Richard A. O'Keefe) wrote in <712@cresswell.quintus.UUCP>: >In article <832@unmvax.unm.edu>, mike@turing.UNM.EDU (Michael I. Bushnell) writes: >> I see NOTHING which precludes: >> float x; >> for (x = 0; x < 20; x += .5) printf("%f\n", x); >> The output would, of course, be >> 0.0 >> 0.5 >> ... >> 19.5 > >You should not be surprised to see as the last value > 19.99999 >I just tried the very similar loop > for (x = 0; x < 21; x += .3) /* .3 divides 21 exactly */ >By analogy with your "of course", the last output should obviously >be 20.7. In fact, when I tried it just now, the last output was > 20.999994 I would be quite surprised to see 19.99999 come out in the former loop. .5 is exactly representable in floating binary, and should cause no problem as an increment. .3 is not representable in a finite binary fraction (.01001 something, it repeats eventually), and cannot be summed up to get an integral value. If the machine did its arithmetic in decimal (Texas Intstruments? Sharp?) then the .3 increment would again not be a problem, since the representation is exact again. This, however, is the point. The behaviour of a particular increment is unreliable. (Not to be insulting at all, but this may be why our Computer Science department makes its majors take our Numerical Methods Course. The very first thing we do is Machine Epsilon and roundoff error. This comment is just to make enough text to keep inews happy.) -- Hume Smith UUCP: Math Department {uunet|watmath|utai|garfield|mnetor}! Acadia U dalcs!aucs!850347s
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Portable "asm" <-- portable? since when? [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6433 for SXJVK@ALASKA; Fri, 11 Mar 88 19:50 AST Received: by UWAVM (Mailer X1.25) id 4297; Fri, 11 Mar 88 20:41:20 PST Date: Wed, 9 Mar 88 23:22:46 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: MH Cox <cox@bentley.uucp> Subject: Re: Portable "asm" <-- portable? since when? Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1355@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: >In article <697@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >|In article <7401@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >|> In article <2738@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >|> >Clearly, assembler statements should have been defined as: >|> >#asm <statement> >|> >instead of >|> >asm("statement"); >|> >|> A properly-designed system programming language should not have such >|> a feature at all. (It is not guaranteed in C, either.) > >What's all this about #asm < > ? > >First, #asm is really a way to change programming languages in >mid-stream. Second, kindly explain how #asm sections are portable? >Third, why not use separate assembly modules instead? If you _really_ need >the flexibility of assembly to do low-level programming, use an >assembler. I can see no need to mix assembly and C at the C source >level (why was the language designed in the first place?). If the #asm has to come back, let's just revert to the old K&R style: #asm ; assembly goes here #endasm I agree with Dave whole-heartedly that we don't need yet another #asm (or to re-adopt the old style). It's against the "spirit" of the maxim, "Isolate your machine-dependent code." Now to change the subject and completely contradict myself... I *would* like to see the "interrupt" keyword added to ANSI C (or D). For a language to claim to be a system programming language and not provide the capability to write interrupt routines is a major oversight (although K&R seemed to do fine without it :-). Both Borland and Microsoft have added this capability, e.g.: interrupt int21() { } The function int21's address can now be placed in an interrupt vector to do interrupt processing. Although this is non-portable, it sure does make writing interrupt routines much easier. Also, I would like to see named access to specific CPU registers included in ANSI C, e.g. AX, BX, R0, R1, etc. Borland does a nice job of this by using _AX, _BX, etc as predefined variables for accessing CPU registers (from what I've heard about the ANSI standard (I don't have the latest copy), symbols beginning with underscore and in all capital letters are reserved for use by the compiler. So even with this CPU register "extension", Borland's compiler is still a "conforming" compiler! Maybe other compiler vendor's will follow suit (are you listenin' Microsoft ;-) and make CPU register access a common feature. I think with the combination of the "interrupt" keyword and CPU register access, that would eliminate 90% of the reasons for reverting to assembly langauge. >Do *not* mix languages in a single source file. Dr. Codd would disagree (see March 88 issue of _Computer Language_). What about SQL? I find C combined with embedded SQL and good forms and menu libraries to be one of the best application development environments going! -- ========================================================================== Michael H. Cox ARPA: moss!bentley!cox@rutgers.edu AT&T Bell Labs UUCP: don't know (can anyone help?) 184 Liberty Corner Road Rm 3B-Q15 Warren, NJ 07060 (201) 580-8622 ==========================================================================
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: == vs = [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6366 for SXJVK@ALASKA; Fri, 11 Mar 88 19:52 AST Received: by UWAVM (Mailer X1.25) id 4186; Fri, 11 Mar 88 20:37:54 PST Date: Thu, 10 Mar 88 09:24:19 est Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Dave Sill <dsill@NSWC-OAS.arpa> Subject: Re: == vs = Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <931@micomvax.UUCP> Ray Dunn <micomvax!ray> writes: >I assume everyone still remembers this discussion, my systems news >processing is so behind that......anyway.... I'm sure they wish they could forget it by now. >In <11915@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) suggests that the >answer is "using competant [sic] C programmers". > >This attitude, as well as being incompetently arrogant, just fails to >recognize the realities of life. Yeah, right, and it's realistic to expect something as fundamental as the assignment operator to be changed at this point. That remark *was* flippant, for which I apologize. >What he is [indirectly] saying, for example, is: > >...that lint is unnecessary, we should rely on the competence of the >programmer and not use lint. Not at all true. I'm a firm believer in `lint'. If you want to make your `lint' complain about "=" in conditional contexts, that's fine with me. I don't think you should expect the language to be changed just because you and a few others want it to. >>...that we should rely on his own (in)ability to spell rather than attempt >to define a spelling methodology that would avoid him making errors [I don't >believe in spelling wars, but this was too relevant to avoid]. Yes, a perfect example! I misspelled "competent", a common enough mistake, but you don't hear me saying we should change the spelling of "competent" to "competant", do you? It's just more trouble than it's worth, even if many people make the same mistake. [As an aside, I *do* have a spelling methodology. I run `ispell' on all my postings. I fixed the misspelled "competent", but overwrote the fixed version when I went back into emacs to make other changes.] >...that the recent language extensions which, for example, allow parameter >type specifications, are unneccessary [sic] because we should rely on the >programmer to always give the correct argument types to function calls! I've said it before: I think function prototypes are A Good Thing. I just don't think they should have been added to C. C + x != C, where x = {function prototypes, honored parentheses, et cetera}. >Dave, don't you believe in removing from system designs, as much of the >human ability to make mistakes as possible? Absolutely. But I also realize that some things are just too hard to change. The way to fix them is to design a new system without them (hint: what comes after C?). >> Like it or lump it. It will never change. > >Dave, the beauty of making statements like this and acting on them, is that >you will always be right! It is wonderfully self fulfilling. You'll never >achieve anything of course, but you'll always be right! I'm not being stubborn or arrogant, I'm being pragmatic. >Remember me the next time you discover a "stupid" error in the code you are >writing, or when a typo costs you a couple of days work, or a poorly >designed user interface costs you a bonus! All of these could be avoided if >you were competent in handling them! How many times can *you* use "competent" in one message? >Followups should perhaps be sent to alt.flame, you will notice the complete >absence of smiley faces (or is that spelt faeces)? I think that's "feces". :-) I also think we should drop this discussion from comp.lang.c, but use e-mail if we really must continue it. ========= The opinions expressed above are mine. "I have enough trouble socializing with people. I don't need some object saying `good morning' to me." -- Ted Nelson
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: nasty evil pointers [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6552 for SXJVK@ALASKA; Fri, 11 Mar 88 19:58 AST Received: by UWAVM (Mailer X1.25) id 4393; Fri, 11 Mar 88 20:57:32 PST Date: Thu, 10 Mar 88 04:06:23 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Patrick Bennett <null@bsu-cs.uucp> Subject: Re: nasty evil pointers Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1159@silver.bacs.indiana.edu>, backstro@silver.bacs.indiana.edu (Dave White) writes: > In article <13100003@bucc2> brian@bucc2.UUCP writes: > > > >It would be nice if we could check every pointer as > >it was used... > > > > > >If pointer > >pointed, say, into the operating system or the text space, the function > >would print a message and exit(). Otherwise it would return. > > OS/2 provides this... Different memory areas can have varying levels of protection. When this protection is broken, whether by attempting to modify, read, whatever (depends on the protection) the program is promptly aborted but with appropriate error info... Although I personally don't have or use OS/2 I obtained this information from the OS/2 Programmer's Guide by Ed Iacobucci (The leader of the IBM OS/2 Design Team) Sounds great to me... -- ---- Patrick Bennett UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!null
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Portable "asm" (Was: The D Programming Language) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6572 for SXJVK@ALASKA; Fri, 11 Mar 88 20:08 AST Received: by UWAVM (Mailer X1.25) id 4412; Fri, 11 Mar 88 21:08:08 PST Date: Mon, 7 Mar 88 22:42:20 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Tim Boemker <boemker@hpfcdc.HP.COM> Subject: Re: Portable "asm" (Was: The D Programming Language) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Since the interface between C and in-line asm seems to be so problematic (not to mention non-portable), why not write those routines that should be written in assembly in assembly? (Please don't tell me about needing just a rotate here or there for performance; reconsider the original partitioning of the task and find an alternative that separates the high-level part and the low-level part.) (Yes, I have written separately compiled assembly routines, and I have repartitioned tasks to find an aesthetically appealing, efficient alternative.) Tim Boemker
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: I forget what it was originally called. [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6593 for SXJVK@ALASKA; Fri, 11 Mar 88 20:28 AST Received: by UWAVM (Mailer X1.25) id 4428; Fri, 11 Mar 88 21:15:23 PST Date: Mon, 7 Mar 88 16:21:36 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Mike McNelly <mike@hpfclq.HP.COM> Subject: Re: I forget what it was originally called. Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Not only do different types cause changes in the order of evaluation, but different classes may also cause differences. C compilers make choices on the order of evaluation based on the "cost" of evaluating a subexpression. Pcc compilers typically evaluate a a subexpression with a high cost in register resources first. As a specific example, you may find your expression compiled differently if "i" is declared to be a register variable than if it was an auto or a static. Frankly I have little sympathy with anyone writing code in this manner. It's cute but it's also no more efficient than alternatives that do what you really wanted to do in a much less ambiguous fashion. If you inherited this code you have my condolences. Mike McNelly hplabs!hpfcla!mike
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6644 for SXJVK@ALASKA; Fri, 11 Mar 88 20:37 AST Received: by UWAVM (Mailer X1.25) id 4463; Fri, 11 Mar 88 21:36:47 PST Date: Thu, 10 Mar 88 17:16:56 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was netnews@psuvax1.cs.psu.EDU From: Scott Schwartz <schwartz@gondor.cs.psu.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <4940001@hpiacla.HP.COM> mlight@hpiacla.HP.COM (Mike Light ) writes: >> SinWave: packed array[0..255] of char; >> char SinWave[256]; >Almost any pascal-ism has an equivalent in C (but not necessarily >the other way around). Except that the useful ones are never that easy. One of my favorites: bitstring: packed array[0..1023] of boolean; In C you have to do bit-fiddling by hand to get the same effect. -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: nasty evil pointers [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6670 for SXJVK@ALASKA; Fri, 11 Mar 88 20:59 AST Received: by UWAVM (Mailer X1.25) id 4485; Fri, 11 Mar 88 21:48:29 PST Date: Thu, 10 Mar 88 16:46:16 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Jack Morrison <jackm@jpl-devvax.jpl.nasa.GOV> Subject: Re: nasty evil pointers Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <13100003@bucc2> brian@bucc2.UUCP writes: > >It would be nice if we could check every pointer as >it was used... Funny how often I see things in this newsgroup that can be answered with two words: try Ada. Even funnier because I still prefer using C. -- Jack C. Morrison Jet Propulsion Laboratory (818)354-1431 jackm@jpl-devvax.jpl.nasa.gov "The paycheck is part government property, but the opinions are all mine."
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Portable "asm" (Was: The D Programming Language) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6737 for SXJVK@ALASKA; Fri, 11 Mar 88 21:08 AST Received: by UWAVM (Mailer X1.25) id 4533; Fri, 11 Mar 88 22:07:32 PST Date: Thu, 10 Mar 88 18:08:20 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was netnews@PT.CS.CMU.EDU From: Eddie Wyatt <edw@IUS1.CS.CMU.EDU> Subject: Re: Portable "asm" (Was: The D Programming Language) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> > Since the interface between C and in-line asm seems to be so > problematic (not to mention non-portable), why not write > those routines that should be written in assembly in assembly? To which the obvious reply is speed - functions invocation can be RELATIVELY expensive. The time taken to invoke a subroutine may out way any gains that the asm statement made. Disclaimer - I don't use asm - don't plan on it either. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: ANSI C & Fortran 8x - Expand cpp to partially support generalized [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6866 for SXJVK@ALASKA; Fri, 11 Mar 88 22:24 AST Received: by UWAVM (Mailer X1.25) id 4602; Fri, 11 Mar 88 23:23:50 PST Date: Thu, 10 Mar 88 18:26:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@sun.uucp From: David Hough <dgh%dgh@Sun.COM> Subject: ANSI C & Fortran 8x - Expand cpp to partially support generalized precision Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> I've previously proposed that Fortran 8x include the C preprocessor, and that ANSI C support a limited interface to Fortran-77. While thinking about Bob Corbett's comments about a related Fortran 8x issue, generalized precision, a light flashed (fuse blowing?) and the right thing to do seemed clear. And unlike some of my other comments, this one touches an issue dear to almost every C programmer. So here's what I'll propose to X3J11, modified by the usual insightful reactions I expect you'll post: Comment #26, Section 3.8.8 and 2.2.4.2: predefine generalized precision macros The generalized precision proposal in Fortran 8x is complicated and controversial, yet responsive to a widely- recognized need among implementers of portable numerical software. The same need is most widely felt in the C com- munity as a question like this: what is the most efficient integral type that contains all integers in the range [- 99999,99999] ? Recommendation: To portably declare such types, add the following predefined macros to 3.8.8: __int__(p) is evaluated to the name of the smal- lest signed int type that contains all the signed p-digit integers, i. e. the interval [- (10**p)+1,10**p-1]. __unsigned__(p) is evaluated to the name of the smallest unsigned int type that contains all the p-digit unsigned integers, i. e. the interval [0,10**p-1]. __float__(p,r) is evaluated to the name of the smallest floating-point type that contains exactly all the p-digit signed integers, i. e. all the integers in the interval [-(10**p)+1,10**p-1], and contains 10**r and 10**-r within its range of positive model numbers. __INTEGER__(p) is evaluated to the Fortran name of the type corresponding to __int__(p,r), or to INTEGER is no Fortran compiler is supported. __REAL__(p,r) is evaluated to the Fortran name of the type corresponding to __float__(p,r), or to REAL if no Fortran compiler is supported. __COMPLEX__(p,r) is evaluated to the Fortran name of the complex type whose components are __float__(p,r), or to COMPLEX if no Fortran com- piler is supported. All the precision- and range-dependent macros fail, terminating compilation, if the precision or range requirements can't be met by any supported type. Recommendation: In order that the C pre-processor itself may be written portably, the C run-time library should provide certain corresponding string-valued functions that return the appropriate type for a particular implemen- tation, or a null string on failure. Add the following in <float.h> to implement the corresponding cpp macros: char * int__ (int p); char * unsigned__ (int p); char * float__ (int p; int r); char * INTEGER__ (int p); char * REAL__ (int p ; int r); char * COMPLEX__ (int p ; int r); David Hough ARPA: dhough@sun.com UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Wanted!! Lattace - C Manual [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6883 for SXJVK@ALASKA; Fri, 11 Mar 88 22:26 AST Received: by UWAVM (Mailer X1.25) id 4629; Fri, 11 Mar 88 23:25:40 PST Date: Wed, 9 Mar 88 05:12:21 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: ark@alice.uucp Subject: Re: Wanted!! Lattace - C Manual Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <12150@brl-adm.ARPA>, V064EHX5@ubvmsc.cc.buffalo.EDU writes: > Any one know where I can get a Lattace - C manual free or very cheap?? Reply to V064ehx5. Thank you! In other words, you've stolen a copy of the compiler and now you want someone to steal a copy of the documentation for you. And you have the gall to admit it in public. Amazing.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: sizeof(char) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6971 for SXJVK@ALASKA; Fri, 11 Mar 88 23:01 AST Received: by UWAVM (Mailer X1.25) id 4687; Sat, 12 Mar 88 00:00:55 PST Date: Thu, 10 Mar 88 22:08:16 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Doug Gwyn <gwyn@brl-smoke.arpa> Subject: Re: sizeof(char) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <17395@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >If C left the units of sizeof up to the implementor it would solve >a lot of problems (e.g. none of the multi-byte character mess that >is now in the proposed standard, and the problems of having to have >functions that know about the two different types of strings). >Other than allowing sloppily written code to continue to be written, >I can see no reason whatsoever for requiring that sizeof(char) be 1. >In Japan it could be 2, while on machines that do a lot of bit >manipulation it could be 16. Both are appropriate for their needs. Yes! I would appreciate it if you would send in a comment suggesting that the approach in X3J11/86-205 (my sizeof(short char)==1 proposal) should be considered in place of the proposed multi-byte character support. That is somewhat more ambitious than your sizeof(char)>=1 proposal, in that it provides an extra data type, so if that bothers you you could suggest merely that the requirement sizeof(char)==1 be dropped (which would leave the door open for later adoption of something ling X3J11/86-205, but unfortunately would not eliminate the proposed multi-byte character features).
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: I forget what it was originally called. [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 6928 for SXJVK@ALASKA; Fri, 11 Mar 88 22:50 AST Received: by UWAVM (Mailer X1.25) id 4656; Fri, 11 Mar 88 23:50:17 PST Date: Thu, 10 Mar 88 19:30:54 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was netnews@PT.CS.CMU.EDU From: Eddie Wyatt <edw@IUS1.CS.CMU.EDU> Subject: Re: I forget what it was originally called. Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > Which brings me to another question: How good are compilers these > day? Can they optimize just as well as a programmer (without > resorting to assembly, that is) or not? For example: [common subexpress example deleted] All depends on the compiler. ccp is generally a bad optimizing compiler. Green Hill gcc and Tartan C compilers are suppose to produce lightening fast executables. If I could only get gcc to compile a copy of "man", I might use it. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Another \"D\" idea: RPN (and more) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7008 for SXJVK@ALASKA; Fri, 11 Mar 88 23:18 AST Received: by UWAVM (Mailer X1.25) id 4729; Sat, 12 Mar 88 00:18:22 PST Date: Thu, 10 Mar 88 22:13:35 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Doug Gwyn <gwyn@BRL-SMOKE.arpa> Subject: Re: Another \"D\" idea: RPN (and more) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <124200005@inmet> justin@inmet.UUCP writes: >/* Written 4:29 pm Mar 3, 1988 by gwyn@brl-smoke.UUCP in inmet:comp.lang.c */ >In article <12088@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: [...] >God, it's finally happened. I had heard about this trend, but I couldn't >believe it. But it's really true. Nobody on the net (except in talk.bizarre) >is capable of recognizing sarcasm without a row of smileys at the end! Actually, the two of us conspired in advance to post this dialogue. But I did mean what I said in my response, unlike the originator who was indeed just poking fun at the "D language" discussion.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Why I won't use ANSI C [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7033 for SXJVK@ALASKA; Fri, 11 Mar 88 23:24 AST Received: by UWAVM (Mailer X1.25) id 4744; Sat, 12 Mar 88 00:23:30 PST Date: Thu, 10 Mar 88 22:45:09 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Doug Gwyn <gwyn@brl-smoke.arpa> Subject: Re: Why I won't use ANSI C Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <933@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >I could go on, I'll spare you though (whew!) except to say that I *do* >believe that we should remember that Doug's position on the ANSI committee >gives him a certain power, but *not* necessarily a superior opinion on the >contentious issues we all discuss (argue? shout about? go to sleep over?...). Thanks for your comments. The one real advantage that participating in X3J11 has given me is that I've heard all the arguments for changing = to := and the other such ideas that keep popping up in this newsgroup many times before. Some topics, such as = vs. ==, have probably been sparked by magazine articles, since the same old arguments keep getting repeated. To give you some idea of what X3J11 is up against, of 717 public comments from the first formal review, roughly 257 (that's 36%) were adopted in some form. The remaining 460 comments (64% of the total) had to be read, understood, discussed, and explanations of why they were not adopted had to be written. The work kept the whole committee busy for many days. It shouldn't be any wonder that some of us by this point have little patience with the same suggestions that we've had to write rejection rationale for over and over. By the way, = vs. == was indeed considered by X3J11, but what can we do about it? If it were changed, the result could not reasonably be called "C". In fact, as I recall, most of us don't even think it should be changed if it were feasible to do so. The only approach that is at all compatible with a large body of C code (but by no means all) would be to introduce Boolean expressions and require that the control conditions of if(), while(), for(), do..while() be Boolean expressions. That would solve the if ( a = 0 ) problem. But it would break so much existing code that I for one am sure that no such "C" standard [that requires a diagnostic when the Boolean-expression constraint is violated] would be generally accepted.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Apology to Richard Harter [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7183 for SXJVK@ALASKA; Sat, 12 Mar 88 01:18 AST Received: by UWAVM (Mailer X1.25) id 4835; Sat, 12 Mar 88 02:17:15 PST Date: Wed, 9 Mar 88 17:44:39 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Dave Burton <daveb@laidbak.uucp> Subject: Apology to Richard Harter Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <25387@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: |In article <1354@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: |>Please don't design D until you understand C. |Er, Dave, may I suggest it is inadvisable to make remarks such as |"Please don't design D until you understand C". You're right. I'm sorry for the slight. The remark was not intented to be a slurr on your personal abilities, rather a plea against throwing features at a language. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7209 for SXJVK@ALASKA; Sat, 12 Mar 88 01:20 AST Received: by UWAVM (Mailer X1.25) id 4882; Sat, 12 Mar 88 02:18:05 PST Date: Thu, 10 Mar 88 18:04:34 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Chris Torek <chris@mimsy.uucp> Subject: Re: Header problems Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> [This makes three.] In article <121@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes: >For compilers that don't support (void *), you must have >a compiler-specific definition of NULL: No. > #define NULL 0 /* If sizeof(int) == sizeof(char *) */ > or > #define NULL 0L /* if sizeof(long) == sizeof(char *) */ Either is technically legal. The former suffices, is not machine dependent, and is correct. >Since the above #defines are necessarily machine (and compiler) specific, The definition of NULL (as 0, or if you have a dpANS-conformant compiler, as (void *)0) is not machine dependent. What *is* machine dependent is whether uncasted 0 in unprototyped function calls appears to work. Using uncasted 0L appears to work (but is nonetheless wrong) on IBM PCs using large model compilers. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Turbo Pascal -> MSC translator [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7199 for SXJVK@ALASKA; Sat, 12 Mar 88 01:19 AST Received: by UWAVM (Mailer X1.25) id 4867; Sat, 12 Mar 88 02:17:30 PST Date: Thu, 10 Mar 88 13:26:23 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Matt Burdick <burdick@iuvax.cs.indiana.EDU> Subject: Turbo Pascal -> MSC translator Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> A few months ago, there was a discussion on the net about a Turbo Pascal to Microsoft C translator that Microsoft was giving away. There was a toll-free number at Microsoft to order it from, but I have since deleted that info. If anyone still has the number, could you e-mail it to me? I will post it if/when I get it. Has anyone used it and thought it useful? -matt -- UUCP: {ihnp4,pyramid,akgua}!iuvax!burdick All these nodes are yours ARPA: burdick@iuvax.cs.indiana.edu Except nsavax BITNET: burdick@iubacs.bitnet Attempt no logins there Use them together Use them in peace
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7218 for SXJVK@ALASKA; Sat, 12 Mar 88 01:22 AST Received: by UWAVM (Mailer X1.25) id 4899; Sat, 12 Mar 88 02:18:11 PST Date: Thu, 10 Mar 88 23:16:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@sigi.Colorado.EDU From: Frank Swarbrick <swarbric@tramp.Colorado.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: :In article <4940001@hpiacla.HP.COM> mlight@hpiacla.HP.COM (Mike Light ) writes: :>> SinWave: packed array[0..255] of char; :>> char SinWave[256]; : :>Almost any pascal-ism has an equivalent in C (but not necessarily :>the other way around). : :Except that the useful ones are never that easy. One of my favorites: : bitstring: packed array[0..1023] of boolean; :In C you have to do bit-fiddling by hand to get the same effect. : How about: typedef char bool; bool bitstring[1024]; Or does the "packed" thing in Pascal have some special meaning? I never could figure out what the difference between a packed array and a regular array was. Frank Swarbrick (and his cat) swarbric@tramp.UUCP swarbric@tramp.Colorado.EDU ..!{hao|nbires}!boulder!tramp!swarbric "Can't help about the shape I'm in. I can't sing, I ain't pretty, and my legs are thin."
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: The D Programming Language: got [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7227 for SXJVK@ALASKA; Sat, 12 Mar 88 01:23 AST Received: by UWAVM (Mailer X1.25) id 4915; Sat, 12 Mar 88 02:18:54 PST Date: Wed, 9 Mar 88 14:16:00 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: mcdonald@uxe.cso.uiuc.EDU Subject: Re: The D Programming Language: got Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> >There are only three reasons for using a goto. Firstly, to implement a >control structure not directly available in the language in question. This >"deficiency" is not necessarily bad; I've used goto to emulate coroutines, but >I probably wouldn't want to see coroutines added to the language. If you >remove goto but then add every other possible flow construct just to avoid the >desire for a goto, you end up with BLISS. Let's not do that. >Secondly, error handling, which could be considered a special case of the >first reason in that it emulates an exception construct of some type. This >includes not only cleanup-and-return but also retry-operation; sometimes a >simple backward goto is clearer than a while. >Thirdly, you can use a goto if you really, really want to, a whole lot. :-) >(I use this as my universal escape clause.) I've only used goto's for non-error handling cases once in C. This is, I guess, an example of Heuer's third case. The particular event was the input parser for my text adventure "World". A logic diagram for this is, like the English language it must decipher, a bowl of spaghetti. I tried for quite a while it untangle it, and finally gave up. The only way I was ever able to get rid of the goto's was to define a "state variable" which would be set to some "magic" number at the end of every block of code ending in a goto. Then I put everything in a big case statement, going to the appropriate place depending on this magic variable. The case statement was inside a do ... while(statevar != QUIT). This gets rid of the goto's, but you are left with the magic numbers. Do you leave them as numbers? No, this is not easy to read, so you give them symbolic names that are #defined somewhere in the upper reaches of the program. At this point I get thinking "Why not just leave in the goto's, and give the labels the appropriate names?" It seems to me that if you reach the point where you have to use the formally guaranteed-to-work method of removing goto's, you might as well leave them in.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Pointers to functions [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7237 for SXJVK@ALASKA; Sat, 12 Mar 88 01:24 AST Received: by UWAVM (Mailer X1.25) id 4931; Sat, 12 Mar 88 02:19:22 PST Date: Thu, 10 Mar 88 12:53:33 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "ELIN Forsch.z." <RCVIE@TUVIE> Subject: Re: Pointers to functions Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <7811@tut.cis.ohio-state.edu- mills-cl@pike.cis.ohio-state.edu (christopher mills) writes: -/* I think D should have Ada-style comments... */ - - Hello there. I was writing a compiler for a simple C-like language of -my own design for a single-board 6809 computer of mine, and I got around to -the pointer arithmetic part and wondered what C does when you try to do -pointer arithmetic on a pointer to a function. I figgured it would generate -an error (since functions do not have a "size"), but being curious, I tried it -on a few C compilers I had around. Suprisingly, many don't flag it as an -error at all and do something implementation-defined and unpredictable (for -example, Lattice C 3.10 on the Amiga treats it as if it were a char *, which -I find odd, because it generates 68000 code which must be even-address -aligned - I would have at least expected it to treat it as a short *). - K&R doesn't say anything about this (as far as I know). I think it -shows a breakdown in the typing system - pointers to functions aren't really -pointers, but a distinct type. Thoughts? Flames? Neither. A correction: K&R say (in my German edition) that only a pointer to an arry element and an integer may be added or subtracted and that no other (pointer) arithmetic is allowed. The dpANS says that "one operand shall be a pointer to an object and the other shall have integral type". An object is defined as "a region of data storage in the execution environment, the contents of which can represent values". This is a more liberate definition for pointer arithmetic than K&R have. In any case, pointer arithmetic on pointers to functions is prohibited. In article <7689@pur-ee.UUCP- hankd@pur-ee.UUCP (Hank Dietz) writes: -This reminded me of a long-standing inconsistency in C in treating -labels. The old pdp11 C compiler used to think labels were actually -constant-valued pointers to instructions, and you could in fact use -them that way. According to K&R, this treatment was just plain wrong - -labels are a separate type - but I had a few systems programmers -telling me that the idea is useful AND THAT THEY HAD USED IT. - -It seems to me that address arithmetic on pointers to functions ought -to be scaled to maintain alignment, as suggested above, and that this -might be part of a "clean" assembly/monitor interface. However, as I've -pointed out, one could easily extend this concept to make labels be -treated as the type "pointer to in-line code." I'm not sure I like -this idea, but, as noted above, I know at least a few C programmers -who'd be happy I mentioned it. Actually, I guess I'm against the idea -because it would really destroy compile-time flow analysis... but I -felt I should point out the issue anyway. The idea to have the same pointer arithmetic on labels as on pointers to functions seems to be a good one (in my opinion). It could help system programmers to solve some problems via tricky programming (I know, I know, ... tricky programming should not be propagated, but some problems can be solved *only* by tricky programming). Secondly this would allow additional entry points into functions. It seems to me as if K&R had something like that in mind when they reserved the keyword entry. Has anybody information why this feature has never been implemented? Dietmar Weickert, ALCATEL-ELIN Research Center, Vienna, Austria.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Why he won't use ANSI C [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7246 for SXJVK@ALASKA; Sat, 12 Mar 88 01:25 AST Received: by UWAVM (Mailer X1.25) id 4947; Sat, 12 Mar 88 02:19:35 PST Date: Thu, 10 Mar 88 19:00:03 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Chris Torek <chris@mimsy.uucp> Subject: Re: Why he won't use ANSI C Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <933@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >To a certain extent I agree with the sentiments expressed above [a `thank you' to Doug Gwyn that I deleted] >by Richard even though (if anyone cares) I sometimes vent my frustration >at some of Doug's idiosyncratic responses. Venting frustration in netnews is something many will do (yes, I too), though it is usually counterproductive. Since it happens, readers of this group (and other groups) should watch for it and try not to let it affect them. >If you hold yourself up as an authority, as Doug does, you must be very >careful to maintain your credibility. Here I will argue philosophy (another counterproductive effort :-) ). I say one cannot `hold oneself up as an authority'. There are two kinds of Authority. One boils down to `power'; in the Usenet dementiarchy [*], at least, and to a fair extent in the ARPA-land info-c mailing list, this meaning does not apply. The other is, in essence, `knowledge'; the only true Authority in this sense is that which is demonstrated. Hence it is his readers who (sensibly) regard Doug Gwyn as an Authority on the latest doings of the ANSI X3J11 committee. Thus it is (at least in part) up to those readers to separate Gwyn-opinion from committee-fact. ---- [*] `Rule by madness'. (I made it up.) >What does it matter if *I* spout off, who am I, but Doug has positioned >himself such that his readers should be able to rely on the veracity of his >remarks. He should thus be careful what he says and how he says it. Perhaps so; but it *does* matter if you, or indeed anyone, `spouts off'. As you yourself put it: >... in my mind it denegrates the "quality" of [one's] >postings and [one's] credibility as an authority. >Earlier gurus of 4 or 5 years ago ... would >rarely resort to sarcasm and downright dismissal of others views! (I think your memory has mellowed the situation somewhat.) >[Mind you, Chris Torek seems to be getting a little crotchetty in his >old age these days! (:-)]. I am not! Why you young whippersnapper, I will have you know . . . . :-) (Besides, I am only 24, and even among full mortals that is rarely considered old, to say nothing of Halfelven.) Seriously, though, anyone can rant, and most of us do; while as authors we should try to minimise this, as readers we should also expect it, and do our best to ignore it. >If anyone wants to follow up this posting, please choose an appropriate news >group. I could not think of any better place (except perhaps /dev/null, but then that was why I put in the Summary header above.). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: HLLs vs asm (was Re: portable "asm") [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7257 for SXJVK@ALASKA; Sat, 12 Mar 88 01:27 AST Received: by UWAVM (Mailer X1.25) id 4963; Sat, 12 Mar 88 02:20:38 PST Date: Thu, 10 Mar 88 04:13:35 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Dave Burton <daveb@laidbak.uucp> Subject: HLLs vs asm (was Re: portable "asm") Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> I'm redirecting this to comp.lang.misc - it's lost all its flavor of C. (Herman, I won't be reading comp.lang.misc, if you want, Email me - Dave) In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: |Frankly, I believe that if someone developed a decent high-level, overloaded |operator, reasonable syntax assembler it would have a good chance of |supplanting C. Add the other useful features of C and you have a good |language. My definition of assembler may be antiquated, but it says that there is a one-to-one (or one to _very_ few) source statements to target statements. I do not think such a beast as your hypothetical super-assembler is likely. I do think C could be improved on in several areas, but which direction? Should C's successor be system implementation oriented, or general purpose oriented; i.e: more explicit control of the underlying machine, or more generalized, higher level constructions? #asm is not of the latter. |Suppose that you have a situation in a program where the implementation of |your compiler has done something bad, like use 10 instructions and 6 memory |references where 2 instructions and no memory references can do the job. |The overhead of a subroutine call is likely to be more than what can be |saved; a goto construction may not work if part of the problem is that the |compiler will mess up register use (very common). The number of situations where the matter of a few microseconds is a make or break proposition is extremely limited. Where they do occur, they are non-portable. These situations are very likely best handled in assembly for that routine, anyway. |Also some of the very simple hardware operations which are useful for some |problems have not been anticipated by the language developlers. This is so |often the case for simple operations frequently found in hardware. More |machines have a hardware operation &~, which most mathematicians normally |use \ for, than have the operation &. I am more likely to want to use &~. If I understand you properly, you want to switch between a HLL and assembly, with regularity, to use machine specific instructions. I think this is in contrast to the basic principles of high-level languages. HLLs are designed to allow a higher level of abstraction than assembly, and somewhat more portability. |If a programmer says that something is inline, and this should be a feature |of any language, the compiler should at most point out why this is not good, |but the judgment must be that of the programmer. Something troubles me about this statement, but I don't know what. I'm inclined to agree. |> [ on language gurus claiming omniscience, deleted ] |The language gurus may not claim this, but I am not so sure. The |designers of 4.xBSD clearly state in their assembler documentation |that the assembler is _not_ for programmers, but for compiler designers |and system maintainers. I believe this is not so much omniscience as practicality. I *like* programming in assembly. I like the control, the flexibility. But I have never written a major application under Unix in pure assembly. Why should I? I can be much more productive in C. Because it's so inconvenient to do assembly hacking, almost nobody does it. With so many using C, lisp, f77, ratfor, efl, what-have-you, why expend a great deal of effort on an assembler used 99% percent of the time by automated software? |But in too many cases, the existing HLLs may produce good code if small |modifications are made. In many cases, these modifications are machine |independent--I can give you cases of this. It may even be as simple as |saying | This is what is needed; implement this block efficiently, while | maintaining its compatibility with the rest of the program. | |That is another reason for asm. Isn't this actually arguing against asm? |> You presume that this same individual also knows how the HLL |> implements itself on that machine. This is not the case. Very few people |> that know both the HLL and the machine instruction set will know what kind |> of code the compiler will produce. |Why not? OK, I know this is not quite the same, but consider interpretive languages. Who knows what shadows lurk ... :-) These include not only BASIC (ack!), lisp, prolog, sno[bol], but "4GL"s like SQL, Informix, Accel and the too many others. Even with compilers, many people do not _take the time_ to learn the transformations performed upon their HLL by the compiler. I never bothered to study the output of FORTRAN or Ada, but I know the assembly language for the machines I write them on. The point is, I and most others don't get paid to cogitate the most efficient possible expression for situation X. (Not that I would mind! :-) It just isn't necessary to know. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7371 for SXJVK@ALASKA; Sat, 12 Mar 88 01:41 AST Received: by UWAVM (Mailer X1.25) id 5011; Sat, 12 Mar 88 02:41:06 PST Date: Fri, 11 Mar 88 01:41:57 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was netnews@psuvax1.cs.psu.EDU From: Scott Schwartz <schwartz@gondor.cs.psu.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >: >:Except that the useful ones are never that easy. One of my favorites: >: bitstring: packed array[0..1023] of boolean; >:In C you have to do bit-fiddling by hand to get the same effect. >: >typedef char bool; >bool bitstring[1024]; > >Or does the "packed" thing in Pascal have some special meaning? I never could >figure out what the difference between a packed array and a regular array was. The "packed" thing has a special meaning. I can't quote you from the ANSI or ISO standards offhand, but the idea is that the compiler is supposed to arrange that the packed structure takes up a minimal amount of space (probably subject to some alignment restrictions). So in the example I gave each boolean would take up one bit, and there would be 1024 of them, the whole array taking up 128 bytes. Unpacked, each boolean would take up one, two, or maybe four (depending on how unlucky you are) bytes. In (I can't believe I'm about to type this, but...) the hypothetical "D" language it would be nice to be able to say typedef bool bit; bool bitstring[1024]; but, alas.... -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7390 for SXJVK@ALASKA; Sat, 12 Mar 88 01:57 AST Received: by UWAVM (Mailer X1.25) id 5026; Sat, 12 Mar 88 02:56:39 PST Date: Fri, 11 Mar 88 02:36:59 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Roland McGrath <rk9005@cca.ucsf.EDU> Subject: Re: Don't use Scanf() Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> One real stupidity I've seen many, many times is the over-use of printf. The printf functions have their uses, and they do their job quite well, but please know what these uses are!! For example: printf("Hello world!\n"); Haven't you ever heard of puts???? puts("Hello world!"); /* note the newline is appended */ or printf("hi"); try fputs: fputs("hi", stdout); /* no newline appended */ What's that? Oh, now you have to include <stdio.h> so you can get the proper declarations of all these functions anyway? Poor baby! And the ultimate stupidity: printf("\n"); Get a brain!!!!! You're using the function that can do complex data formatted output to write one bleeping character!!!!! Try putchar('\n'); If you include <stdio.h>, this will probably end up being a macro that will write it out very fast. I have even seen: sprintf(buf, "constant string"); Hey, Mr. Power-Programmer, ever heard of strcpy???? In general, if there's no format spec, don't use printf!!!!!! -- Roland McGrath ARPA: roland@rtsg.lbl.gov roland@lbl-rtsg.arpa UUCP: ...!ucbvax!lbl-rtsg.arpa!roland
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: sizeof(char) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7424 for SXJVK@ALASKA; Sat, 12 Mar 88 02:18 AST Received: by UWAVM (Mailer X1.25) id 5052; Sat, 12 Mar 88 03:18:15 PST Date: Fri, 11 Mar 88 18:26:54 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Rahul Dhesi <dhesi@bsu-cs.uucp> Subject: Re: sizeof(char) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <2328@bsu-cs.UUCP> I wrote: >And nowhere do I find >K&R saying that byte == char == 1 unit is simply a compiler peculiarity >and not a design assumption in the language. Looking again, more carefully this time, I find this on page 188: A byte is undefined by the language except in terms of the value of sizeof. And yet, looking at the extensive discussion of a function alloc() to allocate memory and a portable implementation of it, we find that char and byte are used synonymously in the examples given. See pages 96-98 and then 173-177. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Bit Addressable Architectures [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7433 for SXJVK@ALASKA; Sat, 12 Mar 88 02:19 AST Received: by UWAVM (Mailer X1.25) id 5069; Sat, 12 Mar 88 03:18:26 PST Date: Wed, 9 Mar 88 14:47:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Frank Adams <franka@mmintl.uucp> Subject: Re: Bit Addressable Architectures Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1988Mar6.002518.945@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >As an extreme case, >one can envision a bit-addressable machine -- that is, one whose pointers >use the low-order three bits to indicate a bit within a byte -- that traps >whenever those bits aren't zero, leaving the actual use of bit pointers >entirely up to the software. When all accesses were in fact aligned, this >would incur essentially no overhead except the reduction in address space. This may sound like an off the wall idea, but it makes a lot of sense to me. This would mean that arithmetic on bit pointers can be done using the standard arithmetic operations; and no special format is required for them. Note that the software need not wait for a trap to deal with unaligned data -- if it knows it is dealing with a bit pointer, it can extract and deal with the low order bits itself. As for the address space issue: I personally believe that 32 bit addresses are too short, and that this will become apparent fairly quickly. With a 64 bit address, one can afford to use 3 bits this way. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7456 for SXJVK@ALASKA; Sat, 12 Mar 88 02:39 AST Received: by UWAVM (Mailer X1.25) id 5085; Sat, 12 Mar 88 03:39:04 PST Date: Fri, 11 Mar 88 23:06:14 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: mike knudsen <knudsen@ihwpt.ATT.COM> Subject: Re: Don't use Scanf() Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> Good points. But if you already are using printf() in your program (with a legitimate need for the formatting) in several places, then substituting puts() where possible will make your program object file bigger, not smaller, since now the puts() code has to be linked in too. Puts() and putchar() will be a little faster, but when you're talking to humans who cares? BTW, I once wrote a large interactive monitor for a free-standing 8086 board, using a C that had no I/O at all. I wrote routines to output %2x, %4x, and %5d as well as strings. Took a lot of calls to do one good printf(), but it IS possible and such custom I/O may save you bytes. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!" "OS/2 == 1/2 of an OS"
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: Apology to Richard Harter [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7562 for SXJVK@ALASKA; Sat, 12 Mar 88 03:27 AST Received: by UWAVM (Mailer X1.25) id 5154; Sat, 12 Mar 88 04:26:55 PST Date: Fri, 11 Mar 88 05:28:14 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Richard Harter <g-rh@cca.CCA.COM> Subject: Re: Apology to Richard Harter Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1361@laidbak.UUCP> daveb@laidbak.UUCP (Dave Burton) writes: > >You're right. I'm sorry for the slight. >The remark was not intented to be a slurr on your personal abilities, >rather a plea against throwing features at a language. Ooooh. You realize, don't you, that it is against net protocol to apologize. You almost gave a heart attack from the shock! :-) No offense taken, and there is justice in your position. Just be careful about these gratuitous apologies in the future or else you will see the net.police descending upon you. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Recursion (was: The D Programming Language)
[Non-Deliverable: User does not exist or has never logged on]
Reply-To: Info-C@BRL.ARPA
Received: From UWAVM(MAILER) by ALASKA with Jnet id 7576
for SXJVK@ALASKA; Sat, 12 Mar 88 03:30 AST
Received: by UWAVM (Mailer X1.25) id 5170; Sat, 12 Mar 88 04:28:41 PST
Date: Fri, 11 Mar 88 23:43:17 GMT
Reply-To: Info-C@BRL.ARPA
Sender: Info-C List <INFO-C@NDSUVM1>
From: 00704a-Liber <nevin1@ihlpf.ATT.COM>
Subject: Recursion (was: The D Programming Language)
Comments: To: info-c@BRL-SMOKE.arpa
To: Vic Kapella <SXJVK@ALASKA>
In article <704@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
There are two problems with this. While using stacks may be easy to program,
it involves lots of loads and stores. I know of at least one machine on which
the normal subroutine call and return do not use stacks. Furthermore, if the
called routine may make additional calls, it may be necessary to use a
separate return stack, and this may require each such subroutine to maintain
its own return stack. In some cases this should be the way to do things,
but not always.
I would not be so worried about the efficiency of passing values to and
from functions on non stack-based machines and be more worried about how
you are going to implement efficiently a language which allows recursion
(C, Pascal, etc.) on a non stack-based machine. I do know that machines
like this exist (yea, I have programmed on a PDP-8), but I haven't seen an
efficient implementation of Pascal or C on any of these machines. The only
model that I know of that supports recursion is a stack. BTW, what I mean
by recursion is that if you graph out the functions in the order that they
are called and you find a cycle in it, it's recursive.
Another problem comes with inline functions. I believe that many function
calls, if not most, should be inline. In this case, I think the result should
go to its destination at the time produced. If the destinations involve
registers or register indirects, the expression of the algorithm must take
the busy set of registers into account. This admittedly makes coding
difficult, and is one reason why I believe DNA can optimize better than
silicon. (The two should be used together, but I do not know of any compiler
which allows the programmer to even give it a hint as to how to optimize,
let alone improve the resulting product.)
As I have told you before, NOT ALL FUNCTIONS ARE INLINEABLE!! Any function
that can be called recursively (see my above definition of recursive) an
unknown (at compile/link time) number of times cannot be inlined!!
Also, another reason that you may not want to inline functions is that on a
smaller machine (such as a PC), you may have to move to a larger memory
module because your activation record is much bigger (it might no longer
fit into a segment, etc.).
Thirdly, if you are calling shareable routines you cannot inline them,
since their code is never actually put into the text segment.
BTW, I am not against inlining per se (I like it much more than macros),
but I do not feel that it should be done if it might break the code (any
function that might be recursive shouldn't be inlined). 'inline' should
be a hint in much the same way that 'register' is a hint (and NOT the way
'noalias' is a hint in the C draft standard).
Here is another proposition for the 'D' language: the keyword 'unroll'
(see Jon Bentley's "Programming Pearls" for reference) should be allowed
in front of any *simple* for loop. What this would do is, for example,
is change:
unroll for (i=1; i <= 4; i++)
printf("String number %d is: %s\n", i, string[i]);
to:
printf("String number 1 is %s\n", string[1]);
printf("String number 2 is %s\n", string[2]);
printf("String number 3 is %s\n", string[3]);
printf("String number 4 is %s\n", string[4]);
i=5;
since the latter is more efficient with respect to speed. Of course, the
comments I made above about potentially breaking code apply here is well
('unrolling' would only be a hint). Comments??
--
_ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194
' ) ) "The secret compartment of my ring I fill
/ / _ , __o ____ with an Underdog super-energy pill."
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: nasty evil pointers [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7634 for SXJVK@ALASKA; Sat, 12 Mar 88 04:04 AST Received: by UWAVM (Mailer X1.25) id 5209; Sat, 12 Mar 88 05:03:32 PST Date: Fri, 11 Mar 88 23:54:38 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: 00704a-Liber <nevin1@ihlpf.ATT.COM> Subject: Re: nasty evil pointers Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <13100003@bucc2> brian@bucc2.UUCP writes: >It would be nice if we could check every pointer as it was used... This seems to be more of a job for the OS than for the language. If you try to check every single use of pointers, you end up with a language like Pascal :-). I don't mind the checking of pointers as long as it doesn't interfere with the efficiency that those of us who program in C have come to love :-). Also, if the pointer checks find an error, I would like it to transfer control to an error-handling section of my program so that I could either try to recover or go down *gracefully* (saving calculated data, etc.). -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/12/88)
Subject: Re: The D Programming Language [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7644 for SXJVK@ALASKA; Sat, 12 Mar 88 04:05 AST Received: by UWAVM (Mailer X1.25) id 5225; Sat, 12 Mar 88 05:04:25 PST Date: Thu, 10 Mar 88 21:26:58 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Stuart D. Gathman" <stuart@bms-at.uucp> Subject: Re: The D Programming Language Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <700@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > but even for direct operators. For example, the infamous frexp function > in C should not have the syntax > y = frexp(x,&n); > but > y,n = frexp(x); > This would, for example, allow n to be in a register, which is probably > where it should be anyhow. > Another example would be to have > q,r = a///b; > where the quotient and remainder are simultaneously produced. Possibly Another example is string comparison. I use a string compare function that returns the index of the first different character. I also need the gt/lt/eq result. Fortunately, in this case it is easily computed by recomparing the chars at the index. This is another case of a double valued hardware primitive. (Available on all three of the architectures we use: Series/1, 80286, 68020.) -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Why NULL is 0 [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001 for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST Date: Fri, 11 Mar 88 21:56:46 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Doug Gwyn <gwyn@brl-smoke.arpa> Subject: Re: Why NULL is 0 Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <124@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes: >Perhaps ANSI should add the restriction that all pointer types must be >the same size in an effort to "codify common existing practice." But it isn't existing practice. If you mean, non-portable, buggy code is existing practice, well yes, but so what? That certainly shouldn't serve as the basis for a standard.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: SUN Env. Vars. [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8019 for SXJVK@ALASKA; Sat, 12 Mar 88 10:51 AST Received: by UWAVM (Mailer X1.25) id 5370; Sat, 12 Mar 88 11:50:10 PST Date: Fri, 11 Mar 88 17:35:10 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Stuart A. Werbner" <stu@linus.uucp> Subject: SUN Env. Vars. Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> Hello fellow SUN/UNIX enthusiasts. Could someone please mail me a list of all environment variables recognized by the Sun 3.x Operating System (and resident commands and utilities). If not, could someone please tell me how to (easily) find such a list. Thank you.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8047 for SXJVK@ALASKA; Sat, 12 Mar 88 10:51 AST Received: by UWAVM (Mailer X1.25) id 5422; Sat, 12 Mar 88 11:50:37 PST Date: Thu, 10 Mar 88 19:02:12 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Mark Brader <msb@sq.uucp> Subject: Re: Header problems Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> > By the way, if you call f(0) where f expects a char *, the requirement > for it to work is not simply that sizeof(int) == sizeof(char *), but > also that (int)0 and (char *)0 have the same bit representation. *And* that the implementation passes integer and pointer type values to functions in the same manner. Remember, arguments can be passed in registers and machines can have several types of registers. *Never* say f(0) or f(NULL). Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com #define MSB(type) (~(((unsigned type)-1)>>1))
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8056 for SXJVK@ALASKA; Sat, 12 Mar 88 10:52 AST Received: by UWAVM (Mailer X1.25) id 5439; Sat, 12 Mar 88 11:50:45 PST Date: Fri, 11 Mar 88 23:57:37 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: 00704a-Liber <nevin1@ihlpf.ATT.COM> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3352@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: >Except that the useful ones are never that easy. One of my favorites: > bitstring: packed array[0..1023] of boolean; >In C you have to do bit-fiddling by hand to get the same effect. Yes, but in C you are guaranteed that bits are actually used. Not many implementations of Pascal bother to implement packed arrays any differently than non-packed arrays, so what you get is an array of 1024 words (where the sizeof(word) is implementation-dependent). -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8077 for SXJVK@ALASKA; Sat, 12 Mar 88 10:53 AST Received: by UWAVM (Mailer X1.25) id 5474; Sat, 12 Mar 88 11:51:00 PST Date: Thu, 10 Mar 88 18:34:58 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@rtech.uucp From: Jim Shankland <jas@llama.rtech.uucp> Subject: Re: Header problems Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3351@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes: >Your use of NULL === 0 promotes unportable code, and is considered to be >bad programming style in a world where portability across multiple machine >architectures ... is required.... On machines were sizeof int != >sizeof(void *), the above definition will >not work.... A better way to do it, in each place you want to define NULL, >is: > > #ifndef NULL > #define NULL ((void *)0) > #endif Ack! Here it comes again! Warm up the ``kill'' file. Jim Shankland ..!ihnp4!cpsc6a!\ sun!rtech!jas ..!ucbvax!mtxinu!/
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Another \"D\" idea: RPN (and more) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8271 for SXJVK@ALASKA; Sat, 12 Mar 88 11:24 AST Received: by UWAVM (Mailer X1.25) id 5559; Sat, 12 Mar 88 12:24:25 PST Date: Sun, 6 Mar 88 17:14:47 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Gregory Conway <gregory@ritcsh.uucp> Subject: Re: Another \"D\" idea: RPN (and more) Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <12088@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: > > Another thing that "D" should have... actually not have, is pointers. At > least 85% of the problems discussed here on Info-C are people who have > some problem with confusion about pointers. Removing pointers would solve > this whole set of problems. > You seem to me to be a little hasty here. The problem has NOTHING to do with pointers, but rather people who do not understand pointers who use them anyways. Pointers are the most powerful aspect of the C programming language and are what make it such a joy to work with. To para-phrase, pointers don't kill, programmers do. -- ================================================================================ Gregory Conway@Computer Science House UUCP: ...rochester!ritcv!ritcsh!gregory Rochester Institute of Technology, Rochester, NY "I got an allergy to Perrier, daylight, and responsibility", Marillion
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: CPP defines... [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8297 for SXJVK@ALASKA; Sat, 12 Mar 88 11:29 AST Received: by UWAVM (Mailer X1.25) id 5578; Sat, 12 Mar 88 12:29:11 PST Date: Thu, 10 Mar 88 23:38:46 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Nick Crossley <nick@ccicpg.uucp> Subject: Re: CPP defines... Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <179@istop.ist.CO.UK> rb@ist.CO.UK (News reading a/c for rb) writes: >Here's a nasty little script that comes in useful when you >want to know what your cpp *really* predefines: we have found >that the man page is sometimes economical with the truth. > ... >strings -a -2 /lib/cpp | sed '/^a-zA-Z0-9_/!s/.*/#ifdef &\ >"%&"\ >#endif/p' |/lib/cpp |sed -n '/%/s/[%"]//gp' Ah, but not all systems have their predefined symbols defined by cpp! I know of some which define some symbols in cc! Thus, a better? more complete? approach might be :- strings <options as required> /lib/cpp /bin/cc | sort -u | sed -n '/^[a-zA-Z0-9_]*$/s//#ifdef &\ "%&"\ #endif/p' >cpp_test.c cc -E cpp_test.c | sed -n '/%/s/[%"]//gp' -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8306 for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST Received: by UWAVM (Mailer X1.25) id 5593; Sat, 12 Mar 88 12:29:18 PST Date: Fri, 11 Mar 88 18:40:35 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was netnews@psuvax1.psu.EDU From: Scott Schwartz <schwartz@gondor.cs.psu.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <760@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: >> So in the >> example I gave each boolean would take up one bit, and there would be >> 1024 of them, the whole array taking up 128 bytes. >The trouble is that a Pascal compiler is absolutely free to ignore >'packed' entirely. When you say > var a: array [0.1023] of boolean; >you have no guarantee at all that the compiler won't use 1024 "words". Right. Lots of (bad) compilers ignore "packed", just like some C compilers ignore "register". For the purpose of argument I was assuming a decent pascal compiler. The University of Sheffield, for example, sells a pascal compiler for Prime 50 series machines that implements "packed" down to the bit level. There's nothing like automatically taking advantage of your instruction set. Anyway, enough pascal talk. On to the next comp.lang.c topic! -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Why NULL is 0 [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8323 for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST Received: by UWAVM (Mailer X1.25) id 5618; Sat, 12 Mar 88 12:29:37 PST Date: Fri, 11 Mar 88 02:57:33 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Pablo Halpern <pablo@polygen.uucp> Subject: Re: Why NULL is 0 Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> From article <10576@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > (You may wish to save this, keeping it handy to show to anyone who > claims `#define NULL 0 is wrong, it should be #define NULL <xyzzy>'. > I intend to do so, at any rate.) > > Let us begin by postulating the existence of a machine and a compiler > for that machine. This machine, which I will call a `Prime', or > sometimes `PR1ME', for obscure reasons such as the fact that it > exists, has two kinds of pointers. `Character pointers', or objects > of type (char *), are 48 bits wide. All other pointers, such as > (int *) and (double *), are 32 bits wide. I must admit, you have come up with a situation where the uncasted value NULL would be an incorrect parameter to a function that didn't have a prototype regardless of the definition of NULL. (If you missed the original posting, please don't flame about this. Ask someone to mail the original to you.) In the situation mentioned, the compiler could not know how wide to make the null pointer when passing it to the function. Indeed, even with NULL defined as (void *) 0, dpANS does not say that the size of a (void *) is the same as the size of any other pointer. However, if I were writing a C compiler, I would choose a size for all pointers equal to the size of the largest possible pointer. This would allow code that passed uncasted NULL to work correctly, provided NULL is a type as large as a pointer. This is not because dpANS says it should be so, but because so much code would break if it were not. Perhaps ANSI should add the restriction that all pointer types must be the same size in an effort to "codify common existing practice."
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8352 for SXJVK@ALASKA; Sat, 12 Mar 88 11:33 AST Received: by UWAVM (Mailer X1.25) id 5644; Sat, 12 Mar 88 12:33:27 PST Date: Fri, 11 Mar 88 11:32:41 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Richard A. O'Keefe" <ok@quintus.uucp> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: > The "packed" thing has a special meaning. I can't quote you from the > ANSI or ISO standards offhand, but the idea is that the compiler is > supposed to arrange that the packed structure takes up a minimal amount > of space (probably subject to some alignment restrictions). So in the > example I gave each boolean would take up one bit, and there would be > 1024 of them, the whole array taking up 128 bytes. The trouble is that a Pascal compiler is absolutely free to ignore 'packed' entirely. When you say var a: array [0.1023] of boolean; you have no guarantee at all that the compiler won't use 1024 "words". To quote the Berkeley Pascal manual page: "The keyword 'packed' is recognized but has no effect." You would be lucky to find a Pascal compiler which will pack array elements down to the bit level. Byte level, yes. The situation is better in C for two reasons. (1) At least you can say char a[1024]; and get nothing worse than byte packing. (2) You can write the bit-extraction operations as macros, and use them over and over again on different arrays. And of course there are those C compilers which have the "inline" processor, so that you can have get_bit(array, index) and put_bit(array, index, value) turned into your machine's instructions for bit access. (Yay, Sun!)
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8362 for SXJVK@ALASKA; Sat, 12 Mar 88 11:34 AST Received: by UWAVM (Mailer X1.25) id 5660; Sat, 12 Mar 88 12:33:35 PST Date: Fri, 11 Mar 88 17:53:52 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Pete Lyall <pete@wlbr.EATON.COM> Subject: Re: Don't use Scanf() Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes: >One real stupidity I've seen many, many times is the >over-use of printf. > >For example: > printf("Hello world!\n"); >Haven't you ever heard of puts???? > puts("Hello world!"); /* note the newline is appended */ Hmmmm. What about the case where 'printf()' is already used elsewhere in the program for argument substitution and formatting? Wouldn't this merely be just another subroutine (in RMA) call to the already included 'printf' function? If that is in fact the case, the I would suspect that the use of 'puts()' or 'fputs()' would actually add code, unless of course the 'puts()' or 'fputs()' are used internally by 'printf()'. I doubt that this is the case (my local unix.wizard says the 'puts' brothers aren't used by 'printf()', at least not here). Another item you might consider... if you're using a coco3 under level II, the minimum allocation segment is 8k under the memory management scheme. Os9 doesn't care if the program is 79 bytes or 7900 bytes, it is still going to allocate 8192 for the program segment (or some multiple thereof). Of course the counter arguments are that if you're byte-fighting to get within the next lower 8k notch, removal of *all* printf's may do you some good (approximately 3-5k). Also, you could save some disk space by removing *all* printf's. -- Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Internet: pete@wlbr.eaton.com UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: sizeof(char) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8371 for SXJVK@ALASKA; Sat, 12 Mar 88 11:35 AST Received: by UWAVM (Mailer X1.25) id 5676; Sat, 12 Mar 88 12:33:42 PST Date: Fri, 11 Mar 88 11:22:58 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Rahul Dhesi <dhesi@bsu-cs.uucp> Subject: Re: sizeof(char) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> Ray Butterworth: Other than allowing sloppily written code to continue to be written, I can see no reason whatsoever for requiring that sizeof(char) be 1. Doug Gwyn: Yes! I would appreciate it if you would send in a comment... Please don't do this. Code that conforms to K&R should not be called sloppy. From page 126: The size is given in unspecified units called "bytes," which are the same size as a char. Existing code will break if sizeof(char) != 1, and let's not blame the programmer for simply taking K&R at face value. And nowhere do I find K&R saying that byte == char == 1 unit is simply a compiler peculiarity and not a design assumption in the language. I have always believed, and I'm sure others share this reasonable belief, that the C programming language is defined by all of K&R, and not just by the brief semi-formal reference manual in the back of the book. I think "long char" is a better bet than changing the meaning of "char". Simply making "char" into two bytes will not allow new code, that needs long characters, to be usable with old compilers anyway. So there is no great need to continue to use the type "char" for long characters (and it could be deceptive to do so). With "long char" one would simply need a new set of str functions such as lstrcmp(), lstrcpy(), etc. So long as we need long chars, and also wish to permit short chars to be used for storage economy, we cannot avoid having two sets of string functions anyway. There is precedence for this sort of change in seek() going to lseek(). -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: syntactical convenience
[Non-Deliverable: User does not exist or has never logged on]
Reply-To: Info-C@BRL.ARPA
Received: From UWAVM(MAILER) by ALASKA with Jnet id 8379
for SXJVK@ALASKA; Sat, 12 Mar 88 11:35 AST
Received: by UWAVM (Mailer X1.25) id 5692; Sat, 12 Mar 88 12:33:49 PST
Date: Fri, 11 Mar 88 19:07:00 GMT
Reply-To: Info-C@BRL.ARPA
Sender: Info-C List <INFO-C@NDSUVM1>
From: Bear with me <kruger@whyvax.dec.COM>
Subject: syntactical convenience
Comments: To: info-c@BRL-SMOKE.arpa
To: Vic Kapella <SXJVK@ALASKA>
It's minor either way, but syntactically, it would be nice if you could
define a bunch of same-sized bitfields in one shot. For example:
struct
{
bit(1) x,y,z;
}
The current system does not convey the meaning as clearly, and is longer and
more obnoxious. Of course, it's only an inconvenience either way.
A more important addition, and a surprising lack in the standard, is the
preprocessor, which doesn't allow inserting preprocessing directives. Our
standards rep had no good arguments against adding the capability, which is
no harder to implement and breaks no programs. He simply said it was unlikely
to change at that point -- not very satisfying.
An example of what I am referring to is:
#define TBD #error
/* this code is not complete yet */
TBD
Of course, this is not the only use of this feature. It is even more surprising
that recursive definitions are not permitted -- the line has to be rescanned
anyway, and it's just as much work. Ah well....
dov
Disclaimer: Your mileage may vary. Void where prohibited. Weight is before
cooking. Digital is not to be held responsible for my madness.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: How not to write a loop [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8423 for SXJVK@ALASKA; Sat, 12 Mar 88 11:39 AST Received: by UWAVM (Mailer X1.25) id 5718; Sat, 12 Mar 88 12:38:31 PST Date: Fri, 11 Mar 88 06:21:22 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "James E. Prior" <jep@oink.uucp> Subject: Re: How not to write a loop Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <402@osupyr.UUCP> gae@osupyr.mast.ohio-state.edu.UUCP (Gerald Edgar) writes: >Lengthy discussion about loops such as: > >>>> float x; >>>> for (x = 0; x < 20; x += .5) printf("%f\n", x); ^ A decimal point would have been nice! > >How about this: > > float x; > for (x = 0; x < 19.75; x += .5) printf("%f\n", x); Yes, this will work reliably across many machines. However, your suggested solution causes another problem, obfuscation of the intended end value of the loop. I realize that 19.75 is half the increment less that twenty, but someone else might not have that much insight. You should right your code so that it is obvious how the magic number 19.75 is derived. Next step in obviousness: for (x=0; x<20.-.5/2.; x+=.5) ... but even now, it is not clear that the .5 in 20.-.5/2. is the same 5 as in x+=.5. The next step in obviousness is: #define STEP (.5) for (x=0; x<20.-STEP/2.; x+=STEP) ... This is quite handy for someone who never saw the <20 to begin with. With the way you wrote your solution, someone needing to change the step to .25 could inadvertently re-introduce reliability problems as follows: for (x=0; x<19.75; x+=.25) Another step to de-mystify 20. would be nice. I stronly recommend that you read Elements of Programming Style by P. J. Plaugher. You have reinforced one of the reasons I quit OSU. > Gerald A. Edgar TS1871@OHSTVMA.bitnet > Department of Mathematics gae@osupyr.UUCP > The Ohio State University ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae > Columbus, OH 43210 70715,1324 CompuServe -- Jim Prior {ihnp4|osu-cis}!n8emr!oink!jep jep@oink.UUCP
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Re: ANSI C idea: structure literals (and short constants) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8434 for SXJVK@ALASKA; Sat, 12 Mar 88 11:39 AST Received: by UWAVM (Mailer X1.25) id 5734; Sat, 12 Mar 88 12:38:38 PST Date: Fri, 11 Mar 88 04:10:06 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Dave Decot <decot@hpisod2.HP.COM> Subject: Re: Re: ANSI C idea: structure literals (and short constants) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > decot@hpisod2.HP.COM (Dave Decot) wrote: > >The problem of deciding what their type is solved for now (and possibly > >always) by stating in the standard that such syntax has no inherent type > >and must be cast or assigned to the desired type. > > They're not, but the point is that this is a totally new meaning for a > cast. Usually, a cast is a unary operator. Here, it's part of the > description, like a declaration. No, I intend that as far as the language is concerned, {...} is an expression that has a value, but there are only two operations defined on such values: assigning it to an lvalue using '=', or casting it to the appropriate aggregate type. This concept is somewhat the cousin of (void *), which generates pointers to values that are not usable directly; such pointers must be cast to some other pointer type before the object to which they point can be used. > To be specific: "(int)f" is an > expression that gets an int-ish value for the floating expression f. > It doesn't change f. Depends on what you mean by "f". This cast changes the bit pattern used for representing the value, surely. Pointer casts change the type of the value to which the expression points, which may give them a completely different abstract interpretation. > In your proposal, (struct a){...} and (struct b){...} imply different > values for {...}. What do you mean by "different values"? Of course they are different, they're of different types! If you mean "bit patterns", this is also true of your cast example above. Anyway, this same syntax represents the same type of typeless value that could be said is used for initializers; the value of these depends on the type of the variable which it initializes. > This is very inconsistent, even worse than the inconsistencies > between casting pointers and casting numerical types. It's more similar to casting numerical types than casting pointers, and I think it should be, in order to make these things look like constants. > Also, your (struct ..) cast will produce an lvalue, > which is also a big inconsistency. That is a misinterpretation, and I'm not sure how you arrived at it. Cast only produce rvalues; I assumed this would be obvious. Dave Decot hpda!decot
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: I forget what it was originally called. [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8466 for SXJVK@ALASKA; Sat, 12 Mar 88 11:43 AST Received: by UWAVM (Mailer X1.25) id 5770; Sat, 12 Mar 88 12:43:11 PST Date: Thu, 10 Mar 88 19:37:44 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@unmvax.unm.EDU From: "Michael I. Bushnell" <mike@turing.UNM.EDU> Subject: Re: I forget what it was originally called. Comments: To: info-c@brl-smoke.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3623@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes: >Which brings me to another question: How good are compilers these >day? Can they optimize just as well as a programmer (without >resorting to assembly, that is) or not? For example: Actually, optimizing C and FORTRAN compilers nowadays do better than programmers writing in assembly language. There goes another old misconception... >A) >temp = {expression} >a[temp] = 1; >b[temp] = 2; >c[temp] = 3; >B) >a[temp={expression}]=1; >b[temp]=2; >c[temp]=3; >C) >a[{expression}]=1; >b[{expression}]=2; >c[{expression}]=3; >A) is very readable. B) may or may not be slightly faster. Does >anyone know whether B) is typically faster than A)? Would it probably >generate the same code? C) is slower since {expression} is evaluated >three times, *unless* the compiler knows to evaluate it once and put >it in a register. Which may be about the same thing as what A) and B) >are doing, *except* in A) and B) it might will write the value into a >variable, which is slower than storing it in a register. Of course, >there's always: Actaully, I find (B) to be more readable, but that isn't what you were concerned about. B is just as fast as A on any optimizing compiler. C is also equal. However, if the expression has a potential side effect (like a function call), but you know there aren't any real side effects, then C can't be optimized and will prove a little slower. The Gnu C compiler will take (C) (assuming no potential side effects) and calculate expression once, and store it in a register. Pretty neat, huh? >D) >{ >register temp; >temp = {expression}; >. >. >. >} >But I find this harder to read, and furthermore, since C compilers can >ignore register declarations anyway, it might put it in as a normal >variable (just like A) ), but it will slow down because it's allocated >each time through the block of code. A compiler is allowed to ignore the decalaration, yes. But if you have a compiler that does, you are entitled to your money back. It is a little like the air IP link: no packets transmitted, but, they did say the protocol was nonreliable, right? It is a little harder to read, and usually won't get you much. If the compiler ignores the register spec, however, you won't have any problem with wasting time pushing and popping stack frames: simple peephole optimization will generate code equivalent to declaring it as a variable specific to the function as a whole. It is usually, I think, a little slower to declare it static, but that is heavily architecture dependent. Michael I. Bushnell mike@turing.unm.edu {ucbvax,gatech}!unmvax!turing!mike HASA -- "A" division
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8626 for SXJVK@ALASKA; Sat, 12 Mar 88 12:38 AST Received: by UWAVM (Mailer X1.25) id 5868; Sat, 12 Mar 88 13:38:07 PST Date: Sat, 12 Mar 88 08:15:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was nobody@sunybcs.uucp From: Fai Lau <ugfailau@sunybcs.uucp> Subject: Re: Don't use Scanf() Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes: >One real stupidity I've seen many, many times is the >over-use of printf. The printf functions have their uses, >and they do their job quite well, but please know what these >uses are!! C'mon!!! Is it really an issue? >For example: > printf("Hello world!\n"); >Haven't you ever heard of puts???? > puts("Hello world!"); /* note the newline is appended */ I can't imagine any reasonably competant C compiler not generating the almost same codes for both cases. >or > printf("hi"); >try fputs: > fputs("hi", stdout); /* no newline appended */ >What's that? Oh, now you have to include <stdio.h> so >you can get the proper declarations of all these functions anyway? >Poor baby! <stdio.h> should be included in mostly every program just so that when you do need it you have it around. It's not gonna give you a bigger or slower program. >And the ultimate stupidity: > printf("\n"); >Get a brain!!!!! You're using the function that can do complex >data formatted output to write one bleeping character!!!!! >Try > putchar('\n'); >If you include <stdio.h>, this will probably end up being a macro >that will write it out very fast. > >I have even seen: > sprintf(buf, "constant string"); >Hey, Mr. Power-Programmer, ever heard of strcpy???? Let's face it. The best way to give efficiency to a program is to write your own macro to handle file I/O and strings. Macros like strcpy are too general if you want to be picky. For example, if you want to print a string fast, you would write a routine that uses only putc with no format capacity and no error checking whatsoever, and forget about printf. Most of what you said are true. But if one has to be as picky as you suggest, then let's forget about stdio.h and strings.h and write everything from the ground up. Fai Lau SUNY at Buffalo (The Arctic Wonderland) UU: ..{rutgers,ames}!sunybcs!ugfailau BI: ugfailau@sunybcs INT: ugfailau@joey.cs.buffalo.EDU
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8854 for SXJVK@ALASKA; Sat, 12 Mar 88 14:12 AST Received: by UWAVM (Mailer X1.25) id 5927; Sat, 12 Mar 88 15:11:05 PST Date: Sat, 12 Mar 88 06:13:45 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@sigi.Colorado.EDU From: Frank Swarbrick <swarbric@tramp.Colorado.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> Hey, I've got no problem with having a 'bit' data type! I've been wondering why it doesn't exist already. It seems rather silly for boolean values to take up a whole byte. But I'm sure there is a good reason for this. (There is, isn't there? :-) Frank Swarbrick (and his cat) swarbric@tramp.UUCP swarbric@tramp.Colorado.EDU ..!{hao|nbires}!boulder!tramp!swarbric "Welcome back my friends to the show that never ends..."
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: cpp.c desperately needed [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9022 for SXJVK@ALASKA; Sat, 12 Mar 88 15:13 AST Received: by UWAVM (Mailer X1.25) id 5954; Sat, 12 Mar 88 16:13:21 PST Date: Sat, 12 Mar 88 11:04:41 ITA Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: CROSSNET mail via SMTP@CUNYVM From: MH9TS1BF%ICINECA.BITNET@CUNYVM.CUNY.EDU Subject: cpp.c desperately needed Comments: To: Info-C@BRL.ARPA To: Vic Kapella <SXJVK@ALASKA> From a desperate Fortranist, who put himself into troubles with his own hands. Dear C Community, Can anybody help me ? I have a lot of Fortran source code to be preprocessed by cpp (to handle machine dependencies etc) ( it seemed a good idea ... ) that I am porting from a Unix environment to Vax/VMS. The Digital Vax C compiler we have on our 8800 has a built-in cpp which cannot be used stand-alone ! i.e. I cannot avoid my poor Fortran programs to be fed into the subsequent passes of the C compiler ( hard work for the parser ..). Does anybody know if there is a cpp.c in the public domain, and how to reach it ? Thank you very much in advance to anybody who may help me. Furio Ercolessi, Intl. School for Advanced Studies, Trieste (Italy) MH9TS1BF@ICINECA.BITNET
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: The D Programming Language [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9296 for SXJVK@ALASKA; Sat, 12 Mar 88 16:52 AST Received: by UWAVM (Mailer X1.25) id 6030; Sat, 12 Mar 88 17:52:24 PST Date: Sat, 12 Mar 88 01:56:28 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Scott Daniels <daniels@teklds.TEK.COM> Subject: Re: The D Programming Language Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <587@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes: >Another example is string comparison. I use a string compare function >that returns the index of the first different character. I also >need the gt/lt/eq result. Fortunately, in this case it is easily >computed by recomparing the chars at the index. An alternative is the string comparison I normally use: cmpstr(s1,s2) 0: if equal >0: if s1 > s2 <0: if s1 < s2 abs(cmpstr(s1,s2)) is the number of chars compared: s1[ abs(cmpstr(s1,s2))-1 ] != s2[ abs(cmpstr(s1,s2))-1 ] if cmpstr did not return 0. Normally this function returns just about any information I need, and it is usually not very hard to make an extremely fast version in assembly. -Scott Daniels (daniels@teklds.TEK.COM)
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: The need for D-scussion (was Re: D Wishlist) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9347 for SXJVK@ALASKA; Sat, 12 Mar 88 17:04 AST Received: by UWAVM (Mailer X1.25) id 6069; Sat, 12 Mar 88 18:03:38 PST Date: Fri, 11 Mar 88 21:52:38 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: The need for D-scussion (was Re: D Wishlist) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > >Most of the things on this wishlist > >are incompatible but unimportant. (Not trivial, necessarily... > > I disagree that the items on the wishlist are unimportant. True > multidimensional arrays, better bit-level data support, a general > aggregate constructor mechanism, a better declaration syntax, and a > more general macro facility are *major* improvements... Au contraire. All they do is reduce the clumsiness of doing those things in C. While that is certainly useful, it is not going to sell people on a new and incompatible language. To do that, you need to show an order-of-magnitude improvement -- overall, not just in a few narrow areas. The things you have listed above are all just icing on the cake; they would *help* sell a language that was already a real contender for other reasons, but by themselves they aren't enough. (Analogously, C++ includes a number of useful, nice small improvements on C, but it would not be worth the trouble without its abstract data types and object-oriented type system.) > I'm sorry, but I just don't think C++ is so good that a *much* better > language is not possible... Oh, I agree it's *possible*; my point is that I don't know how to do it. A little better, yes, that I could do. Fifteen years of active interest in language design, and considerable private work on ideas about the ideal programming language, has given me more than enough thoughts on ways to improve C. But most of them would be, indeed, just icing. My conclusion, after a lot of thought, is that it doesn't matter how much icing you put on if there's no cake underneath. I don't know how to get the order-of-magnitude improvement needed to make lots of converts. That requires at least one quantum leap upward in the power of the language, not just incremental improvements and smoothing down the rough edges. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Re: ANSI C idea: structure literals (and short constants) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9355 for SXJVK@ALASKA; Sat, 12 Mar 88 17:05 AST Received: by UWAVM (Mailer X1.25) id 6084; Sat, 12 Mar 88 18:03:46 PST Date: Fri, 11 Mar 88 21:29:56 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: Re: ANSI C idea: structure literals (and short constants) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > I fail to see that the committee has drawn and observed "need" as > a clear boundary for what should be standardized. They have tried. Sometimes they've let their enthusiasm run away with them; these are reprehensible lapses that should not be considered an excuse to others to do likewise! > > [expletive deleted] Speaking as a user and an implementor, this is an > > abortion if there ever was one. > > Thank you for the feedback. But I wonder if you would be so kind as to > elaborate on this comment... *Why* introduce a new notion of something that doesn't have a type (actually it does have a type, some sort of curious mix of the types of the things inside it) when it is easy to invent a syntax (or borrow the one from the GNU compiler) that specifies the type?!? > > ... probably the GNU compiler's approach, which avoids this > > hideous botch entirely. > > I wonder if you would mind summarizing that approach for those of us who > don't have access to that compiler's source code. As I recall it -- I have not studied the GNU compiler closely yet -- the technique used is a sort of "cast with an initializer". > At any rate, your comment seems to imply that this is existing practice, > so I am having trouble seeing why this is a topic that should not be > standardized. "Existing practice" means that it has been out there for a while, that people other than its implementors have used it at some length, and that it has been used for more than just toy programs. That does not happen overnight, the GNU compiler is very new, and the draft standard is (theoretically) in virtually its final state. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Portable "asm" <-- portable? since when? [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9420 for SXJVK@ALASKA; Sat, 12 Mar 88 17:21 AST Received: by UWAVM (Mailer X1.25) id 6114; Sat, 12 Mar 88 18:21:23 PST Date: Fri, 11 Mar 88 22:10:17 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: Portable "asm" <-- portable? since when? Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > If the #asm has to come back, let's just revert to the old K&R style: > > #asm > ; assembly goes here > #endasm What "K&R" style?!? There is no "asm" or "#asm" in K&R. (It is mentioned once, in the Reference Manual, as a keyword reserved by some compilers.) > I *would* like to see the "interrupt" keyword added to ANSI C (or D). > For a language to claim to be a system programming language and not > provide the capability to write interrupt routines is a major oversight > (although K&R seemed to do fine without it :-)... This is a curious statement, given that all Unix's interrupt routines are written in C. There is a little bit of assembly-language glue involved on most machines, but all that does is smooth over differences in calling conventions. If you are willing to live with the idea that you can't just plop a function's address into an interrupt vector, but some small amount of mediation is required, no language change is necessary. It's not as if what you were doing was portable and could usefully be made standard across different implementations. (If you think it is, consider for example that my machine's interrupt vectors are structures, not just single pointers, so just filling in a function pointer is not enough.) > Also, I would like to see named access to specific CPU registers included > in ANSI C, e.g. AX, BX, R0, R1, etc... Subject to certain rules about naming conventions, ANSI implementations are free to provide whatever machine-dependent magic cookies they want. So are non-ANSI implementations, for that matter. Complain to your vendor if he doesn't do what you want. Actually *specifying* what should be done is so hopelessly machine-dependent and implementation-dependent that no standards committee in its right mind would put it into a standard. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pointers to functions [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9440 for SXJVK@ALASKA; Sat, 12 Mar 88 17:25 AST Received: by UWAVM (Mailer X1.25) id 6131; Sat, 12 Mar 88 18:25:24 PST Date: Fri, 11 Mar 88 22:15:28 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: Pointers to functions Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > The idea to have the same pointer arithmetic on labels as on pointers to > functions seems to be a good one (in my opinion)... X3J11 supports this view entirely, since neither is allowed to participate in arithmetic in any way. This is a practical necessity; on some machines, pointers to functions are very strange "magic cookies" whose contents don't even slightly resemble pointers to data, and pointers to random spots in the code basically don't exist. > ... Secondly this would allow additional entry points into functions. Some machines cannot do this, period. It's also not at all clear that it is particularly useful, which is probably why nobody ever did anything with the "entry" keyword. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: ANSI C idea: structure literals (and short constants) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9636 for SXJVK@ALASKA; Sat, 12 Mar 88 19:31 AST Received: by UWAVM (Mailer X1.25) id 6173; Sat, 12 Mar 88 20:31:21 PST Date: Sat, 12 Mar 88 07:06:28 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Peter da Silva <peter@sugar.uucp> Subject: Re: ANSI C idea: structure literals (and short constants) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article ... henry@utzoo.uucp (Henry Spencer) writes: > foo = { ... }; > It is agreed that the latter form is more convenient. But we were talking > about *needs*, in the context of an existing language, not about a wishlist > for a new language. I implemented just this construct in a copy of the Small-C compiler I was playing around with about 6 years ago. I had just picked up a copy of the BCPL book and wanted to play with the concepts. I also implemented this: foo = { for(i = 0; i < 10; i++) if(...) break; i; }; in analogy to the BCPL: foo = $( ... resultis i; $) Back to the subject.. the problem of what type an aggregate constant is is a lot easier in Small-C. It's only got 4 types. But if you need prior art to consider this, well here's two examples (half-smiley). > way to do it is probably the GNU compiler's approach, which avoids this > hideous botch entirely. What's the GNU compiler's approach? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Header problems [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9841 for SXJVK@ALASKA; Sat, 12 Mar 88 21:05 AST Received: by UWAVM (Mailer X1.25) id 6269; Sat, 12 Mar 88 22:04:47 PST Date: Thu, 10 Mar 88 16:07:15 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: SIEMON <mls@whutt.uucp> Subject: Re: Header problems Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <3416@chinet.UUCP>, dag@chinet.UUCP (Daniel A. Glasser) writes: > > ... > In other words, though proper usage uses casts on NULL, common usage > does not. > > Daniel A. Glasser dag@chinet.UUCP Yes; you should realize that you were flamed so much because people were feeling deeply guilty about their own failure to practice what they preach. Here was a perfect scapegoat -- someone who could be read as not understanding what to do and could be lectured about it by those who REALLY intend to do it right, but somehow don't quite get around to it. (Please no flames from those who really do go to the effort to do it right -- you are a rare breed; for most of us, it is just too damned easy to "code" and too damned hard to think and to rewrite. Michael Siemon contracted to AT&T Bell Laboratories (these are my opinions, not theirs) ihnp4!mhuxu!mls
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Constant overflow [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0287 for SXJVK@ALASKA; Sat, 12 Mar 88 23:22 AST Received: by UWAVM (Mailer X1.25) id 6326; Sun, 13 Mar 88 00:21:41 PST Date: Sun, 13 Mar 88 05:24:50 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@husc6.harvard.EDU From: Kaufer - Lopez - Pratap <steve@endor.harvard.EDU> Subject: Re: Constant overflow Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> Here is the output from the Saber-C programming environment: (Running on SUN & VAX, Ultrix/Unix): Saber-C - Version 1.2c Copyright (C) 1986, 1987, 1988 by Saber Software, Inc. Attaching: /lib/libc.a 1 -> load("foo.c"); Loading: foo.c ---------------- "foo.c", line 2: Integer too large (Warning #220) 1: /* Sample overflow */ 2: long i = 9876543210L; ^ 3: Integer constant (9876543210) exceeds maximum unsigned long (4294967295). Options: continue/suppress/terse/quit/abort/edit/reload [c] ? Stephen Kaufer Saber Software, Inc. saber@harvard.harvard.edu 30 JFK Street, Cambridge, MA. 02138 (617) 876-7636
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Re: Constant overflow [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0359 for SXJVK@ALASKA; Sat, 12 Mar 88 23:48 AST Received: by UWAVM (Mailer X1.25) id 6413; Sun, 13 Mar 88 00:47:52 PST Date: Fri, 11 Mar 88 11:47:41 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Alan_Rooks_sps <alan@bk.dk> Subject: Re: Re: Constant overflow Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <2550059@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >It's hard to do this right unless you do some clever comparison >just before multiplying by 10 (or 8 or 16 or 2). A proven (and very simple) way to do this right was given by J. R. Parker in "A General Character to Integer Conversion Method", Software - Practice and Experience, Vol 15(8) (August '85), pp. 761-766. Alan Rooks - Bruel & Kjaer Copenhagen - ...!mcvax!bk!alan or ...!diku!bk!alan
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0369 for SXJVK@ALASKA; Sat, 12 Mar 88 23:49 AST Received: by UWAVM (Mailer X1.25) id 6429; Sun, 13 Mar 88 00:49:35 PST Date: Fri, 11 Mar 88 04:19:24 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Andrea Humenick <cs2531ar@charon.unm.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <4766@sigi.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >Or does the "packed" thing in Pascal have some special meaning? I never could >figure out what the difference between a packed array and a regular array was. I'm a new poster, so I'm sorry if this is improper. In my current pascal class my teacher explained packed and not packed as this packed: an array that can read in ' ' not packed: an array that can only be read in character by character thank you.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Long Chars [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0538 for SXJVK@ALASKA; Sun, 13 Mar 88 01:06 AST Received: by UWAVM (Mailer X1.25) id 6525; Sun, 13 Mar 88 02:05:53 PST Date: Sat, 12 Mar 88 22:11:00 EST Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU Subject: Long Chars Comments: To: info-c@BRL.ARPA To: Vic Kapella <SXJVK@ALASKA> (This discussion is looking for a good pun... like "lawn chairs"? No... I said GOOD pun.) The "short char vs char" problem can't be solved very easily. Why not a "long char". That wouldn't break much code now, would it? Now I'm not demanding that it goes into v1.0 of the standard but maybe we can look at this for the next "congress". For now, if you want to make some progress, try to get one of the biggies (like MS) to add it as an extension. You can tell them that they'll hit on the "multi-nation/multi-language vendor market" with it. Of course, in my programming I don't have a use for it, but if you do, try typedef short LONG_CHAR; or typedef char LONG_CHAR[2]; (Hmmm... I like the former) and then you can implement a lstrcmp() and a lstrcpy() and an assortment of routines like that. Then when you're done, those can be re-used in all your programs. When it get's suggested to ANSI C II (or whatever it'll be called) you'll be there to warn us about implementation difficulties and ideas. And when it gets passed you can do a search-and-replace from "LONG_CHAR" to "long char" "And there was much rejoicing" -- Monty Python Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlimonce@drew.BITNET Disclaimer: These are my views, not my employer or Drew Univesity --------------------------------------------------------------------------
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0551 for SXJVK@ALASKA; Sun, 13 Mar 88 01:10 AST Received: by UWAVM (Mailer X1.25) id 6542; Sun, 13 Mar 88 02:10:14 PST Date: Sat, 12 Mar 88 21:53:00 EST Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU Subject: Re: Pascal --> C question Comments: To: info-c@BRL.ARPA To: Vic Kapella <SXJVK@ALASKA> On 12-MAR-1988 09:06 ok@quintus.uucp wrote: >You would be lucky to find a Pascal compiler which will pack array >elements down to the bit level. Byte level, yes. Actually, the only version of Pascal that I will use is VaxPascal under VMS (what's that?) because it has some execelent optimizations. First of all, it does wonders with PACKED arrays and variables. Unpacked BOOLEANs take up the same as a INTEGER (4 bytes/1 word) so that you have maximum speed but PACKED ARRAY [xx..yy] OF BOOLEAN is packed to the bit-level. VaxPascal will also do optimizations like not recalculating x+1 each time it's used. (This next one addresses anyother info-c debate) It will even attempt to make functions and procedures inline if it can determine that it is not recursive (or any other problems) and if it will save memory/time. Best of all, all of the optimizations and run-time checking can be turned on or off easily. I do super-fast compiles that generate slow, bulky code until I know it all works. Then I do PASCAL/OPTIMIZE=ALL/CHECK=NONE and let it take all the time it wants to make my final product. Why can't popular C compilers do that? (Whoa! Maybe I should ask, "Which ones do that NOW?" ?) Actually, from what I read, we are on the brink of seeing more and more optimizers on the market very soon. All that grad-school work on writing faster compilers is finally feasible now that we all have our wiz-bang machines based on 386s and '030s (yeah right! Lemme win the lottery first!) Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlimonce@drew.BITNET Disclaimer: These are my views, not my employer or Drew Univesity --------------------------------------------------------------------------
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: powerC review [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0582 for SXJVK@ALASKA; Sun, 13 Mar 88 01:33 AST Received: by UWAVM (Mailer X1.25) id 6586; Sun, 13 Mar 88 02:30:47 PST Date: Sat, 12 Mar 88 11:53:06 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Stanley M. Sutton" <sms@sugar.uucp> Subject: powerC review Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> I purchased power C about a month ago. For the most part, I like it a lot. The manual that comes with the compiler is worth more than the $20 they are asking for the compiler. Any of you that used Mix C on CP/M or MSDOS will be familar with the book. It's been expanded for ANSI C, and a MSC 4.0 /TC 1.0 compatable library. It has a relatively fast compiler/linker. I've used quick C and Turbo C at work on similar programs (Not identical, so it is not really benchmarking) and they all seem to be within 10% of each other. However, there are some problems. I can't compile microEMACS with power C. It apparently runs out of heap in the optimizing phase. Mix Software says they are working on changing the compiler to use far heap instead of near heap, but it is a complicated conversion, so don't expect it before 3rd quarter 88. It does not always use the environment strings properly to control the compilier/linker. An example is SET PCOPTION=/O\C:\C\MIX\ to put objects into a libary. Instead of overiding the object location if it is respecified on the compilier line, the line specification is appended to options string specification. This is not what the manual says it does, but is useful if you are maintaining a multi-level directory of source, and want to maintain the same structure with object. Also, most of the environment problems can be solved by using DOS 3.3 APPEND commands. Just recently I've run into a problem with bit fields in a structure not working correctly. It works fine for simple cases (i.e., if I simplify the problem, it goes away). However, in the Dr. Dobbs journals "C Chest and Other Treasures" routine getargs, they don't work. I'm planning on shipping off a disk this weekend to see what Mix Software thinks of it. To summarize, Good points: inexpensive good manual good user support good libary functions Bad points: bit fields don't always work some environment string problems large programs may not compile One additional comment. The manual for the Power Ctrace source debugger was shipped to the printer at the beginning of March, so they expect to begin selling and shipping around the first of April. I've used the Mix Ctrace, and liked it as a multi-windowed source level debugger. I expect Power Ctrace to be similar.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Constant overflow [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0614 for SXJVK@ALASKA; Sun, 13 Mar 88 01:38 AST Received: by UWAVM (Mailer X1.25) id 6629; Sun, 13 Mar 88 02:38:29 PST Date: Sat, 12 Mar 88 23:52:23 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Rafael Llave <llave@phoenix.Princeton.EDU> Subject: Re: Constant overflow Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <2550059@hpisod2.HP.COM>, decot@hpisod2.HP.COM (Dave Decot) writes: > Try this one on your favorite C compiler. So far, every one I've tried > (including lint) has had no complaint: > > long i = 9876543210L; > > (The problem, of course, is that that number doesn't fit in 32 bits...) Integer arithmetic is not supposed to overflow and all integers are supposed to be taken ss defined modulo a power of 2 which is implementation dependent. I have seen some compilers that at compile time gave you warnings - God bless them -- but to ensure portability of programs that have to handle occasionally large numbers , I have always included some defensive lines.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Pascal --> C question [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0681 for SXJVK@ALASKA; Sun, 13 Mar 88 02:00 AST Received: by UWAVM (Mailer X1.25) id 6710; Sun, 13 Mar 88 02:59:06 PST Date: Sun, 13 Mar 88 00:20:21 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Rafael Llave <llave@phoenix.Princeton.EDU> Subject: Re: Pascal --> C question Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> # # Except that the useful ones are never that easy. One of my favorites: # bitstring: packed array[0..1023] of boolean; # In C you have to do bit-fiddling by hand to get the same effect. # Many Pascal compilers ignore packed
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Why he won't use ANSI C [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 0689 for SXJVK@ALASKA; Sun, 13 Mar 88 02:00 AST Received: by UWAVM (Mailer X1.25) id 6727; Sun, 13 Mar 88 02:59:13 PST Date: Sun, 13 Mar 88 00:01:49 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Rafael Llave <llave@phoenix.Princeton.EDU> Subject: Re: Why he won't use ANSI C Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> # Well, what about the fact that: # # typedef int (*PFI)(); # # main() # { # PFI fp = main; # } # # gives: # fp == *fp == **fp == ***fp ? A) It does not. B) If it did , it would not be more serious than for( i=0;;) generating an endless loop.
jejones@mcrware.UUCP (James Jones) (03/13/88)
In article <12319@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes: > Subject: Re: Why NULL is 0 > > [Non-Deliverable: User does not exist or has never logged on] Huge quantities of messages that say "Undelivered mail" have started appearing in comp.lang.c. I can't help but wonder whether something somewhere (at CUNY? on BITNET?) is broken. Anyone have any theories? James Jones
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: nasty evil pointers [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1086 for SXJVK@ALASKA; Sun, 13 Mar 88 05:42 AST Received: by UWAVM (Mailer X1.25) id 7016; Sun, 13 Mar 88 06:41:42 PST Date: Sun, 13 Mar 88 05:37:25 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> Comments: Warning -- original Sender: tag was news@husc6.harvard.EDU From: Kaufer - Lopez - Pratap <steve@endor.harvard.EDU> Subject: Re: nasty evil pointers Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1529@devvax.JPL.NASA.GOV> jackm@devvax.JPL.NASA.GOV (Jack Morrison) writes: >In article <13100003@bucc2> brian@bucc2.UUCP writes: >> >>It would be nice if we could check every pointer as >>it was used... > >Funny how often I see things in this newsgroup that can be answered >with two words: > try Ada. > >Even funnier because I still prefer using C. > >-- Jack C. Morrison Jet Propulsion Laboratory --- Well, if you are still using C, you should really try an interpreter. The Saber-C interpreter, from Saber Software, Inc., provides full run-time checking of pointers (and many other nasty C things....) More info can be obtained by e-mail or phone... Stephen Kaufer Saber Software, Inc. saber@harvard.harvard.edu 30 JFK Street, Cambridge, MA. 02138 (617) 876-7636 --- Note: As the address indicates, I work for Saber. Having said that, comments about biased reporting to /dev/null!
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1066 for SXJVK@ALASKA; Sun, 13 Mar 88 05:36 AST Received: by UWAVM (Mailer X1.25) id 7001; Sun, 13 Mar 88 06:35:20 PST Date: Sat, 12 Mar 88 14:00:25 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Johan Vromans <jv@mhres.mh.nl> Subject: Re: Don't use Scanf() Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes: >One real stupidity I've seen many, many times is the >over-use of printf. The printf functions have their uses, >and they do their job quite well, but please know what these >uses are!! > > [examples of using puts, fput, putc instead of printf] > >And the ultimate stupidity: > printf("\n"); >Get a brain!!!!! You're using the function that can do complex >data formatted output to write one bleeping character!!!!! >Try > putchar('\n'); >If you include <stdio.h>, this will probably end up being a macro .. If you don't you will likely end up with a missing routine ... >that will write it out very fast. Yes. But it does not flush if the output is a terminal or line-buffered. >In general, if there's no format spec, don't use printf!!!!!! I partly agree. When you are short on space, and want to eliminate the use of "large" routines like printf, you are right. On the other hand, you suggest the use of four or five different routines (with all different calling sequences) instead of one simple and elegant "printf" routine. Printf *CAN* do complex formatting, but it *DOESN'T* do this if you don't have format strings. What remains is just the tiny overhead of testing whether there are formatting characters in the string... I dislike discussions in which the quality of the arguments is measured by the number of exclamation marks following each sentence. -- Johan Vromans | jv@mh.nl via European backbone Multihouse N.V., Gouda, the Netherlands | uucp: ..{uunet!}mcvax!mh.nl!jv "It is better to light a candle than to curse the darkness"
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Benchmark - (nf) [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1057 for SXJVK@ALASKA; Sun, 13 Mar 88 05:35 AST Received: by UWAVM (Mailer X1.25) id 6984; Sun, 13 Mar 88 06:34:24 PST Date: Fri, 11 Mar 88 14:03:00 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: LUC@SIEDAP Subject: Re: Benchmark - (nf) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> /* Written 2:26 am Mar 5, 1988 by news@brl-adm in siedap:comp.lang.c */ /* ---------- "Benchmark" ---------- */ This mail is intended for <kruger@16bits.dec.COM>, but I am posting it to the list because the gateway burped at his numeric address. -David- ----------------------------Original message---------------------------- Received: by WUVMD (Mailer X1.24) id 4182; Wed, 02 Mar 88 17:32:55 CST Date: Wed, 02 Mar 88 17:30:28 CST From: David Camp <C04661DC@WUVMD> Subject: Re: Dhrystones, anyone? To: "I've got 50nS memory. What did you say?" <kruger@16bits.dec.COM> In-Reply-To: Your message of Wed, 2 Mar 88 00:21:00 GMT >I am interested in the Dhrystone, Whetstone, and other popular benchmarks. >Please mail to me. If you want the collection, I will collect them and >forward. > >Thanks! >dov I typed this in from a magazine. I think it was "Computer Language", but I am not certain. I would appreciate your forwarding the collection. -David- *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | *----------------------------------------------------------------------* --------------------- FILE dhamp c --------------------- --------------------------- cut here -------------------------------- /* The dhampstone benchmark. Written by Jack purdum. */ /* version 1.0, August 1,1985 */ #include "stdio.h" #define BELL 7 /* ASCII BELL code */ #define FIB 24 #define TINY 100 #define MAXINT 179 #define LITTLE 1000 #define SMALL 9000 #define PRECISION .000001 #define FILENAME "zyxw.vut" #define NUMTEST 6 #ifndef ERR #define ERR -1 #endif struct { int cresult; int iresult; int cprsult; unsigned uresult; long lresult; double dresult; } results; main() { char buf1[TINY], buf2[TINY]; int i = 0; unsigned fib (); long square, sq (); double dmath, sroot (), dply (); printf("Start...%c\n\n",BELL); while (i < NUMTEST) { switch (i) { case (0): /* Character test */ results.cresult = stest (buf1,buf2); printf ("\ncresult = %d\n",results.cresult); break; case (1): /* Integer test */ results.iresult = intest (); printf ("\niresult = %d\n",results.iresult); break; case (2): /* Unsigned test */ results.uresult = fib (FIB); printf ("\nuresult = %u\n",results.uresult); break; case (3): /* Long test */ square = 0L; results.lresult = sq (square); square = sq (results.lresult); /* Check the value */ printf ("\nlresult = %ld",results.lresult); printf ("\n square = %ld\n",square); break; case (4): /* Double test */ results.dresult = sroot ((double) results.lresult); printf ("\ndresult = %f\n",results.dresult); dmath = dply (results.dresult); printf (" dmath = %f\n",dmath); break; case (5): /* Disk copy */ results.cprsult = mcopy (); printf ("\b copy = %d",results.cprsult); break; default: break; } ++i; } /* End while i */ printf ("\n\n...End%c",BELL); } long sq (big) /* Function to square a number by iteration */ long big; { int i; static long j = 1L; if (!big) for (i = 0; i < SMALL; ++i) { big += j; j += 2; } else for (i = 0; i < SMALL; ++i) { j -= 2; big -= j; } return (big); } double sroot (num) /* Find square root of number */ double num; { double temp1, temp2, abs (); temp2 = num / 2.0; temp1 = num; while (temp1 > PRECISION * temp2) { temp1 = (num / temp2) - temp2; temp1 = abs (temp1); temp2 = ((num / temp2) + temp2) / 2.0; } return (temp2); } double abs (x) /* Absolute value of a double */ double x; { return (x < 0 ? -x : x); } double dply (x) /* Exercise some doubles */ double x; { int i = TINY; double y; while (i--) { y = x * x * x * x * x * x * x; y = y / x / x / x / x / x / x; y = y + x + x + x + x + x + x; y = y - x - x - x - x - x - x; } return (y); } unsigned fib (x) /* Common Fibonacci function */ int x; { if (x > 2) return (fib (x-1) + fib (x-2)); else return (1); } int stest (b1,b2) /* String test using strcpy() and strcmp() */ char *b1, *b2; { int i,j; void mstrcpy (); for (i = 0, j = 0; i < SMALL; ++i) { mstrcpy (b1, "0123456789abcdef"); mstrcpy (b2, "0123456789abcdee"); /* Note it's a different string. */ j += mstrcmp (b1,b2); } return (j); } int mstrcmp (c,d) /* External string compare */ char *c, *d; { while (*c == *d) { if (!*c) return (0); ++c; ++d; } return (*c - *d); } void mstrcpy (c,d) /* External string copy */ char *c, *d; { while (*c++ = *d++) ; } int mcopy () /* Disk copy. Test assumes file doesn't exist */ { FILE *fp, *fopen (); char buf[TINY]; int i, j; mstrcpy (buf, "Disk I/O test"); if ((fp = fopen(FILENAME,"w")) == NULL) { printf ("Cannot open file"); exit (ERR); } i = 0; while (++i < LITTLE) for (j = 0; buf[j]; ++j) putc (buf[j], fp); fclose (fp); return (i); } int intest () /* Square an integer by iteration */ { int i, j, k, sum; for (i = 0; i < LITTLE; ++i) { sum = 0; for (j = 0, k = 1; j < MAXINT; ++j) { sum += k; k += 2; } } return (sum); }
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: MSC 4.0 Internal Compiler Error
[Non-Deliverable: User does not exist or has never logged on]
Reply-To: Info-C@BRL.ARPA
Received: From UWAVM(MAILER) by ALASKA with Jnet id 1118
for SXJVK@ALASKA; Sun, 13 Mar 88 05:54 AST
Received: by UWAVM (Mailer X1.25) id 7033; Sun, 13 Mar 88 06:53:33 PST
Date: Thu, 10 Mar 88 16:15:20 GMT
Reply-To: Info-C@BRL.ARPA
Sender: Info-C List <INFO-C@NDSUVM1>
From: Markku Savela <msa@clinet.fi>
Subject: MSC 4.0 Internal Compiler Error
Comments: To: info-c@BRL-SMOKE.arpa
To: Vic Kapella <SXJVK@ALASKA>
I got the following message from my Microsoft C Compiler (4.0)
while trying to compile one of my programs (using LARGE MODEL and
MS-DOS):
thisbug.C(8) : fatal error 1: Internal Compiler Error
(compiler file 'regMD.c', line 272)
Contact Microsoft Technical Support
Here is a much reduced (and stupid) program fragment which still
produces the same result:
int x,y,i;
struct MemCell {int Ntype; struct MemCell *Mem} MemLoc[1000];
void grokit()
{
while (i++ < 10) MemLoc[y].Mem[i] = MemLoc[x];
}
It seems that the following things are required
- LARGE MODEL (compiles using SMALL)
- loop (while, for,...)
- Mem is not the first field of the structure
- and of course this double indexing...
I do not expect any help on this. I surely can code around the
problem. I'm just reporting a bug for anyone interested (whether
this reaches Microsoft or not, I don't care). (Perphaps Microsoft
should have a mailbox in the net for this kind of things -- this
is much easier than going through the regular routes...). And,
perhaps this doesn't occur in MSC 5.0 or 5.1 any more...
--
-- Markku Savela, msa@clinet.fi
-- (Note: I cannot send mail -- do not expect mail replys)
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Why NULL is 0 [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1135 for SXJVK@ALASKA; Sun, 13 Mar 88 06:01 AST Received: by UWAVM (Mailer X1.25) id 7048; Sun, 13 Mar 88 07:01:00 PST Date: Sat, 12 Mar 88 19:07:25 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: "Stephen J. Friedl" <friedl@vsi.uucp> Subject: Re: Why NULL is 0 Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> In article <124@polygen.UUCP>, pablo@polygen.uucp (Pablo Halpern) writes: > However, if I were writing a C compiler, I would choose a size for all > pointers equal to the size of the largest possible pointer. This would > allow code that passed uncasted NULL to work correctly, provided NULL > is a type as large as a pointer. This is not because dpANS says it > should be so, but because so much code would break if it were not. > Perhaps ANSI should add the restriction that all pointer types must be > the same size in an effort to "codify common existing practice." I think this is naive. Presumably, the large "common" pointer format would pass around the machine OK but it still must be converted to the machine's native pointer types to actually use -- how efficiently will this be done? This might be like the 80x86 huge pointer calculations or the old promote-float-to-double rules -- they makes life a little easier for the (lazy?) programmer at the larger expense in time and compiler complexity Perhaps more reasonable is to promote all pointers to the same large width while passing them on the stack and convert them back on the other end: this would fix the alignment issues but would still slow things down. I don't favor this approach but I bring it up in the spirit of this discussion. The obvious answer is to be very rigorous about casting your pointers and knowing when to do so. This is a bummer for the beginners but we all had to go through it unless we develop on a VAX :-). -- Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA *Hi Mom* CSNet: friedl%vsi.uucp@kent.edu ARPA: friedl%vsi.uucp@uunet.uu.net uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: ANSI C & Fortran 8x - Expand cpp to partially support [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1162 for SXJVK@ALASKA; Sun, 13 Mar 88 06:14 AST Received: by UWAVM (Mailer X1.25) id 7065; Sun, 13 Mar 88 07:13:34 PST Date: Sat, 12 Mar 88 17:41:08 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Alan J Rosenthal <flaps@dgp.toronto.EDU> Subject: Re: ANSI C & Fortran 8x - Expand cpp to partially support generalized precision Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> [In editing David Hough's article below, I have taken representative paragraphs. -ajr] In article <44981@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes: >Comment #26, Section 3.8.8 and 2.2.4.2: predefine generalized precision macros >... >__int__(p) is evaluated to the name of the smallest signed int type >that contains all the signed p-digit integers, i. e. the interval >[-(10**p)+1,10**p-1]. >... Useable but not very useful. Also not sufficiently well defined. What is its value for p > log10(LONG_MAX)? Also, your macros are very different from all other preprocessing macros in that they don't simply substitute to a string (with possible replacements from the arguments). Also also, nowhere else does the preprocessor know about names of types. >__INTEGER__(p) is evaluated to the Fortran name of the type corresponding >to __int__(p), or to INTEGER if no Fortran compiler is supported. >... Since no Fortran compiler is supported by the ANSI C standard, you can just say "INTEGER". The C standard does not mandate a separate preprocessor, nor should it. That would be the domain of a Preprocessor Standard. It seems like that is what you are proposing. Perhaps you should write one, or get someone else to write one. ajr -- If you had eternal life, would you be able to say all the integers?
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: Don't use Scanf() [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1172 for SXJVK@ALASKA; Sun, 13 Mar 88 06:14 AST Received: by UWAVM (Mailer X1.25) id 7080; Sun, 13 Mar 88 07:14:16 PST Date: Sun, 13 Mar 88 00:58:41 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: Don't use Scanf() Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > For example, if you want to print a string fast, you would write > a routine that uses only putc... !!NO!! If you want to print a string fast, you use fputs and insist that your supplier implements it properly. Putc has to do things like buffer- overflow checking on every character; a fast implementation of fputs can inspect the buffer *once*, note that there is room for N more characters, copy N characters at high speed, and then update counts and so forth *once*. This is a major efficiency win over putc if you are doing it a lot. Unfortunately, not all implementors make the effort to make stdio fast. In general, System V stdios are fast and 4BSD ones are not. (There are exceptions to this, both ways, and I believe the 4BSD one is going to be improved.) -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: volatiles/consts inside structs in dpANS C [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1209 for SXJVK@ALASKA; Sun, 13 Mar 88 06:23 AST Received: by UWAVM (Mailer X1.25) id 7098; Sun, 13 Mar 88 07:23:22 PST Date: Sun, 13 Mar 88 00:54:11 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: volatiles/consts inside structs in dpANS C Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> As I recall (my copy isn't handy), the latest draft says that const, volatile, etc. inside a struct sort of pop to the surface when you attempt something like an assignment. So assigning to a struct with a const member is illegal. Personally, I think such "buried qualifiers" should simply be illegal, since they are useless... -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/13/88)
Subject: Re: syntactical convenience [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 1230 for SXJVK@ALASKA; Sun, 13 Mar 88 06:29 AST Received: by UWAVM (Mailer X1.25) id 7118; Sun, 13 Mar 88 07:29:11 PST Date: Sun, 13 Mar 88 00:55:15 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List <INFO-C@NDSUVM1> From: Henry Spencer <henry@utzoo.uucp> Subject: Re: syntactical convenience Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella <SXJVK@ALASKA> > A more important addition, and a surprising lack in the standard, is the > preprocessor, which doesn't allow inserting preprocessing directives. Our > standards rep had no good arguments against adding the capability, which is > no harder to implement... Not all implementors would agree. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
schmidt@BONNIE.ICS.UCI.EDU (Douglas C. Schmidt) (03/14/88)
Why doesn't someone do something about all the blasted "undelivered mail messages emanating from ALASKA.BIT? This is cluttering up the bboard! dcs
qwerty@drutx.ATT.COM (Brian Jones) (03/14/88)
About 50% of the traffic at our site looks like the following message: Also, a number of these are repeating, some multiple times. Someone's software is broken somewhere... *In article <12345@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes: * Subject: Re: Header problems * * [Non-Deliverable: User does not exist or has never logged on] * * Reply-To: Info-C@BRL.ARPA * * Received: From UWAVM(MAILER) by ALASKA with Jnet id 9841 * for SXJVK@ALASKA; Sat, 12 Mar 88 21:05 AST * Received: by UWAVM (Mailer X1.25) id 6269; Sat, 12 Mar 88 22:04:47 PST * Date: Thu, 10 Mar 88 16:07:15 GMT * Reply-To: Info-C@BRL.ARPA * Sender: Info-C List <INFO-C@NDSUVM1> * From: SIEMON <mls@whutt.uucp> * Subject: Re: Header problems * Comments: To: info-c@BRL-SMOKE.arpa * To: Vic Kapella <SXJVK@ALASKA> * * In article <3416@chinet.UUCP>, dag@chinet.UUCP (Daniel A. Glasser) writes: DELETED TEXT * Michael Siemon * contracted to AT&T Bell Laboratories * (these are my opinions, not theirs) * ihnp4!mhuxu!mls -- Brian Jones aka {ihnp4,allegra}!{drutx}!qwerty @ AT&T-IS, Denver
richardh@killer.UUCP (Richard Hargrove) (03/15/88)
--- I think we've punted ALASKA. richardh --------
twb@hoqax.UUCP (BEATTIE) (03/15/88)
What is all this "Undelivered mail" doing here?
djones@megatest.UUCP (Dave Jones) (03/16/88)
in article <12311@brl-adm.ARPA>, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU says: > > Subject: Re: Why NULL is 0 > > [Non-Deliverable: User does not exist or has never logged on] > > Reply-To: Info-C@BRL.ARPA > > Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001 > for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST > Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST > Date: Fri, 11 Mar 88 21:56:46 GMT > Reply-To: Info-C@BRL.ARPA > Sender: Info-C List <INFO-C@NDSUVM1> > From: Doug Gwyn <gwyn@brl-smoke.arpa> > Subject: Re: Why NULL is 0 > Comments: To: info-c@brl-smoke.arpa > To: Vic Kapella <SXJVK@ALASKA> ... > I'm getting dozens and dozens of these returned-mail postings to comp.lang.c. They are all postings that have appeared under their original headings. Anybody know what's going on? Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA Lines to make this posting as long as the original, so the mailer will accept it.
be@dde.uucp (Bjorn Engsig) (03/16/88)
In a lot of articles, MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU writes something like: > [Non-Deliverable: User does not exist or has never logged on] > Reply-To: Info-C@BRL.ARPA > Received: From UWAVM(MAILER) by ALASKA with Jnet id 8323 > for SXJVK@ALASKA; Sat, 12 Mar 88 11:30 AST > To: Vic Kapella <SXJVK@ALASKA> Aren't there any better way to do this. It's guite boring to 'n' through all these 'undelivered mail's, and one might even miss something of interest. -- Bjorn Engsig, E-mail: ..!uunet!mcvax!diku!dde!be or be@dde.uucp -- Hofstadters Law: It always take longer than you expect, even if you take into account Hofstadters Law.
rsalz@bbn.com (Rich Salz) (03/17/88)
Dave Jones, djones@megatest.UUCP (Dave Jones) asks why comp.lang.c is getting filled up with messages like: > > Subject: Re: Why NULL is 0 > > [Non-Deliverable: User does not exist or has never logged on] > > Reply-To: Info-C@BRL.ARPA > > Received: From UWAVM(MAILER) by ALASKA with Jnet id 8001 > for SXJVK@ALASKA; Sat, 12 Mar 88 10:50 AST > Received: by UWAVM (Mailer X1.25) id 5338; Sat, 12 Mar 88 11:49:55 PST > Date: Fri, 11 Mar 88 21:56:46 GMT > Reply-To: Info-C@BRL.ARPA > Sender: Info-C List <INFO-C@NDSUVM1> > From: Doug Gwyn <gwyn@brl-smoke.arpa> > Subject: Re: Why NULL is 0 > Comments: To: info-c@brl-smoke.arpa > To: Vic Kapella <SXJVK@ALASKA> The answer is that the comp.lang.c newsgroup is gatewayed into an Internet mailing list, info-C. One of the recipients is at BITNET site. And when BITNET mail has problems it tends to do, unh, things that are anti-social to Usenet (if not the rest of the Internet world :-). The person in charge, a postmaster at one of the BITNET sites, found out and shut things off within a day or two, but that was still too late to prevent about 75 of these messages from costing Usenet thousands of dollars to transmit. Yet another argument against unmoderated bidirectional gateways. The most interesting question, tho, still remains unanswered: if the user does not exist, or has never logged in, how did the subscribe to the INFO-C mailing list? Speculations, flames, and follow-ups should probably be sent to me. At any rate, keep them out of the comp.lang.c newsgroup. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU (03/23/88)
[Non-Deliverable: User does not exist or has never logged on] Received: From UOGUELPH(SOSLIZ) by ALASKA with Jnet id 7625 for OP@ALASKA; Wed, 23 Mar 88 06:13 AST Date: 23 March 1988, 10:01:43 EST From: SOSLIZ at UOGUELPH To: OP at ALASKA Hi. You don't know me, but because you're the operator, I'm hoping you have access to the information I need. Cathy Hirt is a friend of mine, and I am trying to reach her boss, Kurt. I don't know what his last name is, all I know is that he works for the U. of A. Computer Center. Do you know him, and more importantly, can you provide me with his USERID (and node)? Thanks in advance. Elizabeth Reemeyer, Computing Services, University of Guelph.