dewitt@cca.UUCP (Mark DeWitt) (04/09/86)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** I have three questions, the first of which was only brought to my attention by lint, not caused by it. The code in question works under BSD4.2 on both vaxes and suns. 1. I have code with declarations that look like the following: struct tm *zulu, *gmtime(); but I forgot to #include <sys/time.h> at the top. Pretty careless, but what is remarkable is that I never noticed until I ran lint on it. WHY DID THIS COMPILE SUCCESSFULLY? The only other headers I included were ctype.h and stdio.h, neither of which includes anything else. The lint message was: warning: structure tm never defined 2. With the following code-- static int page; ioctl(0, SOMEINTEGER, (char *)&page); or ioctl(0, SOMEINTEGER, (char *)(&page)); lint says: warning: illegal pointer combination. This doesn't make sense to me. For one thing, ioctl's arguments are defined in the manual as: ioctl(int d, int request, char *argp) For another thing, the C Reference Manual says (Section 14.4): "It is guaranteed that a pointer to an object of a given size may be converted to a pointer to an object of smaller size and back again without change." So why can't I cast the address of a static integer into a pointer to a character? If I don't cast all such arguments of disparate types to char *'s then lint complains about "arg n not declared consistently" or something like that. 3. How do you get lint to shut up about variable numbers of arguments with stdio functions like printf, scanf, etc.? I tried using /*VARARGS*/ right, left, and sideways to no avail. The doc is not great, but you knew that already. After three years of C programming I'm just starting to use lint, so please no negative reinforcement by flaming about how stupid my questions are, lest I give up on it entirely :-). -- "We like your attitude, but what are you doing?"
steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (04/11/86)
In article <7097@cca.UUCP>, dewitt@cca.UUCP (Mark DeWitt) writes: > I have three questions, the first of which was only brought to my > attention by lint, not caused by it. > > ............. question 1 deleted > > 2. With the following code-- > static int page; > > ioctl(0, SOMEINTEGER, (char *)&page); > or > ioctl(0, SOMEINTEGER, (char *)(&page)); > > lint says: > > warning: illegal pointer combination. > > ......... question 3 deleted > When I lint the following on a Ridge 32C under ROS 3.3 (SYSV derivative), #include <stdio.h> main() { static int page; ioctl(0,2,(char *)(&page)); } I get test.c ============== (7) warning: main() returns random value to invocation environment ============== function returns value which is always ignored ioctl Note that there are no pointer complaints. Sounds like you have a problem on your system. If lint complains about the sample above, I would complain to the vender. -- ...smeagol\ Steve Schlaifer ......wlbr->!jplgodo!steve Advance Projects Group, Jet Propulsion Labs ....group3/ 4800 Oak Grove Drive, M/S 156/204 Pasadena, California, 91109 +1 818 354 3171
rb@ccird2.UUCP (Rex Ballard) (04/15/86)
In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >*** REPLACE THIS LINE WITH YOUR MESSAGE *** >I have three questions, the first of which was only brought to my >attention by lint, not caused by it. The code in question works under BSD4.2 >on both vaxes and suns. > >1. I have code with declarations that look like the following: > struct tm *zulu, *gmtime(); > >but I forgot to #include <sys/time.h> at the top. Pretty careless, >but what is remarkable is that I never noticed until I ran lint on >it. WHY DID THIS COMPILE SUCCESSFULLY? >The lint message was: >warning: structure tm never defined If you did not attempt to access any of the structure members, the compiler would just "fudge" the pointer. If the pointer pointed to an odd address, the execution would have bombed. Compilers are often very forgiving (I have one that exepts newlines as statement terminators, but lint bombs from the syntax errors). > >3. How do you get lint to shut up about variable numbers of arguments >with stdio functions like printf, scanf, etc.? I tried using /*VARARGS*/ >right, left, and sideways to no avail. The doc is not great, but you >knew that already. The /*VARARGS*/ escape has to be put just before the code that defines the function. ie: /*VARARGS1*/ printf(s,p) char *s; int p; { int i; return(i) }; this should have been done when your lintlib was created. You may need to re-create the lintlib. There are usually skeleton definitions in the same directory as the lintlib (4.2). V7 had these declarations in source form only. >After three years of C programming I'm just starting to use lint, so >please no negative reinforcement by flaming about how stupid my questions >are, lest I give up on it entirely :-). YAHOO!!! GOOD FOR YOU!!! :-). You have taken a good step into the realm of clean, portable code. We've cut our debug time by 60-70% doing this, and reduced maintenance costs as well. There is really no justification for not using lint.
philip@axis.UUCP (04/18/86)
Just a comment on using lint to improve code portability: I agree entierely that lint really does cut down on debugging time and should always be used during development. However, some of my experiences with portability are not so encouraging. We sell a Pascal -> C translator (written in C) which we port to (almost) any UNIX system which has a C compiler. When I took over responsibility for this product, there was an outstanding job - porting to a RIDGE running ROS (not a real unix anyway). This had been attempted by my predecessor and abandoned. When I looked at the problem I didn't blame him - the translator uses lots of variable argument lists, and the RIDGE has a wierd method of passing arguments! To help me to find out where the problems lay, I used lint. It took about three weeks of work to make the whole think lint-free, but it was worth it, it worked! (I had to write my own version of varargs). Now comes the nasty bit: One day I tried to port this to another machine (which shall remain nameless), and the compiler produced LOTS of messages about pointer coercions (you guessed it, its one of those machines with ints and pointers of different sizes). I ran lint and it produced about 5 pages of complaints - not all related to pointers. It would seem that some people out there MODIFY lint to match their own compilers. This makes using lint just about worthless when trying to write portable code. The only consolation is that such a nasty trick seems to be quite rare. The moral is BEWARE lint-free one one machine may not be lint free on another.
garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (04/21/86)
In a recent article philip@axis.UUCP (Philip Peake) wrote: >... >It would seem that some people out there MODIFY lint to match their own >compilers. This makes using lint just about worthless when trying to write >portable code. The only consolation is that such a nasty trick seems to >be quite rare. >... I have had the pleasure of having to dig through the source to Lint. At least on the machine I was on (a BSD derivative), Lint just consisted of the front end of the machine's regular C compiler, plus a lot of kludges to check a few more things and to deal with Lint's intermediate data files. If Lint is indeed always based on the host's compiler, one might expect considerable variability. garry wiegand garry%cadif-oak@cu-arpa.cs.cornell.edu Interesting aside: the source to Lint could not in a million years pass Lint.
kay@warwick.UUCP (Kay Dekker) (04/26/86)
In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >After three years of C programming I'm just starting to use lint, so >please no negative reinforcement by flaming about how stupid my questions >are, lest I give up on it entirely :-). Mark, I'm not flaming you, but I *am* worried! If you've been programming in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* lint. You have my profound sympathy. OR 2) Nobody ever taught you about using lint. I wonder why not? OR 3) You never realised that using lint was important. You must have wasted many hours (that you could have spent playing Rogue or whatever :-)) chasing problems down that lint might well have indicated to you. People, what are *we* doing wrong when somebody can spend 3 years programming in a particular language and only then start using one of the most important development tools for it? It's got to the point when if I'm doing program surgery and someone comes up saying that their program "doesn't work", if they haven't brought a line-numbered listing of the source AND a lint output, I don't really want to start looking for the problems. Kay. -- "I AM; YOU ARE; HELLO: all else is poetry" ... mcvax!ukc!warwick!kay
rbj@icst-cmr (Root Boy Jim) (05/01/86)
> In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: > >After three years of C programming I'm just starting to use lint, so > >please no negative reinforcement by flaming about how stupid my questions > >are, lest I give up on it entirely :-). > > Mark, I'm not flaming you, but I *am* worried! If you've been programming > in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* > lint. You have my profound sympathy. OR 2) Nobody ever taught you about > using lint. I wonder why not? OR 3) You never realised that using lint > was important. You must have wasted many hours (that you could have spent > playing Rogue or whatever :-)) chasing problems down that lint might well > have indicated to you. > > People, what are *we* doing wrong when somebody can spend 3 years programming > in a particular language and only then start using one of the most important > development tools for it? > > It's got to the point when if I'm doing program surgery and someone comes up > saying that their program "doesn't work", if they haven't brought a > line-numbered listing of the source AND a lint output, I don't really want > to start looking for the problems. > Kay. > -- > "I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay You people fail to realize that some of us out here don't like lint. It complains too much about what I do. I refuse to go any further than generating no compiler warnings. I know what I'm doing. When I goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. Before you start flaming my style, let me say I am quite good. I am also quite philosophical and attentive to coding style. My outlook is just different. I program for myself. If it is applicable to you, fine. I have my own criteria which I rarely see embraced by others waving standardization flags. Most of the code I have written was intrinsically non-portable. I *do* appreciate portability as a spectrum concept, but not as a binary one. This is just me. I'm not sure I would recommend my methods to anyone else, especially novices. My experience was obtained with more than a few battle scars. There are probably easier ways. (Root Boy) Jim Cottrell <rbj@cmr> "I'm alright, Jack, keep your hands off of my stack"
gwyn@BRL.ARPA (VLD/VMB) (05/01/86)
Re: "lint" not being as smart as Root Boy Jim That's really silly. I write C code such that I expect absolutely NO warnings from "lint" (except for malloc pointer type-cast, which is unavoidable at present); then if I get any "lint" warnings, they indicate BUGS that must be fixed. This is tremendously helpful. I find that there are very few "inherently nonportable" applications. Even when an application is designed to use specific hardware, portable programming techniques contribute to better code quality. Lint-free coding comes naturally after a bit of practice. I find it no burden at all, and hardly have to think about it. Indeed, it helps organize my use of complicated data types so that I get the code right (and portable!) the first time.
ded@aplvax.UUCP (Don E. Davis) (05/02/86)
>You people fail to realize that some of us out here don't like lint. >It complains too much about what I do. I refuse to go any further >than generating no compiler warnings. I know what I'm doing. When I >goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > (Root Boy) Jim Cottrell <rbj@cmr> (Root Boy) is not alone, though with a name like that he should be. ;-) I know several excellent programmers who never use lint. Personally, I use lint some, but it is not my religion. I do think programmers should be familiar with lint but I don't think we should run screaming into the sea because someone never heard of it. If they haven't heard of hack, now -- that's a different story! -- Don Davis JHU/APL ...decvax!harpo!seismo!umcp-cs!aplcen!aplvax!ded ...rlgvax!cvl!umcp-cs!aplcen!aplvax!ded
garys@bunkerb.UUCP (Gary M. Samuelson) (05/03/86)
In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes: >In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >>After three years of C programming I'm just starting to use lint, so >>please no negative reinforcement by flaming about how stupid my questions >>are, lest I give up on it entirely :-). >Mark, I'm not flaming you, but I *am* worried!... And well you should be. >People, what are *we* doing wrong when somebody can spend 3 years programming >in a particular language and only then start using one of the most important >development tools for it? Good question. I offer the following opinion: generally, even though most companies (and schools, for that matter) give lip service to "proper" development techniques, in reality they reward those who write sloppy, un-commented, ill-planned or un-planned code. Did you not read the discussion about the teaching of programming? Some, thank God, do pay some attention to issues such as style, but most still look only at the output. And many companies are worse than schools. Productivity is measured in lines of code -- which means that if you are actually trying to *design* before writing code, you aren't being productive. Some places don't require specifications; some do, supposedly, but any pile of paper with the word "specification" on the top sheet will apparently do. Fewer still understand the difference between a requirement (storing data) and design (let's use a hard disk). Some people -- in senior management positions, where they ought to know better -- actually believe that "we can't afford" to do things like impose coding standards, much less have design reviews or even code reviews. It is practically a proverb that "there's never time to do it right, but there's always time to do it over." Such short-sightedness -- the belief that having a program which does *anything* resembling what the user wants is better than waiting another week -- results in all sorts of trash being shipped Friday only to be junked Monday. Of course, part of the problem is that a lot of C programmers in particular learned C from the Unix (tm) source. I just picked 'rm.c', more or less at random, and found exactly one comment: all files following a null option are considered file names That's it. It isn't even obvious that 'rm.c' removes files (I suppose that one would eventually find that there is an 'unlink' call in there somewhere, and figure it out). >It's got to the point when if I'm doing program surgery and someone comes up >saying that their program "doesn't work", if they haven't brought a >line-numbered listing of the source AND a lint output, I don't really want >to start looking for the problems. > Kay. Good for you! That is the type of attitude required. In many cases, I would go even further and require that the line-numbered listing be part of a cross-reference. Also, when someone says, "This program doesn't work," it is often revealing to ask, "what's it supposed to do?" It is amazing -- and frustrating -- how often the person can give no clear answer. Gary Samuelson >"I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay At last! someone who appreciates my poetry! :-)
rbj@icst-cmr (Root Boy Jim) (05/03/86)
Re: "lint" not being as smart as Root Boy Jim
Gee, I hope not. After it's *only* a *program* (and I'm not? :-)
That's really silly. I write C code such that I expect absolutely
NO warnings from "lint" (except for malloc pointer type-cast, which
is unavoidable at present); then if I get any "lint" warnings, they
indicate BUGS that must be fixed. This is tremendously helpful.
Not really. I will give you one good example of a technique that is NOT a
bug, altho it may make you shudder somewhat. I have ranted about C using
a one statement model for its control statements instead of an explicit
end statement. Compound statements are bounded by braces instead. Yuk!
Fortunately, there is the comma operator. This allows the following:
Most People Your's Truly
if (c) { if (c)
w = y; w = x,
y = z; y = z;
} /* look ma, no brace */
Other things you will see in my code are:
if (argc < 2)
exit((printf("usage: foo bar\n"),1));
or even: exit(1,printf("usage: foo bar\n"));
Sufficeth to say that I use a lot of commas in my code. Unfortunately,
I cannot do this if either statement is a control struxure, *except* return.
Most People Your's Truly
if (c) { if (c)
w = y; return w = x,
return;
} /* look ma, no brace */
When I want to return a *real* value, I use `return(exp)' using *explicit*
parens. I only do this in void funxions of course. I cannot see *any*
implementation doing either of the following:
1) barfing because I returned an *extra* value sometimes
2) barfing because I added an extra argument
Now you may claim that this is `bad programming practice', but I claim
that it is just a convention, just like #defines are usually capitalized.
You may not like either one, but I claim this is portable. And, it is
meaningful to me.
I find that there are very few "inherently nonportable" applications.
Even when an application is designed to use specific hardware,
portable programming techniques contribute to better code quality.
This is probably true. He who lives by the trick usually dies by it.
On the other hand, I just tried to port the System V date to BSD, and
it mumbled somthing about timezones not being defined. My point is
that even the simplest things usually require *some* diddling.
Lint-free coding comes naturally after a bit of practice. I find
it no burden at all, and hardly have to think about it. Indeed,
it helps organize my use of complicated data types so that I get
the code right (and portable!) the first time.
Yes, but it all depends on what you're willing to put up with. I find it
terribly ugly having to cast printf's or close's to void. And as
someone pointed out, assignments return a value too, so should we cast
them to void as well? Oh yeah, assignment is `different'.
(Root Boy) Jim Cottrell <rbj@cmr>
"One man gathers what another man spills"zben@umd5.UUCP (Ben Cranston) (05/03/86)
In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: >In article <*> Root Boy Jim writes: >>You people fail to realize that some of us out here don't like lint. >>It complains too much about what I do. ... >I know several excellent programmers who never use lint. ... Hmm, I remember a certain Cobol compiler that had an 'E' option to generate error messages - because it generated such a quantity of informational diagnostics but its users wanted "clean compiles". I can see Cobol types complaining about this, but US? I'll be perfectly happy when I can understand what lint is saying to me, and convince myself that it is just being paranoid. Dare I suggest this: a filter for lint output that only lets the real bad errors through? Dare I suggest THIS: that it would be easier if every line from lint had an identification tag like this: BCD325I: Bad C construct at line 2543342 (No, No, anything but EBCDIC!) -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
gwyn@BRL.ARPA (VLD/VMB) (05/03/86)
Failure to examine the value returned by a function is probably an error; at the very least, a deliberate decision should be made to ignore it (which is the PROPER use of the (void) cast). This does not apply to assignments. "Lint" makes the proper distinction between these cases.
bzs@bu-cs.UUCP (Barry Shein) (05/03/86)
>From: gwyn@BRL.ARPA (VLD/VMB) >Re: "lint" not being as smart as Root Boy Jim > >That's really silly. I write C code such that I expect absolutely >NO warnings from "lint"... Although I agree philosophically, this reminds me a lot of the days when I prided myself on being the only person I knew who could write PL/I code without even an informatory message (and then get to harangue other programmers when they modified my code and left "I" messages..argh!) I started to wonder after a while how much I was actually accomplishing much more than simulating the damn error checker in my brain rather than writing such wonderful code all the time (meaning, whether it really proved anything that I could keep PLIOPT silent.) The point is, that some of this is really to an extent more a display of the prowess of the programmer's ability to simulate compilers and checkers somewhat (not that that isn't useful, but I wonder if it's not a little distracting sometimes.) At any rate, it's something to strive for, I guess I just react to anything that sounds a little dogmatic in either direction. I would put it more like this: IF you worked for me, I may very well run code you hand me through lint, ya better be ready to answer for any messages, so you may as well run it through yourself. I wish root-boy could be a little more specific, rather than dismissing his claim as 'silly' I would be open to the idea that LINT needs some more design work, 10 years ago we were more open to its foibles than we should be today, us old-timers get too complacent. A more interesting idea: Would it be reasonable to run a vendor's code you just bought through LINT and call their warranty dept if there was any serious bitching by lint? Just a thought. -Barry Shein, Boston University
operators@watmath.UUCP (M.F.C.F. Operators) (05/03/86)
In article <453@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >Most of the code I have written was intrinsically non-portable. I *do* >appreciate portability as a spectrum concept, but not as a binary one. Good point. There seems to be a lot of people confusing "portability" and "machine-independance". Some years ago Malcolm and Rogers defined a measure they called the "portability index" of a program cost to modify the existing code for new environment index = ----------------------------------------------------- Cost to recode from scratch an equivalent program Where "cost" is appropriate function for your environment time, money etc. A machine independant program would have a portabily index of 0.
grr@cbmvax.cbm.UUCP (George Robbins) (05/04/86)
In article <942@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: > >>In article <*> Root Boy Jim writes: >>>You people fail to realize that some of us out here don't like lint. >>>It complains too much about what I do. ... > >>I know several excellent programmers who never use lint. ... > >Hmm, I remember a certain Cobol compiler that had an 'E' option to generate >error messages - because it generated such a quantity of informational >diagnostics but its users wanted "clean compiles". I can see Cobol types >complaining about this, but US? > The whole lint/cc issue is probably one of those little misfeatures of unix that we just have to live with. Sure there are historical reasons, and nice efficiency arguments for keeping the two separate, but if lint was a default pass of the compiler that could be disabled, or diminished by a switch, then there would be a whole lot more people using lint, and generating more portable code than otherwise. One of the more traumatic things about being exposed to unix after working with numerous other systems was that the stupid c compiler refused to give me a nice clean listing with source, interspersed error messages, and optional object code. I'm not dumb, but trying to learn a debug a big program though a 24-line window and my memory just doesn't make it... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
ggs@ulysses.UUCP (Griff Smith) (05/04/86)
> Most People Your's Truly > > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ ... > Sufficeth to say that I use a lot of commas in my code. Unfortunately, > I cannot do this if either statement is a control struxure, *except* return. > > Most People Your's Truly > > if (c) { if (c) > w = y; return w = x, > return; > } /* look ma, no brace */ > > When I want to return a *real* value, I use `return(exp)' using *explicit* > parens. I only do this in void funxions of course. I cannot see *any* > implementation doing either of the following: > > 1) barfing because I returned an *extra* value sometimes > 2) barfing because I added an extra argument > > Now you may claim that this is `bad programming practice', but I claim > that it is just a convention, ... ... > (Root Boy) Jim Cottrell <rbj@cmr> "Thank you, Mr Cottrell. It is refreshing when job applicants are so candid during an interview; we will notify you of our decision in a few weeks..." -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/05/86)
Barry, the point is, if you have a decent version of "lint", then ANYthing it warns you about really could be an error. It is not always obvious to the non-expert what the problem could be, but I haven't seen more than a few actual errors made by our SVR2+ "lint". Therefore, if you really do want your code to port without hassle, you should pay attention to what "lint" tells you about your code. Furthermore, for this approach to be maximally helpful, you want to reduce the not-really-a-problem messages so that real problems do not get buried among the non-problems. The main category of "lint" messages that do not indicate bugs or possible portability problems is the detection of unused variables, functions, parameters, and function values. Most of these are probable errors in the code. The one that seems to bother people most is the flagging of unused function values. The naive idea that one then sticks "(void)" in front of all such function invocations "just to shut lint up" indicates a misunderstanding of what lint is all about. If one's own functions do not return values, they should be declared of type void. If a function's value is sometimes important and sometimes not (good examples of this are fairly rare), then one should explicitly indicate discarding of the value, which is the proper use of (void). This shows whoever reads the code that the matter has been thought about and indeed the value is not needed in that invocation (it also forces you to think about the matter when you write the code). The final instance involves standard library functions; I claim that robust code really must check the majority of function returns (strcpy() is a notorious exception, since it doesn't tell one anything useful). I just finished writing an MDQS despooling slave both with and without using stdio for device output; in order to detect problems with the output device and perform appropriate error recovery, it was essential to test the return values from putchar(), fflush(), and other such functions that most programmers do not test. The fact that "lint" encourages one to program responsibly is good! If you follow my recommendation and try to make your code lint-free in the first place, then ANY noise from "lint" will necessarily call your attention to a bug. This is extremely helpful, but it only works well if the expectation is that there will be no "lint" output for correct code. Now, if you want to just "hack around", then "lint" is not for you; but if you're producing production-quality C code, there is no excuse for delivering unduly linty code. In answer to your question, yes, I think one has a right to expect C source code deliverables (pretty rare these days) to be lint-free. Every time we get code that hasn't been done that carefully, it doesn't work right and a lot of time has to be spent fixing it. This should be the vendor's responsibility, not the customer's; but a vendor that ships code like that probably won't be able to fix it properly either. P.S. Unless your malloc() has type (void *), "lint" warnings about incompatible pointer conversion will be unavoidable, since "lint" doesn't realize that malloc() arranges its (char *) return value to be maximally aligned. This is one of the few "lint" warnings that correct code should produce, and it is easy to spot. But beware the yo-yo who fails to declare the malloc() function, invokes it (as a default int-valued function), and casts the result to (char *); that's incorrect usage. P.P.S. Don't look to the UNIX sources for good examples of lint-free code; some of them are good, but most are horrible. P.P.P.S. I agree with the fellow who identified the major problem as poor programming management. C code quality is only a small part of overall software quality. All too often, one sees programmers writing code before a proper job of analysis and design has been done. I also believe that is partly because semi-running code makes it appear as though progress has been made, while a complete design doesn't convey the same impression. The only solution is to educate the management involved. There are many good books (mostly from Yourdon, Inc.) that can be used to help with this; my experience has been that such educational efforts are only partially successful, but that partially correct organization of the software development process is better than none.
dave@andromeda.RUTGERS.EDU (Dave Bloom) (05/05/86)
>> People, what are *we* doing wrong when somebody can spend 3 years programming >> in a particular language and only then start using one of the most important >> development tools for it? > Good question. I offer the following opinion: generally, even though > most companies (and schools, for that matter) give lip service to > "proper" development techniques, in reality they reward those who > write sloppy, un-commented, ill-planned or un-planned code. Just because you don't always use lint, doesn't mean your code is sloppy or ill planned. Very often programs do *NOT* have to be portable... In fact, sometimes code is easier to read if you haven't gone out of your way to be portable. Further more, the Lint S/N ration is frustrating, to say the least. And many of us don't believe in muddling up code with void casts and the like to keep lint happy.... -- harvard\ pyramid\ Dave Bloom seismo \ pyrnj \ ut-sally >!topaz >!andromeda!dave Office: (201) 648-5083 allegra / caip / ihnp4!packard/ yogi/ "You're never alone with a schizophrenic...."
gelfand@valid.UUCP (05/05/86)
> In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: > >After three years of C programming I'm just starting to use lint, so > >please no negative reinforcement by flaming about how stupid my questions > >are, lest I give up on it entirely :-). > > Mark, I'm not flaming you, but I *am* worried! If you've been programming > in C for 3 years and not using lint then EITHER 1) Your system doesn't *have* > lint. You have my profound sympathy. OR 2) Nobody ever taught you about > using lint. I wonder why not? OR 3) You never realised that using lint > was important. You must have wasted many hours (that you could have spent > playing Rogue or whatever :-)) chasing problems down that lint might well > have indicated to you. > > People, what are *we* doing wrong when somebody can spend 3 years programming > in a particular language and only then start using one of the most important > development tools for it? > > Kay. > -- > "I AM; YOU ARE; HELLO: all else is poetry" > ... mcvax!ukc!warwick!kay I have been programming for many years (over 20) in many different languages, and C is the only language that I can remember that has a separate program (lint) to find and report compiler errors in source code. All of the other languages I have used have this function built into the compiler. Perhaps because UNIX is a programmers system rather than a production system this was felt to be unnecessary. In most production systems the programs spend more time executing than compiling; while in a development system most of the time is spent editing and compiling. Thus running lint each time would add to the load on the system. A suggestion, system adminstrators could replace the cc command with a script that would invoke lint before the C compiler. Then everyone would run lint and perhaps development time spent tracking down bugs would decrease. Brooks Gelfand
rbj@icst-cmr (Root Boy Jim) (05/06/86)
> In article <942@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: > >In article <219@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: > > > >>In article <*> Root Boy Jim writes: > >>>You people fail to realize that some of us out here don't like lint. > >>>It complains too much about what I do. ... > > > >>I know several excellent programmers who never use lint. ... > > > >Hmm, I remember a certain Cobol compiler that had an 'E' option to generate > >error messages - because it generated such a quantity of informational > >diagnostics but its users wanted "clean compiles". I can see Cobol types > >complaining about this, but US? > > > > The whole lint/cc issue is probably one of those little misfeatures of unix > that we just have to live with. Sure there are historical reasons, and nice > efficiency arguments for keeping the two separate, but if lint was a default > pass of the compiler that could be disabled, or diminished by a switch, then > there would be a whole lot more people using lint, and generating more > portable code than otherwise. > > One of the more traumatic things about being exposed to unix after working > with numerous other systems was that the stupid c compiler refused to give me > a nice clean listing with source, interspersed error messages, and optional > object code. I'm not dumb, but trying to learn a debug a big program though > a 24-line window and my memory just doesn't make it... > > -- > George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr > but no way officially representing arpa: cbmvax!grr@seismo.css.GOV > Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) BSD has a program called `error' that will insert the errors & then invoke `vi' on all the sources. EMACS will do that as well. (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"
faustus@cad.UUCP (Wayne A. Christopher) (05/06/86)
The thing that RBJ seems to be annoyed about is the fact that lint generates error messages whenever you ignore the return value of close(), unlink(), etc, and it is quite ugly to put (void) in everywhere. However, in my experience if you use the right flags these are the only sort of errors you should ignore (and malloc pointer problems, of course). I would say that the most useful messages lint gives you is argument type/number mismatches... Wayne
faustus@cad.UUCP (Wayne A. Christopher) (05/06/86)
Hmm, so now we see from which soapbox Root Boy is speaking... I don't like to criticize people's personal preferences, but when you are writing code that other people have to maintain, strange coding practices like this are as bad as bugs... I almost wish that lint would catch non-standard style in addition to portability problems... Wayne
greg@utcsri.UUCP (Gregory Smith) (05/06/86)
In <183@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >... I'm not dumb, but trying to learn a debug a big program though >a 24-line window and my memory just doesn't make it... > Get EMACS. -- "Canabee be said2b or not2b anin tire b, if half thabee isnotabee, due2 somain chunt injury?" - Eric's Dilemma ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (05/06/86)
In article <256@valid.UUCP>, gelfand@valid.UUCP (Brooks Gelfand) writes: > > I have been programming for many years (over 20) in many different > languages, and C is the only language that I can remember that > has a separate program (lint) to find and report compiler errors in > source code. All of the other languages I have used have this function > built into the compiler. Perhaps because UNIX is a programmers > system rather than a production system this was felt to be unnecessary. > In most production systems the programs spend more time executing than > compiling; while in a development system most of the time is spent editing > and compiling. Thus running lint each time would add to the load > on the system. Actually, having lint be a seperate program fits nicely with the original software tools philosophy of unix. That is, a program should do one thing and do it well. A compiler within this philosophy should compile whatever you give it so long as it can make sense of it. A seperate tool (lint in this case) should exist to point out things that you are doing which are questionable. The idea here is that the programs are then simpler to build, maintain and debug since they each have a simpler function to perform. For a better discussion of this than I can give see the AT&T Bell Laboratories Technical Journal of October 1984 (Vol 63, No. 8, Part 2) article by R. Pike and B. W. Kernighan (Program Design in the Unix Environment). -- ...smeagol\ Steve Schlaifer ......wlbr->!jplgodo!steve Advance Projects Group, Jet Propulsion Labs ....group3/ 4800 Oak Grove Drive, M/S 156/204 Pasadena, California, 91109 +1 818 354 3171
gwyn@BRL.ARPA (VLD/VMB) (05/06/86)
> C is the only language that I can remember that has a separate > program (lint) to find and report compiler errors in source code. First, the errors detected are not COMPILER errors but CODING errors. Second, I supose you never heard of the PL/I checkout compiler nor of "student Fortran compilers" such as WatFor? Separate compilers were used to generate production executable binary once the program was debugged. Third, "lint"ing is not necessary on every compilation. I often rebuild already de-linted software from source (e.g., when a library routine has been improved). Fourth, on small systems such as the PDP-11, making "lint" a separate program makes it possible to have both better compilation and better error checking without resorting to complicated multi-pass compilation. Fifth, "lint" is rather portable (I use the same version on three distinct architectures), whereas a code-generating compiler is inherently machine-dependent. In short, I see nothing wrong with the present set-up.
faustus@cad.UUCP (Wayne A. Christopher) (05/06/86)
In article <256@valid.UUCP>, gelfand@valid.UUCP writes: > I have been programming for many years (over 20) in many different > languages, and C is the only language that I can remember that > has a separate program (lint) to find and report compiler errors in > source code. First, lint doesn't report ERRORS -- it reports possible problems. Second, there is no other way you can check things like argument types (except for prototyping, which will make lint much less useful), since you generally compile only one .c file at a time. Wayne
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/06/86)
In article <560@brl-smoke.ARPA> Root Boy Jim <rbj@icst-cmr> writes: >BSD has a program called `error' that will insert the errors ... Coals to Newcastle.
dewitt@cca.UUCP (Mark DeWitt) (05/07/86)
In article <> garys@bunkerb.UUCP (Gary M. Samuelson) writes: >In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes: >>In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes: >>>After three years of C programming I'm just starting to use lint, so >>>please no negative reinforcement by flaming about how stupid my questions >>>are, lest I give up on it entirely :-). > >>Mark, I'm not flaming you, but I *am* worried!... > >And well you should be. I would like to thank the above and other contributors who have kept this discussion on a non-judgmental, rational plane. I would also like to point out that there is more than one way to learn portable coding style. Using lint and avoiding the messages it produces is one way. Having to (gasp!) port other people's code yourself is another way. Of my first six months of C programming, a good four months were spent porting "working" C code from the IBM PC to the Apple II+ / IIe, including graphics and floating point applications. Blech! It was painful, but I sure as hell learned a lot of what NOT to do if you want to write portable code. Most of my trouble with lint has not been with having to change my coding style, only with getting it to shut up. -- "We like your attitude, but what are you doing?"
wcs@ho95e.UUCP (#Bill_Stewart) (05/08/86)
In article <183@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >One of the more traumatic things about being exposed to unix after working >with numerous other systems was that the stupid c compiler refused to give me >a nice clean listing with source, interspersed error messages, and optional >object code. I'm not dumb, but trying to learn a debug a big program though >a 24-line window and my memory just doesn't make it... One of the more traumatic things about programming an IBM System-34 in RPG2 was that you got the listing whether you liked it or not. We had the slow printer, so my 10-page program took 45 minutes to compile, including cross-references, overlay maps, .... If we'd had the fast printer it would have taken about 20. Then we got the box of cheap paper which jammed the printer a lot, and I almost wanted my keypunch back..... (The system 34 was a desk-sized beast with 48K of core and a 13 Meg disk. Can you say "wimp!"?) If you get a fancy enough emacs package, you can have your C listing on-screen; otherwise you'll have to use somebody's pretty-printer, and hack in error message support. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
stevesu@copper.UUCP (Steve Summit) (05/08/86)
In article <501@brl-smoke.ARPA>, rbj@icst-cmr (Root Boy Jim) writes: > Most People Your's Truly > > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ There is an excellent, excellent book, which everybody should read, called The Elements of Style, by William Strunk and E. B. White. It is about writing in English, but almost everything in it applies to writing in programming languages as well. One of my favorite quotes (from page 74 of the third edition) is "In ordinary composition, use orthodox spelling. Do not write "nite" for "night," "thru" for "through," "pleez" for "please," unless you plan to introduce a complete system of simplified spelling and are prepared to take the consequences." The consequences, of course, are that in virtually all cases you will be laughed out of the room. Convention has a place. You are not being a sheep or a lemming if you do things the way most people do things; you are being responsible. C can be hard enough to read when it is formatted "correctly;" we certainly don't need any more unorthodox methodologies floating around. Proponents of things like "look ma, no braces" will claim that theirs is not "ordinary composition," and that they are therefore exempt from generally accepted programming practices. This statement is in fact perfectly true. If you want to be a rugged individualist and program in a vacuum; if nobody else ever reads your code; if only you have to maintain it or port it to other machines; then you are certainly welcome to make each program you write an odds on favorite for the winner's circle in the Obfuscated C Contest. However, do the rest of us a favor and perfect your isolated environment by sparing this newsgroup from your rantings and ravings. Steve Summit tektronix!copper!stevesu
rbj@icst-cmr (Root Boy Jim) (05/08/86)
????--> > C is the only language that I can remember that has a separate ????--> > program (lint) to find and report compiler errors in source code. GWYN--> [most of reply deleted] Because I agree with everything you said here. GWYN--> In short, I see nothing wrong with the present set-up. First off, let us remember that `cc' is NOT the C compiler. It is just the coordinator for all the phases that build programs. Therefore, I see no inconsistency with allowing `cc' to call lint if a given option is specified. This might encourage non-unix vendors to include lint with their products. (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"
henry@utzoo.UUCP (Henry Spencer) (05/08/86)
> All too often, one sees programmers writing code before > a proper job of analysis and design has been done. I > also believe that is partly because semi-running code > makes it appear as though progress has been made, > while a complete design doesn't convey the same impression. Sorry, Doug, I can't let that one go by. All too often, one sees programmers writing detailed design specifications before writing any code. This is probably because design specs make it appear that the problem is fully understood, and give the impression to management that the rest of the process of implementation will be entirely mechanical and hence will be on budget and on schedule. Ho ho. Then one gets to draw up a new budget and schedule for "maintenance", which is the process of modifying the program so that it really meets the customer's needs, instead of merely meeting the specification. The alternative is to recognize that (a) the user probably does not have a complete and coherent idea of what he needs, and hence cannot write a spec or meaningfully assess one you write, and (b) in any case, the presence of the software itself will change the user's tasks and therefore his needs. Given recognition of this situation, it is not even theoretically possible to avoid a trial-and-error process of software development. Hence you should aim to make your inevitable mistakes as early as possible. Which puts a heavy premium on getting initial prototype software into the hands of the customers right away, so that you can learn what's wrong with it. One progresses by iteratively enhancing (and perhaps sometimes re-doing) the prototype, with regular user feedback. This is not to say that the design-it-first method doesn't have its uses, and its advantages, when the problem is understood well enough. But a very large class of problems -- almost anything to do with user interaction, for example -- simply don't meet that criterion. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry
kwh@bentley.UUCP (KW Heuer) (05/09/86)
In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >I have ranted about C using a one statement model for its control >statements instead of an explicit end statement. Compound statements are >bounded by braces instead. Yuk! Ah yes, there are two major types of language in the structured family; f77 with "endif" (some members use "end" for all of "endif", "endwhile", etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I presume this is what you dislike. (If it's the spelling that bothers you, I'm sure you're aware that you can define "begin" and "end" as macros.) Yet another convention, not endorsed by any language I know, is to dispense with the braces and let the indentation alone tell the compiler how to interpret the program. (I came up with this idea after an argument on the "correct" place to put the braces.) >Fortunately, there is the comma operator. This allows the following: > Most People Your's Truly > if (c) { if (c) > w = y; w = x, > y = z; y = z; > } /* look ma, no brace */ I can hardly flame you for this, since I've used it myself when in a hurry. (But I write it on one line, "if (c) w=x, y=z"). I usually end up rewriting it with braces, though. >Other things you will see in my code are: > exit((printf("usage: foo bar\n"),1)); >or even: exit(1,printf("usage: foo bar\n")); What's wrong with printf("usage: foo bar\n"), exit(1); as above? >Sufficeth to say that I use a lot of commas in my code. Unfortunately, >I cannot do this if either statement is a control struxure, *except* return. > Most People Your's Truly > if (c) { if (c) > w = y; return w = x, > return; > } /* look ma, no brace */ You're introducing a minor inefficiency, since the compiler will have to copy the result of the last expression into the return register. I presume you don't bother to declare void functions "void", either, or this wouldn't make it past the compiler. >I cannot see *any* implementation doing either of the following: > 1) barfing because I returned an *extra* value sometimes > 2) barfing because I added an extra argument You're probably correct in that all implementations that accept your code will produce correct results; however, I can easily imagine a compiler that would refuse to compile such an "obvious bug". >Now you may claim that this is `bad programming practice', but I claim >that it is just a convention, just like #defines are usually capitalized. >You may not like either one, but I claim this is portable. And, it is >meaningful to me. But it *is* bad practice, in a measurable sense: you are using a style which is indistinguishable from a bug. As a result, you cannot easily use lint to find *real* bugs, because you've introduced so much noise in the lint output. You're throwing away a useful tool unnecessarily. >I find it terribly ugly having to cast printf's or close's to void. Me too. But let's not lump all the cases together: [0] strcpy() returns a value that can be safely ignored. (Although I often find that I can use it in the next statement anyway.) [1] printf() returns a number which is normally pretty useless. It does also have an error return, but if you're writing to the terminal it's pretty safe to ignore that too. (Especially fprintf(stderr). What can you do if it fails, print an error message?) [2] close(), as near as I can tell, can only fail by being handed a number that does not denote an open file. I usually assume that this error would have been caught earlier. [3] unlink() and most other system calls should be checked! (It's too bad lint can't tell whether you've tested the return value of open(), etc.) My "solution" for [0]-[2] is simply to check the bottom of the lint output for "result ignored" messages, and decide which ones are serious. ("lint returns an error which is always ignored" :-) >And as someone pointed out, assignments return a value too, so should we >cast them to void as well? Oh yeah, assignment is `different'. Actually, this does bother me somewhat. I think I prefer the idea that values should be used or explicitly discarded, as in forth. (Not that forth has any error checking!) No, I'm not suggesting that lint should complain about assignments, or that C should have a different notation for assignments that are being pipelined into another expression. Just waiting for the next generation of languages. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
kwh@bentley.UUCP (KW Heuer) (05/09/86)
In article <592@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >> C is the only language that I can remember that has a separate >> program (lint) to find and report compiler errors in source code. > >First, the errors detected are not COMPILER errors but CODING errors. >Second, [examples of other languages] >Third, "lint"ing is not necessary on every compilation. >Fourth, on small systems ... [it's better than] complicated multi-pass. >Fifth, "lint" is rather portable, [but cc] is inherently machine-dependent. Moreover, because lint is an optional pass which doesn't produce code, it's safe for it to be overly conservative and flag "errors" which might be okay. For example, the "possible pointer alignment problem" which results from any nontrivial cast of malloc(). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
lindsay@cheviot.uucp (Lindsay F. Marshall) (05/09/86)
In article <601@brl-smoke.ARPA> gwyn@brl.ARPA writes: >Coals to Newcastle. I'll thank you not to talk about us in that way!!
peter@baylor.UUCP (05/10/86)
> One of the more traumatic things about being exposed to unix after working > with numerous other systems was that the stupid c compiler refused to give me > a nice clean listing with source, interspersed error messages, and optional > object code. I'm not dumb, but trying to learn a debug a big program though > a 24-line window and my memory just doesn't make it... On the other hand, I found VAX/VMS 'C' a real pain after UNIX because it put all the error messages in this huge ugly listing instead of a brief list so I could find them. Of course the stupid bloody editor that didn't have a shell escape or any sort of facility for editing multiple files didn't help. Just because you're used to a compiler-generated listing doesn't mean it's the only way to go. Of course, a list of errors may not be either... though a utility like "error" (which puts the error messages into the original source as comments: something not feasible with the huge listing method) can really addict you to UNIX *fast*. -- -- Peter da Silva -- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076
gmp@rayssd.UUCP (G.M. Paris) (05/11/86)
> You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell <rbj@cmr> > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++--------------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++
steve@warwick.UUCP (Steve Rumsby) (05/12/86)
In article <797@bentley.UUCP> kwh@bentley.UUCP writes: >In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >>I have ranted about C using a one statement model for its control >>statements instead of an explicit end statement. Compound statements are >>bounded by braces instead. Yuk! > >Ah yes, there are two major types of language in the structured family; >f77 with "endif" (some members use "end" for all of "endif", "endwhile", >etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I >presume this is what you dislike. (If it's the spelling that bothers you, >I'm sure you're aware that you can define "begin" and "end" as macros.) > >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) > Occam uses this model to delimit its blocks. It's a nice idea - no more adding {/} around an if's "then" or "else" part simply because you've changed it from one statement to two. Consistency like this can save a lot of time looking for missing braces, etc. However, you do have to be *very* careful with the space bar. One space in the wrong place can also be a bit irritating to find, especially if you can't use vi/emacs to match them for you like you can with {/}! Couldn't you write a small(?) filter which would let you write C without braces and fill them in for you from the indentation? It doesn't seem too difficult. (No I'm not offering to do it). Steve. -- Steve Rumsby. UUCP: ...!ukc!warwick!steve JANET: steve%warwick.uucp@uk.ac.warwick.daisy ARPA: steve%warwick.uucp@ucl-cs.ARPA BITNET: steve%warwick.uucp%uk.ac.warwick.daisy@uk.ac
dgary@ecsvax.UUCP (D Gary Grady) (05/12/86)
In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >Yet another convention, not endorsed by any language I know, is to dispense >with the braces and let the indentation alone tell the compiler how to >interpret the program. (I came up with this idea after an argument on the >"correct" place to put the braces.) As several people have pointed out, this convention is used in some languages. I just wanted to point out an instance no one has mentioned yet: IBM's ISPF, a mainframe 3270 screen management package that allows you to define a "panel" with associated procedural information. You find things in the oddest places... -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
garys@bunkerb.UUCP (Gary M. Samuelson) (05/13/86)
In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >[2] close(), as near as I can tell, can only fail by being handed a number > that does not denote an open file. I usually assume that this error > would have been caught earlier. Assuming a buffered device, the last block of data will not be physically written until close(), in which case nearly all of the errors possible with write() could occur with close(). >[3] unlink() and most other system calls should be checked! (It's too bad > lint can't tell whether you've tested the return value of open(), etc.) ??? Lint certainly can check for that (at least the lint I use); it says something like "open returns value which is sometimes ignored" (or "always", as the case may be). It does this by checking the definition of open() in /usr/lib/lint >"lint returns an error which is always ignored" :-) This is going to my collection of classic quotes. From Jim Cotrl (yes, I know the spelling is wrong, but after all, think of all the keystrokes I saved): >>And as someone pointed out, assignments return a value too, so should we >>cast them to void as well? Oh yeah, assignment is `different'. If I say "a = b", I have clearly used the value of the expression. Gary Samuelson
ka@hropus.UUCP (Kenneth Almquist) (05/13/86)
> Yet another convention, not endorsed by any language I know, is to dispense > with the braces and let the indentation alone tell the compiler how to > interpret the program. (I came up with this idea after an argument on the > "correct" place to put the braces.) I first encountered this idea about 8 years ago, when Dave Korn used it in a specialized language for data checking, and it is a good one. Using braces to indicated the structure of a program results in code that is quite difficult to read. (Try removing all indentation from any C program you choose and see how readable the result is.) Of course sensible programmers use indentation to indicate the structure of the program to the reader. So from the reader's point of view braces are just useless clutter. Thus the C language forces the programmer to use two separate methods of indicating the structure of the program, one for the benefit of the reader and the other for the benefit of the compiler. Given that the compilers can fairly easily be written to understand about indentation, there is no justification for requiring programmers to translate the indentation information into brace form by hand, with the attendent risk of errors. Furthermore, Jim has correctly pointed out that the braces actually obscure the code for the human reader, since they add clutter without providing any new information about the program. In fairness, C is better than most languages in this respect since it reduces begin and end to single characters. This is good enough that I do not agree with the extremes to which Jim goes to avoid braces. But C doesn't take the idea to its logical conclusion, which is to eliminate the delimiters entirely. Fortunately, grouping by indentation has finally been adopted by at least on language. See the article on "Modcap" in the March issue of Sigplan Notices. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
rbj@icst-cmr (Root Boy Jim) (05/14/86)
> In article <501@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > >I have ranted about C using a one statement model for its control > >statements instead of an explicit end statement. Compound statements are > >bounded by braces instead. Yuk! > > Ah yes, there are two major types of language in the structured family; > f77 with "endif" (some members use "end" for all of "endif", "endwhile", > etc.) and pascal with "begin" "end" (which C abbreviates to "{" "}"). I > presume this is what you dislike. (If it's the spelling that bothers you, > I'm sure you're aware that you can define "begin" and "end" as macros.) Well C certainly makes the spelling less verbose, but that is not my complaint. The first structured language I came across (SIMPL-T at U of Md) used the notation `IF <condition> THEN <list> { ELSE <list> } END'. This has become my personal favorite paradigm for if statements. In fact, the syntax of all control statements was almost entirely similar to that used by the Bourne shell, except that END ended any kind of block. This is superior to the `one statement' (braces, BEGIN-END, etc) style because it explicitly delimits where the else statement goes. It is also easier to parse. > Yet another convention, not endorsed by any language I know, is to dispense > with the braces and let the indentation alone tell the compiler how to > interpret the program. (I came up with this idea after an argument on the > "correct" place to put the braces.) This is too scary, even for a scofflaw like myself. I don't trust white space, and you give up the ability to `cb' or `indent' it. > >Fortunately, there is the comma operator. This allows the following: > > Most People Your's Truly > > if (c) { if (c) > > w = y; w = x, > > y = z; y = z; > > } /* look ma, no brace */ > > I can hardly flame you for this, since I've used it myself when in a hurry. > (But I write it on one line, "if (c) w=x, y=z"). I usually end up rewriting > it with braces, though. I often do myself. EMACS C-mode adds them for you automatically, so I guess it's not much of an issue for some people. > >Other things you will see in my code are: > > exit((printf("usage: foo bar\n"),1)); > >or even: exit(1,printf("usage: foo bar\n")); > > What's wrong with > printf("usage: foo bar\n"), exit(1); > as above? Oops, I goofed royally. BTW, I didn't notice that I needed the extra parens in the first example until I posted it. Another example of why not to use tricks. Silly rabbit :-) > >Sufficeth to say that I use a lot of commas in my code. Unfortunately, > >I cannot do this if either statement is a control struxure, *except* return. > > Most People Your's Truly > > if (c) { if (c) > > w = y; return w = x, > > return; > > } /* look ma, no brace */ > > You're introducing a minor inefficiency, since the compiler will have to > copy the result of the last expression into the return register. I presume > you don't bother to declare void functions "void", either, or this wouldn't > make it past the compiler. I hadn't even thought of that. In my defense I will have to mention that 1) the expression may have already been computed in R0 anyway, 2) `tis a small matter, & 3) the attempt is to optimize cranial time rather than execution time. The statements of the left side are starting to get verbose, while the ones on the right side, especially if written on one lline, are simple and to he point. It might take you a bit to get used to the convention, but it's not that difficult. As for void, it didn't exist on the compiler I first used. Even BSD has problems with pointers to functions returning voids (did I get it right?) so I avoid them. It is easier just to default it to int, never return anything (or use my convention), and ignore the value. That's right, easier, not better. I'm lazy. Generally, tho, I find that I don't make *that* kind of mistake too often, so why bother? It all comes down to what you gain versus what you put out, and have to read for all eternity. > >I cannot see *any* implementation doing either of the following: > > 1) barfing because I returned an *extra* value sometimes > > 2) barfing because I added an extra argument >> > You're probably correct in that all implementations that accept your code > will produce correct results; however, I can easily imagine a compiler that > would refuse to compile such an "obvious bug". Not true. The first case is required to be supported so that I can ignore a value (strcpy, eg) if I choose. The second is required to support printf. > >Now you may claim that this is `bad programming practice', but I claim > >that it is just a convention, just like #defines are usually capitalized. > >You may not like either one, but I claim this is portable. And, it is > >meaningful to me. > > But it *is* bad practice, in a measurable sense: you are using a style which > is indistinguishable from a bug. As a result, you cannot easily use lint to > find *real* bugs, because you've introduced so much noise in the lint output. > You're throwing away a useful tool unnecessarily. I see your point. I first ran lint after I had a few thousand lines of code written, and it barfed unmercifully. Before that, I had attempted to run it but the permission bits were set wrong for some files. Only root could run it. By the time I figured out why, I had a bad taste in my mouth. Also, reading the documentation left me unexcited. Maybe I will give it another try someday. I'll probably point it at net.sources. I find I can get along okay without it. That is my whole point. It's not lint that bothers me, it's the people that think it's a panacea for everything. Actually, I am pleased by the mixed reaction I received. About half of the articles I've seen make this point as well. I do prefer the way it fits into the language tho. It's there when you need it but not shoved down your throat by run-time or compile-time checks. > >I find it terribly ugly having to cast printf's or close's to void. > > Me too. But let's not lump all the cases together: > > [0] strcpy() returns a value that can be safely ignored. (Although I often > find that I can use it in the next statement anyway.) > > [1] printf() returns a number which is normally pretty useless. It does also > have an error return, but if you're writing to the terminal it's pretty > safe to ignore that too. (Especially fprintf(stderr). What can you do > if it fails, print an error message?) > > [2] close(), as near as I can tell, can only fail by being handed a number > that does not denote an open file. I usually assume that this error > would have been caught earlier. I meant to say `fclose', which can write data and thus barf too. > [3] unlink() and most other system calls should be checked! (It's too bad > lint can't tell whether you've tested the return value of open(), etc.) Mostly. But sometimes you don't care if the file you are trying to unlink or the descriptor you are trying to close doesn't exist. > My "solution" for [0]-[2] is simply to check the bottom of the lint output > for "result ignored" messages, and decide which ones are serious. ("lint > returns an error which is always ignored" :-) Right. Grep -v helps here too. > >And as someone pointed out, assignments return a value too, so should we > >cast them to void as well? Oh yeah, assignment is `different'. > > Actually, this does bother me somewhat. I think I prefer the idea that > values should be used or explicitly discarded, as in forth. (Not that forth > has any error checking!) No, I'm not suggesting that lint should complain > about assignments, or that C should have a different notation for assignments > that are being pipelined into another expression. Just waiting for the next > generation of languages. The explicitness comes in the source code. Why do you find it so hard to believe that I meant what I said? > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Root Boy) Jim Cottrell <rbj@cmr> The Sitting Lint Maker
chris@umcp-cs.UUCP (Chris Torek) (05/15/86)
In article <640@bunkerb.UUCP> garys@bunkerb.UUCP (Gary M. Samuelson) writes: >If I say "a = b", I have clearly used the value of the expression. Which expression? `b', certainly, but what about the value of `a = b'? The problem is that there really are several `kinds' of expressions in C. All expressions have values; but some are more useful than others. The following are grouped into `error' and `non-error' classes: Error: Non-Error: open("foo", 1); strcpy(hold, s); a + 1; a++; My best guess at the moment at the `true' distinction between the `error' and `non-error' classes is that the latter `end' in side effects. The return value from `open' is usually as important as its side effect; but that from strcpy() is often not. `a + 1' has no side effects in most cases (one where it might is if integer overflow traps are enabled); `a++' has a clear side effect. So perhaps lint needs, in addition to /*VARARGS*/ and /*ARGSUSED*/, and the System V style /*PRINTFLIKE*/, another pragma: /*FORSIDEEFFECTS*/. Routines like strcpy(), strcat(), and perhaps even close(), would be so declared in llib-lc. This would tell lint that the return value, though available, was purely for convenience: that the function is normally called simply for its side effects. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
tainter@ihlpg.UUCP (Tainter) (05/15/86)
>>>And as someone pointed out, assignments return a value too, so should we >>>cast them to void as well? Oh yeah, assignment is `different'. >If I say "a = b", I have clearly used the value of the expression. > Gary Samuelson No. You have only used the value of the expression "b", not the expression "a = b" (which happens, by definition, to return the value of the expression "b"). The argument stands. The principle behind ignoring, even meaningful, return codes is: I don't have any particular response to this error so I will fall back on whatever default error handling the system provides. Admittedly, this is not the desired response when what is being written is a general tool. ROBUSTNESS provides GENERALITY but costs DEVELOPMENT TIME. --j.a.tainter
peters@cubsvax.UUCP (Peter S. Shenkin) (05/15/86)
In article <baylor.643> peter@baylor.UUCP writes: >> One of the more traumatic things about being exposed to unix after working >> with numerous other systems was that the stupid c compiler refused to give me >> a nice clean listing with source, interspersed error messages, and optional >> object code. I'm not dumb, but trying to learn a debug a big program though >> a 24-line window and my memory just doesn't make it... > >On the other hand, I found VAX/VMS 'C' a real pain after UNIX because it >put all the error messages in this huge ugly listing instead of a brief >list so I could find them. Of course the stupid bloody editor that didn't >have a shell escape or any sort of facility for editing multiple files >didn't help. What I'm waiting for is an interactive interpretive debugger that runs from vi. The program would run interpretively until an error was encountered, then place you at the appropriate line in the source file with the error message displayed. Then you could go into insert mode, make the necessary change, and resume execution. Normally interpreted languages, like APL, often have such facilities. Are there insuperable difficulties with doing this with a normally compiled language like C? (I'm sure it could be done with FORTRAN, since FORTRAN interpreters are well-known... but why have we seen no C interpreters?) Seems to me a few years ago some people on the net from Harvard were trying to implement this concept or one similar to it. Whatever happened? Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
rbj@icst-cmr (Root Boy Jim) (05/15/86)
> In article <501@brl-smoke.ARPA>, rbj@icst-cmr (Root Boy Jim) writes: > > Most People Your's Truly > > > > if (c) { if (c) > > w = y; w = x, > > y = z; y = z; > > } /* look ma, no brace */ > > There is an excellent, excellent book, which everybody should > read, called The Elements of Style, by William Strunk and E. B. > White. It is about writing in English, but almost everything in > it applies to writing in programming languages as well. One of > my favorite quotes (from page 74 of the third edition) is > > "In ordinary composition, use orthodox spelling. Do not > write "nite" for "night," "thru" for "through," "pleez" > for "please," unless you plan to introduce a complete > system of simplified spelling and are prepared to take > the consequences." Attacking me on both fronts, eh? Well GFY! These people are obviously more conservative than I choose to be. After all, don't we hear enuf people screaming about UUCP transmission isn't free? Well, I am just helping out in my own little way :-). What kind of a person would let the way someone spells bother them? You must have awfully thin skin. Worry about something that makes a difference for a change. After all, you *do* understand me don't you? > The consequences, of course, are that in virtually all cases you > will be laughed out of the room. Convention has a place. True. When you start following mine I'll start following yours. For example, I happen to think that all code should be formatted such that all funxions fit on a page. This is a good idea, but one I seldom see adhered to. You're laughing? So what? I'm laughing at you for getting stuck on an insignificant detail. Since you don't have anything real to say, you're attacking the style, not the substance. > You are not being a sheep or a lemming if you do things the way most > people do things; you are being responsible. C can be hard > enough to read when it is formatted "correctly;" we certainly > don't need any more unorthodox methodologies floating around. I didn't make this style up just to be ornery. My whole point is that the delimiting style chosen by the authors of the language left a little something to be desired. Bourne's macros fixed this. And yet, some people complained about them. > Proponents of things like "look ma, no braces" will claim that > theirs is not "ordinary composition," and that they are therefore > exempt from generally accepted programming practices. This > statement is in fact perfectly true. If you want to be a rugged > individualist and program in a vacuum; if nobody else ever reads > your code; if only you have to maintain it or port it to other > machines; then you are certainly welcome to make each program you > write an odds on favorite for the winner's circle in the > Obfuscated C Contest. However, do the rest of us a favor and > perfect your isolated environment by sparing this newsgroup from > your rantings and ravings. Hey, lighten up pal. Most of the `examples' I posted I have given up long ago. Even with the comma trick, sooner or later you're going to want to add a control statement that forces the braces. I just get tired of all you sanctimonious zealots that insist upon quoting the party line on everything. It makes me ornery. You can't please everyone all of the time. And you can't expect people to please you either. All you can do get off on the common ground, while putting aside the (minor & insignificant) differences. I quit trying to please everyone else long ago. That's your job. As for sparing you, I just might do that. I'm getting pretty sick of these discussions and I haven't seen anything new for awhile. > Steve Summit > tektronix!copper!stevesu (Root Boy) Jim Cottrell <rbj@cmr> "You used to laugh about Everybody that was hanging out"
gwyn@BRL.ARPA (VLD/VMB) (05/16/86)
You seem to have missed a key word in my posting. I urged "a proper job of analysis and design" before coding. A proper job of systems analysis addresses the issues you raised. Structured software development even encourages early hands- on use of prototypes, to REFINE the design, not to try to ARRIVE at a design by trial-and-error. There IS a lot of knowledge about user interaction; like structured software development, however, few practitioners appear to have bothered to study it.
kwh@bentley.UUCP (KW Heuer) (05/16/86)
In article <287@euclid.warwick.UUCP> warwick!steve writes: >Couldn't you write a small(?) filter which would let you write C >without braces and fill them in for you from the indentation? It >doesn't seem too difficult. (No I'm not offering to do it). I almost wrote such a filter when I first got this idea, but there wasn't enough interest. No, it isn't difficult -- a short awk script could do it, I think. I guess for continuation lines you'd have to either start flush with the previous line, or use a continuation character (backslash). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
kwh@bentley.UUCP (KW Heuer) (05/16/86)
In article <640@bunkerb.UUCP> bunkerb!garys (Gary Samuelson) writes: >In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>(It's too bad lint can't tell whether you've tested the return value of >>open(), etc.) > >??? Lint certainly can check for that (at least the lint I use); it says >something like "open returns value which is sometimes ignored" By "open(), etc." I meant the class a functions which return a useful value even when they succeed. For example, lint does *not* catch the following: fp = fopen(fname, "r"); c = getc(fp); which is a potential error because fopen() could return NULL. Trouble is, even if lint knew that fopen had such an error return, it would have to know whether getc() is prepared to handle it (it isn't). Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
franka@mmintl.UUCP (Frank Adams) (05/17/86)
In article <6667@utzoo.UUCP> henry@utzoo.UUCP writes: >> All too often, one sees programmers writing code before >> a proper job of analysis and design has been done. I >> also believe that is partly because semi-running code >> makes it appear as though progress has been made, >> while a complete design doesn't convey the same impression. > >Sorry, Doug, I can't let that one go by. > >All too often, one sees programmers writing detailed design specifications >before writing any code. > >The alternative is to recognize that (a) the user probably does not have >a complete and coherent idea of what he needs, and hence cannot write a >spec or meaningfully assess one you write, and (b) in any case, the presence >of the software itself will change the user's tasks and therefore his needs. >Given recognition of this situation, it is not even theoretically possible >to avoid a trial-and-error process of software development. Hence you >should aim to make your inevitable mistakes as early as possible. Which >puts a heavy premium on getting initial prototype software into the hands >of the customers right away, so that you can learn what's wrong with it. >One progresses by iteratively enhancing (and perhaps sometimes re-doing) >the prototype, with regular user feedback. Sorry, Henry, I can't let that one go by. Your points about the lack of definition of the task are well taken, but your solution doesn't work very well for large or even medium-sized projects. The problem is that you fairly quickly wind up with very bad code, and spend inordinate amounts of time making relatively small changes. Yes, I know you said "sometimes re-doing", but that is often impossible, under the press of circumstance. What I think works better (and I don't know of anything which works really well) is to do an initial design which is as flexible as possible (keeping speed considerations in mind). Then, with a little luck, when the user comes back and wants you to do it differently, you can make a fairly small, clean fix. Of course, they usually manage to come up with a variation in a direction you never even contemplated, and you're back at square one. On another level, design first is likely to produce something you can show the customer sooner than plunging right in, for large and medium-sized projects. Beyond a certain minimum size, design/code/debug is faster than code/debug. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
greg@utcsri.UUCP (Gregory Smith) (05/17/86)
> Yet another convention, not endorsed by any language I know, is to dispense > with the braces and let the indentation alone tell the compiler how to > interpret the program. (I came up with this idea after an argument on the > "correct" place to put the braces.) COBOL has something which is very similar from a compiler-writer's point of view - hierarchal data structures are described by giving each member a 'level number' - map 'level numbers' onto indentation columns, and both systems are the same. To describe an 'indentation structured' language as a grammar, you could introduce the terminals 'indent_more' and 'indent_less' which could be generated by a lexical analyzer, and would effectively replace { and }. What about the following sort of thing, though ? ( this is how I would write it in normal C ): ... if( vogsphere == fuddle && !blasted ){ while( sixteenvalvedualoverheadcam( bleen ) == '?') infriddle( batman.utility_belt ); if( total_confusion_estimated > MAX_CONFUSION ) printf( "Well I think you ought to know that I am getting really confused by %s\n", reason_for_confusion[WOMBAT] ); return SAY_WHAT; }else post_to_net_lang_c( silly_stuff_like_this ); >:-) -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
craig@comp.lancs.ac.uk (Craig Wylie) (05/19/86)
In article <456@hropus.UUCP> ka@hropus.UUCP writes: >> Yet another convention, not endorsed by any language I know, is to dispense >> with the braces and let the indentation alone tell the compiler how to >> interpret the program. (I came up with this idea after an argument on the >> "correct" place to put the braces.) > >I first encountered this idea about 8 years ago, when Dave Korn used it >in a specialized language for data checking, and it is a good one. > >Using braces to indicated the structure of a program results in code that >is quite difficult to read. (Try removing all indentation from any C >program you choose and see how readable the result is.) Of course >sensible programmers use indentation to indicate the structure of the >program to the reader. So from the reader's point of view braces are >Fortunately, grouping by indentation has finally been adopted by at least >on language. See the article on "Modcap" in the March issue of Sigplan >Notices. It is also the method used in the languages OCCAM and Miranda. The method of grouping follows something called the offside rule, I will post the reference (read dig it out of my filling cabinet) if any body mails me for it. Craig. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4146 | LA1 4YR Project: Cosmos Distributed Operating Systems Research Group
rbj@icst-cmr (Root Boy Jim) (05/19/86)
From info-c-request@BRL.ARPA Fri May 16 00:24:39 1986 Received: from BRL-SMOKE.ARPA (brl-smoke.arpa.ARPA) by icst-cmr.ARPA (4.12/4.7) id AA20984; Fri, 16 May 86 00:24:35 edt Received: from USENET by SMOKE.BRL.ARPA id a007113; 15 May 86 21:45 EDT From: "G.M. Paris" <rayssd!gmp> Newsgroups: net.lang.c Subject: Re: Re: questions from using lint Message-Id: <2235@rayssd.UUCP> Date: 11 May 86 18:22:19 GMT Sender: "Gregory M. Paris @ Raytheon Co., Portsmouth RI" <rayssd!gmp> To: info-c@brl-smoke.arpa > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell <rbj@cmr> > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++--------------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++
bright@dataioDataio.UUCP (Walter Bright) (05/19/86)
In article <473@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: >What I'm waiting for is an interactive interpretive debugger that runs from >vi. The program would run interpretively until an error was encountered, >then place you at the appropriate line in the source file with the error >message displayed. Then you could go into insert mode, make the necessary >change, and resume execution. Normally interpreted languages, like APL, >often have such facilities. Are there insuperable difficulties with doing >this with a normally compiled language like C? (I'm sure it could be done >with FORTRAN, since FORTRAN interpreters are well-known... but why have we >seen no C interpreters?) Major difficulties are: 1) The preprocessor. At any line, a macro could be changed, which could change the meaning of the entire remainder of the source text. This means that 'incremental compiles' becomes 'compile from here to the end of the source text'. Of course, that means the parser must have the state of the parse saved at every line..., which obviously is impractical. 2) C isn't line oriented. This means that any line could be any part of a statement or expression. Thus, the parser must be able to back up from any point to find a 'synchronization point'. But C isn't backwardly parseable... Why BASIC and FORTRAN can be handled this way: 1) They don't have a preprocessor. 2) They are line oriented. All the parser has to do is back up to the beginning of the line (or in FORTRAN to the first line that isn't a line continuation). 3) Each line is more or less independently parseable from the rest of the program. Conclusion: The only fully functional, practical way is to do a reparse of the complete source file upon any changes (even on whitespace changes). Turbo Pascal works this way, instead of attempting to incrementally compile, Borland spent their efforts making the compile step really fast. An incremental compiler could be made if numerous assumptions and restrictions were made about what could be changed. I think the bugs and kludges that would result would make it impractical, however.
rbj@icst-cmr (Root Boy Jim) (05/20/86)
> You people fail to realize that some of us out here don't like lint. > It complains too much about what I do. I refuse to go any further > than generating no compiler warnings. I know what I'm doing. When I > goof, I'll fix it myself. I refuse to add extra casts to keep lint > happy. > > Before you start flaming my style, let me say I am quite good. > I am also quite philosophical and attentive to coding style. > My outlook is just different. I program for myself. If it is applicable > to you, fine. I have my own criteria which I rarely see embraced by > others waving standardization flags. > > Most of the code I have written was intrinsically non-portable. I *do* > appreciate portability as a spectrum concept, but not as a binary one. > > This is just me. I'm not sure I would recommend my methods to anyone > else, especially novices. My experience was obtained with more than a > few battle scars. There are probably easier ways. > > (Root Boy) Jim Cottrell <rbj@cmr> > "I'm alright, Jack, keep your hands off of my stack" Sorry I enclosed so much of the original article above, but I found it so surprisingly bizzare, I just couldn't leave any of it out. I have two things to say about it: 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never recommend him being hired as a programmer, anywhere. -- ++------------------------------------------------------------------++ || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++------------------------------------------------------------------++ Where's the rest of me? I sent out a flame with this, but it must have disappeared. Oh well, here it is: For all of you who have ROT13 software, you will know what to do with this: Tb Shpx Lbhefrys! And for those of you who don't like my spelling, at least it's deliberate. This cretin doesn't even know how to spell `bizarre'. Buddy, I forgot more than you'll ever know. (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"
liam@cs.qmc.ac.uk (William Roberts) (05/20/86)
In article <169@comp.lancs.ac.uk> craig@comp.lancs.ac.uk (Craig Wylie) quotes: >>Using braces to indicated the structure of a program results in code that >>is quite difficult to read. (Try removing all indentation from any C >>program you choose and see how readable the result is.) Of course >>sensible programmers use indentation to indicate the structure of the >>program to the reader. I use programs like "cb" and "indent" to get my C programs indented according to what they *REALLY* mean, as opposed to what I intended them to mean (indicated by MY indenting). This can be quite illuminating.... -- William Roberts ARPA: liam@UK.AC.qmc.cs Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK
Makey@LOGICON.arpa (Jeff Makey) (05/21/86)
> [Steve Summit politely quotes "The Elements of Style" when > criticizing Jim Cottrell's abuse of English and C.] Jim flames back: > Attacking me on both fronts, eh? Well GFY! . . . What kind of a > person would let the way someone spells bother them? . . . After > all, you *do* understand me don't you? Jim's abuse of English (e.g., his use of the letter "x") is not only poor communication, it is discourteous. It is poor communication because it draws attention to the wrong words in his sentences (imagine random use of italics). It is discourteous because it makes *me* (and hundreds of other people) waste mental effort trying to understand what he is writing. Sure, it's cute the first time you see it, but (just like being told for the 50th time that your shoe is untied when it isn't) it gets downright annoying after awhile. A quote from Jim: > I program for myself. If this was true then Jim's programming style would be of no concern to me or anyone else. Unfortunately, other people sometimes have to make changes to Jim's code. I found myself in this position about a year and a half ago when I attempted to fix a bug in a version of the "more" program Jim had left behind when he left the company I work for. Imagine my dismay when the program turned out to be written in some strange "language" with keywords such as BEGIN, ENDWHILE, etc. instead of in C. All of the #defines were there, but it would have taken just too much effort to learn it this "language". (I'm no Bozo. C is at least the 8th computer language I've used in the last 11 years.) I gritted my teeth and let the bug live. As the saying goes, Real Programmers can write FORTRAN code in *any* language. I'm not accusing Jim of writing FORTRAN code in C, but I *am* accusing him of using wonderful, obscure programming tricks instead of common techniques that are much easier to understand (and are sometimes more efficient). It's really neat once you've figured out what the trick is, but you've just spent 3 hours analyzing 40 lines of code. More from Jim: > You can't please everyone all of the time. And you can't expect > people to please you either. All you can do get off on [sic] the > common ground, while putting aside the (minor & insignificant) > differences. I quit trying to please everyone else long ago. Things that are minor and insignificant to one person can be very important to somebody else (one man's code is another man's design specification). The question seems to be: does Jim try to please *anybody* besides himself? Jim's arrogance emphasizes his immaturity, and as long as he behaves that way I will have to firmly agree with Greg Paris, who said: > 1) I'm glad that Mr. Cottrell doesn't work here; 2) I'd never > recommend him being hired as a programmer, anywhere. Jim's flaming ROT13 reply to this (I didn't need any software to see that it decrypted to the expansion of "GFY", an acronym Jim likes to use when he has lost an argument) just reinforces Greg's statement. > (Root Boy) Jim Cottrell <rbj@cmr> > "You used to laugh about > Everybody that was hanging out" "People call, Say ''beware, doll, You're bound to fall.'' You thought they were all Kidding you." :: Jeff Makey Makey@LOGICON.ARPA The opinions expressed above are solely my own.
henry@utzoo.UUCP (Henry Spencer) (05/22/86)
One (relatively minor) defect of grouping by indentation is that it is
sometimes useful to use indenting violations to flag unusual situations.
The obvious example is a classic one: temporary debugging code not
indented at all, to make it easy to find and remove later.
More seriously, any grouping-by-indenting scheme should be studied carefully
for ways in which minor typos could seriously alter the meaning of the
program in non-obvious ways.
--
Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology
Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (05/23/86)
> Yes, I know you said "sometimes re-doing", but that is often impossible, > under the press of circumstance. The press of circumstance must be firmly resisted if it's going to lead to shoddy work. I agree that there is considerable incentive to get things close enough to correct that major revision at the last minute isn't needed. > ... Beyond a certain minimum size, design/code/debug is faster than > code/debug. Ah, but is design/code/debug/release/withdraw/revise/really-release faster than code/debug/try/code/debug/release? :-) More seriously, I do acknowledge the need to have some idea of where you're going before you set out to get there. And the degree of advance planning needed is indeed a function of project size. But getting where you're going and then discovering that you really want to be somewhere else should be treated as a predictable part of the development process, not as a rare and surprising exception. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jc@cdx39.UUCP (John Chambers) (05/23/86)
> ... I happen to think that all code should be formatted such > that all funxions fit on a page. This is a good idea, but one I > seldom see adhered to. Not only do I agree, but I even think that all funxions (and even prosejurz) should fit into one screen-full. I mean, I can really only understand what I can have sitting before my eyeballs at one time. Do I follow my own advice? Are you kidding? Of course, it is easier with a 100-by-100 screen than with a 16-by-32 screen. [OK, so a screen-full IS just another kind of a page. I admit it.] -- John M Chambers (617-364-2000x7304) / cthulhu \ /usenet / inmet \ / news ...!{ harvax }!cdx39!{ jc \ mit-eddie / \ uucp \ mot[bos] / \root
bzs@bu-cs.UUCP (Barry Shein) (05/25/86)
Re: To design then code, code then design, a little of each iteratively? etc. Obviously it depends on the problem, let's ignore the trivial cases. One major consideration to always take into account is "who is the customer?" When I am programming something by request/contract of someone else a whole different set of rules come into play. Before I start coding the User's Manual is written, delivered to the 'customer' and agreed to, preferably in writing. 99% of the heartache I've encountered in coding for someone else had to do with delivering the more or less finished product and having the "customer" suddenly get this surge of creativity upon playing with the program (gee, why can't you make a "few little changes" to...) At least I can point to the User's Manual that was signed off and possibly at that point offer to negotiate a new project. They don't like it, but they can usually understand it. If there are other potential complexities I would go for a Maintainer's (or System Administrator's) guide. This was important in one case where I was building a data-base system and I sincerely felt they did not understand that they needed more disk to do what they wanted. I sent over some pre-docs with "worksheets" to estimate disk needs and asked them to please have someone work through them with me a little as in conversations I saw them waving their hands and all they seemed to be thinking about was the price of the disk(s). And so on... I think the most dangerous thing that happens to a program that did not have enough aforethought is the sudden realization that the data structure(s) involved were not powerful enough to do the job, this can ripple through an entire software system and practically require ground-up re-write. I've had it happen. With the hope of not immediately starting the obvious flame-fest, people who code in FORTRAN are most liable to this failure as they are strongly motivated to make every problem work in terms of scalars and arrays. Not that they *can't* represent a binary tree, but because of the unnaturalness of that in FORTRAN they will tend to try to ignore that option until it is too late. Often if FORTRAN is their only language they aren't very sophisticated in recognizing the problem, but that's another issue. Generally, in a reasonably well-coded program the algorithms are fairly easy to replace (how hard would it be to change sort methods for example) as it involves re-writing a specific module and generally leaving the rest alone. A change in data structures, however, can almost never be localized in effect. At the very least, besides the issue at hand, input and output (and storage/retrieval) routines usually have to be re-written. The conclusion would be, therefore, design your data structures carefully and with aforethought. If you don't want to design all the algorithms beforehand keep things modular and recognize what pieces you may want to replace later. TRAP: Changing the algorithm CAN sometimes demand changing the data structure. When in doubt, sketch it out. In defense of the iterative process this is often actually used to explore possibilities to use in the design. If the code used in the "experiments" happens to get used in the final project, all the more better, but don't let the tail wag the dog. -Barry Shein, Boston University
bzs@bu-cs.UUCP (Barry Shein) (05/25/86)
Re: User wants interactive, interpreted environment for C development I believe the product SAFE/C from Catalytix Corp (Cambridge, MA?) provides this. I have never used it but from what I have read and heard (a friend was one of the developers) that is the basic idea of the product. If someone has used this product I would be interested in your impressions. It is available on a variety of machines and I believe is meant to be portable but the marketing interest would probably have to be there, I dunno, ask em. I think the main problem I would expect from such a product would be the memory model. I suspect that memory management errors (eg. over-running a malloc()'d area) could be hard to detect within the interpreted environment unless carefully and specifically checked for (in which case, what if I *want* to do some sort of overlaying/equivalencing.) The point is (forgive me) that in the interpreted environment things would point around differently than in the final compiled environment. This is one reason why the lack of explicit pointers in LISP is a good thing (I know, most lisps can allow an internals person to do an (addr x), but it is highly disrecommended for several reasons in a program.) I remember speaking about this with my friend when he was developing and, although he agreed that yes indeed, that's a problem, they had some compromise (I forget, maybe something like enabling/disabling intensive checking with lintish /*SCREWMEM*/ statements, or maybe that's just what they were considering at the time, this goes back a coupla-few years.) I believe one of the main goals of the product was to provide extensive run-time checking during development/testing. -Barry Shein, Boston University
greg@utcsri.UUCP (Gregory Smith) (05/26/86)
In article <890@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > >Attacking me on both fronts, eh? Well GFY! ... Good For You? > (Root Boy) Jim Cottrell <rbj@cmr> > "You used to laugh about > Everybody that was hanging out" Now you don't talk so loud... -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
franka@mmintl.UUCP (Frank Adams) (05/26/86)
In article <6716@utzoo.UUCP> henry@utzoo.UUCP writes: >More seriously, any grouping-by-indenting scheme should be studied carefully >for ways in which minor typos could seriously alter the meaning of the >program in non-obvious ways. I agree, but: why should this be done for grouping by indentation, when it isn't done for any other language features? (When was the last time you wrote "=" instead of "=="?) Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
franka@mmintl.UUCP (Frank Adams) (05/26/86)
In article <6726@utzoo.UUCP> henry@utzoo.UUCP writes: >> ... Beyond a certain minimum size, design/code/debug is faster than >> code/debug. > >Ah, but is design/code/debug/release/withdraw/revise/really-release faster >than code/debug/try/code/debug/release? :-) But now you're arguing about a different part of the process. What I want is design/code/debug/try/[re-design]/code/debug/release. This often is faster than leaving out the design phase. >More seriously, I do acknowledge >the need to have some idea of where you're going before you set out to >get there. And the degree of advance planning needed is indeed a function >of project size. But getting where you're going and then discovering that >you really want to be somewhere else should be treated as a predictable >part of the development process, not as a rare and surprising exception. Agreed. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
rab@well.UUCP (05/27/86)
[WHAT line ea In a previous article, an anonymous person writes: > > > You people fail to realize that some of us out here don't like lint. > > It complains too much about what I do. I refuse to go any further > > than generating no compiler warnings. I know what I'm doing. When I > > goof, I'll fix it myself. I refuse to add extra casts to keep lint > > happy. > > Of course, an expert like yourself would not consider stooping to making modifications to lint which match your programming preferences. And, of course, since you're omnipotent (at least within your machine) then there is no point in indirectly soliciting the impartial opinion of another competent programmer: if there are any bugs, well by God you put them there on purpose! > > > > Before you start flaming my style, let me say I am quite good. > > I am also quite philosophical and attentive to coding style. > > My outlook is just different. I program for myself. If it is applicable > > to you, fine. I have my own criteria which I rarely see embraced by > > others waving standardization flags. > > And of course the desires of your employer to have a working product that will remain usable even if you suffer an untimely death are completely irrelevant to your criteria.... What the heck, if another person can't figure out a few tens of thousands of lines of code without your help, why they must not be a very good programmer! > > > > Most of the code I have written was intrinsically non-portable. I *do* > > appreciate portability as a spectrum concept, but not as a binary one. > > Define 'spectrum' and 'binary' as used in this context. Responding to the above (and more like it) Greg Paris writes: > > Sorry I enclosed so much of the original article above, but I found it > so surprisingly bizzare, I just couldn't leave any of it out. I have > two things to say about it: 1) I'm glad that Mr. XYZZY doesn't work > here; 2) I'd never recommend him being hired as a programmer, anywhere. > -- > ++------------------------------------------------------------------++ > || Greg Paris {allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || > ++------------------------------------------------------------------++ > I, for one, thoroughly agree with you. Individual programming style is one thing; complete contempt for rational coding practice is quite another. -- Robert Bickford {lll-crg,hplabs}!well!rab
farren@hoptoad.UUCP (05/27/86)
After following a LOT of discussion about the relative merits of "design
first, then code" and "code first, then code", I have been driven to put in
my own two cents worth. Basically, I have never worked on a project that
did not benefit (or, at least, would not have benefitted) from putting as much
time and effort into the design of the project as possible before the first
line of code was written. Never. Not even once.
By thinking about the work you are about to do before hand, you ensure
that you will probably not fall into the horrible trap of dicovering that
what you are attempting to do can't be done. You also are preparing yourself
for the (inevitable?) eventuality that requires changing viewpoints, goals, or
the very nature of the project itself. If you have a clear idea of where you
are going, and how you plan to get there, it's a lot easier, and less de-
moralizing, to accomodate blocks, detours, or other obstacles. The final
product may not bear a strong resemblance to your original concept, but
at least the reason it doesn't is a *rational* one, not simply 'cause
someone panicked.
Mike Farren
{hplabs, dual, hoptoad}!well!farren
hoptoad!farrenjdz@wucec2.UUCP (05/28/86)
Gee, I thought GFY stood for "Good For You." Maybe I'm just naive.
Couldn't we just ignore Mr. Cottrel's spelling and spend more time and
bandwidth on more substantive things? It may be annoying at times, but I've
noticed he's toned it down quite a bit lately. Besides that, he has on more
than one occasion had something interesting and useful to say.
Let's stick to C and ignore English, shall we?
As to the use of the comma, I believe it has use only in for and while loops
and that's about it. There's no reason for not using them elsewhere. A pair
of braces require two extra keystrokes. BFHD (Big Fat Hairy Deal).
--
Jason D. Zions ...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz
Washington University Center for Engineering Computing
Box 1045
St. Louis MO 63130 USA (314) 889-5097
Drink Guinness - the stout with roughagehenry@utzoo.UUCP (Henry Spencer) (06/02/86)
> >More seriously, any grouping-by-indenting scheme should be studied carefully > >for ways in which minor typos could seriously alter the meaning of the > >program in non-obvious ways. > > I agree, but: why should this be done for grouping by indentation, when it > isn't done for any other language features? (When was the last time you > wrote "=" instead of "=="?) Because it's the right thing to do, even if our predecessors didn't always do it. "Neglect of duty does not cease by repetition to be neglect of duty." -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (06/06/86)
> There IS a lot of knowledge about user interaction; Far too little to be of a lot of use. Even something as simple as how to best handle over-long lines (wrap them around? leave a continuation marker on the right margin and allow horizontal scrolling? and a dozen details of approach for each of those) does not appear to have been studied at all. (If this particular issue has been studied, please cite references -- I'd love to know about them. Note that I'm talking about comparative studies, with numeric results, not just "we did it this way and we're glad".) > like structured software development, however, few > practitioners appear to have bothered to study it. For another example of lack of study, look at the March 85 CACM and a paper in CHI 83 by the same folks: few practitioners make ANY ATTEMPT to get real user input on how the software should behave. Let alone major input like real, numeric-result experiments on prototypes to find out what the user really needs/wants. Very few practitioners even mention it as a significant step, when asked about their methodology. Is it any wonder that much of their software isn't usable until Release 2 or 3? -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry