hannum@haydn.psu.edu (Charles Hannum) (07/01/90)
of some of the current flame wars on comp.lang.c ... NULL pointers ------------- How should one deal with the various contexts of NULL pointers in C, and casting them properly, in order to write portable C programs? My solution: Write "NULL", except as arguments to vararg functions, where I put an explicit cast. (Actually, when I think about it, I can't ever remember passing NULL to a vararg function, except for execl(). Just how common is this?) How to shut up lint ------------------- How do you keep lint from complaining about things like the arguments to malloc()? My solution: Don't use lint; it's ancient and brain-dead. Learn C, or get a C guru to help you. To parenthesize, or not to parenthesize? ---------------------------------------- (This actually seems to have ended a little while ago, but I'll cover it anyway.) In a lot of cases, C operator precedence sucks. (I can quote K&R saying the same thing -- different wording, of course. Lets not argue about this point.) How does one deal with it? My solution: Most of the time I know. When I don't, I try it one way, and if it doesn't work right, I put parentheses in to force the issue. Many times I just add them to begin with. Who cares about a few extra parentheses, when you can *know* that the code will work as intended? (I hesitate to put "correctly" there ... B-)) A faster language (Prolog vs. C)? --------------------------------- Someone posts an example of a program which appears to be faster in Prolog than in C, hoping to get the C community upset, and succeeding. My answer: The two are not comparable, because: 1) It's an extremely small subset of each language 2) The compilers are doing different optimizations, which means inherently 3) The algorithms are not comparable Imprecision of floating point numbers ------------------------------------- This topic has been BEATEN TO DEATH in recent time. Floating point numbers simply can't represent every single number in their range perfectly. It's impossible without a HUGE precision. Someone mentioned the problem of converting numbers on input and output. This is, in fact, a major problem. I haven't seen a reference to the cited papers before, but I will definitely take a look at them. My solution: If you want true accuracy, use variable-precision BCD, if you have the time to wait. Initializing bit fields ----------------------- This seems to be well defined in ANSI C. There shouldn't be any argument about it here, except of course that, as usual, there is the question of "JUST HOW THE HELL DO I GET A COPY OF THE ANSI STANDARD?!?" Also, while the posting saying "... this doesn't even look like C to me ..." was probably out of place, it *is* very easy to learn to ignore the fluff and cut down to the information. The person that did the flaming here should have reconsidered his posting (and so should the person who flamed him back). The other people that talked about this treated it seriously, and without burning a hole through my monitor. I commend them for that. [B-)] My solution: Read all the follow-ups to the original article. To beep or not to beep ---------------------- Beeping is an effective way to get a user's attention. It can also be annoying though. Should programs beep or not? My answer: I don't see anything wrong with beeping, especially when on most machines I can control the volume, if not the pitch also. I don't stay up late at night 2 feet away from someone who is sleeping, so I'm not worried about the noise. It simply doesn't matter to me. And besides, visual beeps always take far too much CPU. And I *despise* long messages like: WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING [insert not-so-important error message here] ... when a simple beep would have sufficed and gotten my attention faster, AND wouldn't have cluttered up my screen as much. A side note ----------- I honestly think we should all sit down calmly, take a relaxation pill, and think things over. (In case you don't recognize it, that's a paraphrase from 2001: A Space Odyssey. [My spelling might be off. It's 3 AM ...]) There have been far too many flame wars in comp.lang.c. In fact, on most days I can mark over 3/4 of all the articles without reading them, because I know they're just a continuation of a flame war. It's really tiring. Disclaimer ---------- I'm open to additions and corrections to anything I say, provided it's in a positive, non-condescending manner. I'm always willing to learn from someone who knows more about something than I. (And I'm sure there are a *lot* of people here that know C better than I. I've only been writing it for 9 years. [B-I]). However, I abhor it when someone rants and raves, "NO NO NO NO NO!! GO READ YOUR MANUAL AGAIN! YOU DON'T KNOW C FOR SH*T!!" -- Virtually, Charles Martin Hannum "Those who say a thing cannot be done should Please send mail to: under no circumstances stand in the way of hannum@schubert.psu.edu he who is doing it." - a misquote
culliton@cdss.UUCP (Tom Culliton x2278) (07/03/90)
In article <1990Jul1.065531.18620@acc.stolaf.edu>, hannum@haydn.psu.edu (Charles Hannum) writes: > of some of the current flame wars on comp.lang.c ... > ... deleted text ... > > How to shut up lint > ------------------- > > How do you keep lint from complaining about things like the arguments to > malloc()? > > My solution: Don't use lint; it's ancient and brain-dead. Learn C, or get a C > guru to help you. > ... deleted text ... PLEASE, don't encourage people to abandon lint! Yes, its not all that it could/should be, BUT, I've seen a lot of code that could have really benifited from an inspection by the cranky old lady of the "C" programming world. You don't have to fix all the things that it complains about but its catches things that you might otherwise overlook. Let me give you an example... When I was porting some GNU code at my last job (it was either SED or AWK, I don't recall which) there were a couple of terrible problems I was having a hard time tracking down, (and I'm something of a guru at debugging) the breakthrough was when I ran the whole thing through lint. Lint gave me a LOT of extraneous garbage, which I ignored, and spotted a couple of functions which didn't return a value along every path! My immediate question was, why hadn't somebody else taken such a simple QC step before releasing the silly thing? Using lint does take some judgement, (you can't and shouldn't fix everything it complains about) but isn't that one of the principles of C programming? The programmer should be trusted to be a responsible adult and take the necessary steps to produce solid dependable code in return for the freedom to do whatever it takes to get there. In my opinion using lint, or something like it, is one of those steps. Tom ***************************************************************************** * uunet!culliton@cdss - Tom Culliton at Arinc Research Corp. Annapolis MD * * "I haven't lost my mind -- it's backed up on tape somewhere." * *****************************************************************************
zvs@bby.oz.au (Zev Sero) (07/04/90)
In article <1990Jul1.065531.18620@acc.stolaf.edu> hannum@haydn.psu.edu (Charles Hannum) writes:
In a lot of cases, C operator precedence sucks. (I can quote K&R saying the
same thing -- different wording, of course. Lets not argue about this point.)
How does one deal with it?
My solution: Most of the time I know. When I don't, I try it one way, and if
it doesn't work right, I put parentheses in to force the issue. Many times I
just add them to begin with.
My solution: Photocopy the table on page 49 of K&R1 (Page 53 of K&R2
is not as neat looking), and stick it on the wall next to your screen.
When in doubt (and even when not in doubt), look it up.
--
Zev Sero - zvs@bby.oz.au
...but we've proved it again and again
that if once you have paid him the danegeld,
you never get rid of the Dane. - Rudyard Kiplingfriedl@mtndew.UUCP (Stephen J. Friedl) (07/04/90)
> My solution: Photocopy the table on page 49 of K&R1 (Page 53 of K&R2 > is not as neat looking), and stick it on the wall next to your screen. Alternatively, stick this in /usr/local/bin: I use this all the time and this trivial little script has been handy time and time again (it fits on one screen without having to use more!). #------------------------------- cut here --------------------------- # opchart.sh # # Description: # # This simply prints a C operator precedence chart on # stdout. It is taken right from K&R, page 49. cat << 'EOF' C operator precedence/associativity chart Arity Operator Assoc -------------------------------------------------------------- binary () [] -> . l -> r unary ! ~ ++ -- - (type) * & sizeof r -> l binary * / % l -> r binary + - l -> r binary << >> l -> r binary < <= > >= l -> r binary == != l -> r binary & l -> r binary ^ l -> r binary | l -> r binary && l -> r binary || l -> r ternary ?: r -> l binary = += -= *= /= %= >>= <<= &= ^= |= r -> l binary , l -> r -------------------------------------------------------------- From K&R, p 49 EOF #------------------------------- cut here --------------------------- -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "Show me a good loser and I'll show you a loser" - Roger Penske
donp@na.excelan.com (don provan) (07/06/90)
In article <1990Jul4.020809.7619@melba.bby.oz.au> zvs@bby.oz.au (Zev Sero) writes: >In article <1990Jul1.065531.18620@acc.stolaf.edu> hannum@haydn.psu.edu (Charles Hannum) writes: >>My solution: Most of the time I know. When I don't, I try it one way, and >>if it doesn't work right, I put parentheses in to force the issue. Many >>times I just add them to begin with. > >My solution: Photocopy the table on page 49 of K&R1 (Page 53 of K&R2 >is not as neat looking), and stick it on the wall next to your screen. >When in doubt (and even when not in doubt), look it up. You guys make me feel lazy. I just put in the stupid parentheses and don't worry about the precedence. Why are you two knocking yourselves out? Is it just so everyone (including you) who looks at the code later can get practice by repeating the procedure? don provan donp@novell.com
fmcwilli@oracle.oracle.com (Floyd McWilliams) (07/12/90)
In article <1990Jul1.065531.18620@acc.stolaf.edu> hannum@haydn.psu.edu (Charles Hannum) writes: >My solution: Don't use lint; it's ancient and brain-dead. Learn C, or get >a C guru to help you. I work for Oracle's kernal development group. Everyone here knows C; many of us are gurus. But nobody is going to wade through thousands of lines of code every time we change a structure, alter calling conventions, or add new code. Lint is an automated tool that checks for simple errors. It catches most of these errors and returns some spurious messages, which means the person running line must spend a few minutes checking them out. Beats poring over the code for several hours with a copy of K&R II. -- Floyd McWilliams -- fmcwilli@oracle.com "Little bunny Foo-foo, rocking out for Satan. Picking up little field mice and biting off their heads."
john@frog.UUCP (John Woods) (07/14/90)
In article <1506@excelan.COM>, donp@na.excelan.com (don provan) writes: > In article <1990Jul4.020809.7619@melba.bby.oz.au> zvs@bby.oz.au (Zev Sero) writes: > >My solution: Photocopy the table on page 49 of K&R1 (Page 53 of K&R2 > You guys make me feel lazy. I just put in the stupid parentheses and > don't worry about the precedence. Ah, but when you parenthesize someone else's code it can be handy to know by inspection whether or not you've just fixed a bug. That's why I used tbl and troff to make a nice, large copy of the K&R table so I can see it from across the room... -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
unhd (Anthony Lapadula) (07/16/90)
In article <1990Jul12.151618.16133@oracle.com> fmcwilli@oracle.com (Floyd McWilliams) writes: >In article <1990Jul1.065531.18620@acc.stolaf.edu> hannum@haydn.psu.edu (Charles Hannum) writes: >>My solution: Don't use lint; it's ancient and brain-dead. Learn C, or get >>a C guru to help you. > > Lint is an automated tool that checks for simple errors. It catches >most of these errors and returns some spurious messages, which means the >person running line must spend a few minutes checking them out. Beats >poring over the code for several hours with a copy of K&R II. > >-- > Floyd McWilliams -- fmcwilli@oracle.com > "Little bunny Foo-foo, rocking out for Satan. > Picking up little field mice and biting off their heads." True, but I've yet to see a version of lint that understands prototypes. Anyone know where I might find source code for such a beast? -- Anthony Lapadula No cute .sigs allowed!
mcdaniel@adi.com (Tim McDaniel) (07/17/90)
al@uunet!unhd (Anthony Lapadula) asks:
... I've yet to see a version of lint that understands prototypes.
Anyone know where I might find source code for such a beast?
FlexeLint, from
Gimpel Software
3207 Hogarth lane
Collegeville, PA 19426
1 215 584 4261
It can be run on SUNs, VAXen, et cetera. It's a fine product, and I
really like using it.
(I have no financial interest in Gimpel.)
--
"I'm not a nerd -- I'm 'socially challenged'."
Tim McDaniel
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!puffer!mcdanieljohnb@srchtec.UUCP (John Baldwin) (07/18/90)
In article <1990Jul15.194736.11447@uunet!unhd> al@unhd.UUCP (Anthony Lapadula) writes: > >True, but I've yet to see a version of lint that understands prototypes. >Anyone know where I might find source code for such a beast? > I don't know about anything PD or shareware, but Gimpel software makes a really great lint; Jim Gimpel keeps up fairly well with the changes in C and upgrades the product on a regular basis. As far as I know, the most recent upgrade (which I haven't got yet) is fully ANSI. The version I use (just previous to the most current) certainly understands prototypes, and has a lot of features that older "original UNIX lints" don't have. The version for MS-DOS is very reasonably priced, in the $99 price range (last time I checked). And, WORTHY OF NOTE, Gimpel Software doesn't believe in stiffing its customers with outrageous upgrade fees (I think the MS-DOS version upgrades for something like $20 --- well worth the additional functionality you receive!) I know they have their LINT available for platforms other than mess-dos but I don't remember just what platforms are supported. They also have it available as "shrouded source code," for porting to *any* machine with a decent C compiler. "Shrouded" means they have a (really neat) automated C Code Obfuscator (also available commercially) which buffoonerizes all the identifiers and constructs and removes any indentation information: effectively producing "compiler readable only" source code. Any C compiler (I don't know if this means ANSI, K&R, or both) should find it a valid program, but you won't be able to understand it or modify it --- thus they can sell it to you for significantly less than they would a full source-code license. ------------------------------------------------------------------------------ John T. Baldwin | NOT a paid spokesman for Gimpel Software. really. research analyst | search technology, inc. | "The opinions expressed came from a Chinese fortune johnb@srchtec.uucp | cookie with my lunch yesterday."