dave@dptechno.uucp (Dave Lee) (09/22/90)
This is a bone I've been thinking about for some time.
Given a simple function like :
int func(){ ... }
Whose return value I rarely care about --- say printf().
Why should I go to the extra trouble to write
(void) printf("hello world\n");
Instead of
printf("hello world\n");
IMHO, one of the great beauties of C is not distinguishing between
procedure and function calls.
The possible reasons I have deduced are:
1. shut up lint.
2. shut up the compiler
To both 1 and 2 I reply:
If I wanted to check the return value, I would have.
This is not the sort of thing that results from a typo or unconcious omission.
I never type
func_call();
When I mean
if( func_call() == whatever ) ...;
I never "accidently" ommit a check for return value, though I may be lazy
and decide to omit one.
I believe this is a programming consideration, not a language one.
Any comments on this? Of what real value is the extra "(void)", when
IMHO omitting it is easier to read, shorter, and has identical meaning to
the compiler.
--
Dave Lee
uunet!dptechno!davejensting@skinfaxe.diku.dk (Jens Tingleff) (09/25/90)
dave@dptechno.uucp (Dave Lee) writes: [..] >To both 1 and 2 I reply: >If I wanted to check the return value, I would have. >This is not the sort of thing that results from a typo or unconcious omission. >I never type GOTCHA! Try these two int function_with_some_side_effects(); other func() { int a,b; b = function_with_side_effects(some_global); a = b + function_with_side_effects(some_global); } ---OR--- { int a,b; b = function_with_side_effects(some_global); a = b ; function_with_side_effects(some_global); } ^ +-- Grade A typo, if you keyboard has '+' as SHIFT ';' (such as this keyboard, a TVI955) Enough said.. . Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1, DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/25/90)
I put in the (void) to remind myself later that I simply do not care about the return value of foo. When I leave something like printf() without a (void), I'm reminding myself that I may or may not want to check the return value. This gain in readability (using a convention that lint also supports) justifies taking advantage of the feature. ---Dan
ghoti+@andrew.cmu.edu (Adam Stoller) (09/25/90)
Excerpts from netnews.comp.lang.c: 21-Sep-90 Why use (void) func() ? Dave Lee@dptechno.uucp (1070) > Given a simple function like : > int func(){ ... } > Whose return value I rarely care about --- say printf(). > Why should I go to the extra trouble to write > (void) printf("hello world\n"); [.....] > If I wanted to check the return value, I would have. > This is not the sort of thing that results from a typo or unconcious omission. > I never type > func_call(); > > When I mean > if( func_call() == whatever ) ...; > I never "accidently" ommit a check for return value, though I may be > lazy and decide to omit one. I believe this is a programming > consideration, not a language one. a) You make the traditional assumption that just because YOU never do anything wrong (exagerated emphasis) that NOBODY would ever do something wrong. It's an imperfect world, and mistakes happen. b) Most of the cases of such functions are probably throwbacks to olden days when: -) they didn't have void. -) they almost never bothered to declare anything that was, or returned int. -) they may have actually had a real reason for sending the return value. I happen to agree that having printf() return an int is rather a waste, but if/when it bothers me, I either go through the code and put the void cast in front of each printf, or I change them all from "printf" to "PRINTF" and declare a macro like: #define PRINTF (void)printf It's not beautiful, but at least it shows anyone who looks at my code (including myself some days down the road) that I explicitly decided to ignore the return value. But then we breach into the holliest of holy wars -- (oh noooooo! :0 oh yes! ;-)) -- styles and code formatting. And so, adding my $0.02 to the pot, I return to the murky depths of my own subconcious............ --fish
karl@haddock.ima.isc.com (Karl Heuer) (09/25/90)
In article <586@dptechno.UUCP> dave@dptechno.uucp (Dave Lee) writes: >Why should I go to the extra trouble to [explicitly cast to void]? To distinguish between "This call might fail, but I don't know what I should do about it" (uncast) and "This call might fail, but the appropriate recovery operation is a NOP" (cast). An example of the former is most programs' use of putchar() or printf(). An example of the latter is unlink(t) in a cleanup routine where t is a temp file that may or may not exist at this point, or the fprintf(stderr, ...) issued from a panic routine just before exiting. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/25/90)
In article <586@dptechno.UUCP>, dave@dptechno.uucp (Dave Lee) [claims that he never accidentally omits to check the result of a function, and asks why lint complains about it. He specifically cites printf().] > Why should I go to the extra trouble to write > (void) printf("hello world\n"); > Instead of > printf("hello world\n"); Stop and think for a moment. Why might lint have been made to check for this in the first place? The answer is simple: the result that you are ignoring is the only error indication you are going to get, and ignoring it _may_ be very silly. I am sick of UNIX programs whose authors KNEW that they could safely ignore the result of (say) write(), with the result that I have lost valuable files because write errors were ignored. (It's no good relying on a source management system to protect your old versions when the source management system itself is capable of storing large blocks of 0s for this very reason.) printf() used to return 0 for success, -ve for failure. In ANSI C, printf() returns #characters written for success, -ve for failure. Are you _sure_ that you know all the causes of error in a call to printf() -- such as output being written to a file on a disc that has just filled up -- and have ensured that they can't happen? You might like to use something like #include <stdarg.h> #include <stdio.h> #include <stdlib.h> static void error(void) /* BEWARE: This is UNIX-specific */ { /* if you've closed stderr, we're sunk */ static char message[] = "Error in ?printf\n"; write(2, message, sizeof message - 1); exit(EXIT_FAILURE); } void eprintf(char *format, ...) { va_list ap; int t; va_start(ap, format); t = vprintf(format, ap) va_end(ap); if (t < 0) error(); } void efprintf(FILE *stream, char *format, ...) { va_list ap; int t; va_start(ap, format); t = vfprintf(stream, format, ap) va_end(ap); if (t < 0) error(); } /* end of file */ -- Heuer's Law: Any feature is a bug unless it can be turned off.
volpe@underdog.crd.ge.com (Christopher R Volpe) (09/25/90)
I wouldn't mind it if lint warned about *my* functions that I declare with a return value which I *sometimes* ignore. That makes sense, because I rarely define functions whose return values I am interested in only sometimes. What I do mind is when lint warns me about return values from printf being ignored, which I, as well as most people, routinely ignore. Our dain-bramaged lint does the annoying thing in both circumstances: It fails to warn about ignored return values from *my* routines, and always warns about ignored return values from printf and scanf! ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
henry@zoo.toronto.edu (Henry Spencer) (09/25/90)
In article <3819@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >... Are you _sure_ that you know all the causes of error in a >call to printf() -- such as output being written to a file on a disc >that has just filled up -- and have ensured that they can't happen? For printf, it is usually a whole lot simpler -- in cases where it matters, which it often doesn't -- to just check ferror() near the end. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/26/90)
In article <1990Sep25.163906.4187@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > For printf, it is usually a whole lot simpler -- in cases where it matters, > which it often doesn't -- to just check ferror() near the end. I haven't a copy of the final draft of the C standard. Does it explicitly say that errors detected by printf() &co set the stream's error indicator? I've checked the Plauger & Brodie summary, and it says nothing of the kind, nor does any of the UNIX manuals that I've checked. Actually, this is a long-standing gripe of mine: I have never been able to find out which errors printf() *does* detect (negative field width and precision have been defined as non-errors, but what about %@ or the like), and I've certainly never seen any suggestion that format errors set ferror() nor any guarantee that printf() doesn't clear ferror(). What _does_ the standard say about this? -- Fixed in the next release.
henry@zoo.toronto.edu (Henry Spencer) (09/28/90)
In article <3837@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >> For printf, it is usually a whole lot simpler -- in cases where it matters, >> which it often doesn't -- to just check ferror() near the end. > >I haven't a copy of the final draft of the C standard. Does it explicitly >say that errors detected by printf() &co set the stream's error indicator? It says, when defining the error indicator, that it "records whether a read/write error has occurred". Period. No distinction is made as to cause of said error. >... what about %@ or the like... Behavior undefined. Could cause a read/write error, I guess... >never seen any suggestion that format errors set ferror() nor any >guarantee that printf() doesn't clear ferror(). clearerr() and some of the fopen() family are the only things that are documented as clearing the error indicator. I think it is safe to say that an indicator defined as recording "whether a read/write error has occurred" cannot legally be implemented as "whether a read/write error has occurred since the latest printf". As for format errors, those clearly are not read/write errors, unless the undefined response to them provokes one. It should not be necessary to do a run-time check for what is invariably a compile-time error, however, unless the printf format string is being synthesized in some bizarre way. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/28/90)
In article <3837@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > What _does_ the standard say about [printf() and ferror() and so on] Thanks to the many people who explained to me that printf &co do output "as if" using fputc() so *output* errors are reflected in ferror() as they would be by fputc(), but that the effect of format errors as such is not defined. -- Fixed in the next release.
karl@haddock.ima.isc.com (Karl Heuer) (09/29/90)
In article <oazbx9O00VtqAheFBf@andrew.cmu.edu> ghoti+@andrew.cmu.edu (Adam Stoller) writes: >I happen to agree that having printf() return an int is rather a waste, >but if/when it bothers me, I either go through the code and put the void >cast in front of each printf, or [fake it with a macro]. In other words, you treat the symptoms instead of the disease. My opinion: the disease is pretty mild, but so are the symptoms (a single entry in one line of lint output); and I'd rather keep the latter around in case I someday decide to repair the former. I actually have one program that lints cleanly, modulo lint bugs, and does not do any such fudging: output is done with void pprintf(Player *p, char const *fmt, ...) { va_list ap; va_start(ap, fmt); if (vfprintf(p->ofp, fmt, ap) < 0) bugcheck(); va_end(ap); if (fflush(p->ofp) == EOF) bugcheck(); } Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
asylvain@felix.UUCP (Alvin E. Sylvain) (10/02/90)
In article <12141@crdgw1.crd.ge.com> volpe@underdog.crd.ge.com (Christopher R Volpe) writes: >I wouldn't mind it if lint warned about *my* functions that I declare >with a return value which I *sometimes* ignore. That makes sense, because >I rarely define functions whose return values I am interested in only >sometimes. What I do mind is when lint warns me about return values from >printf being ignored, which I, as well as most people, routinely ignore. >Our dain-bramaged lint does the annoying thing in both circumstances: >It fails to warn about ignored return values from *my* routines, and >always warns about ignored return values from printf and scanf! >================== >Chris Volpe >G.E. Corporate R&D >volpecr@crd.ge.com I agree with this assessment of lint, and I'd like to open the floor to opinions in that area. I believe this is the main bone of contention here. IMHO, lint is a good idea, but it is usually so durnedably verbose that I'd rather not bother. It's a matter (as expressed above) of reporting problems one could just as well not hear about. Any tool which annoys the user to the point of not using it is less than useless ... the benefits are wasted. In the case of lint, real problems can remain uncovered, only to bite you during testing, maintenance, or (ye gads!) customer operation. Anyone else out there feel this way? Any thoughts toward a version of lint that's a little less "mother-hen", but still tells you what you need to know? Maybe we could program it with "ignore the following problems with the following functions" instructions. (BTW, even if you never check printf, IMAO you should *always* check scanf. Your output may be 99% reliable if the file was opened successfully, but your input is *always* suspicious, no matter what the source.) -- ------------------------------------------------------------------------ "I got protection for my | Alvin "the Chipmunk" Sylvain affections, so swing your | Natch, nobody'd be *fool* enough to have bootie in my direction!" | *my* opinions, 'ceptin' *me*, of course! -=--=--=--"BANDWIDTH?? WE DON'T NEED NO STINKING BANDWIDTH!!"--=--=--=-
flint@gistdev.gist.com (Flint Pellett) (10/03/90)
Something I think would help lint a lot would be the following two options: 1. An option to ignore extern declarations made in a .h that aren't used. (Ever run lint on something that #includes <curses.h>? You get to wade through 3 pages of curses routines that were extern'ed but not used.) The same goes for declarations I put in my own .h files. Now if I have an extern right there in the file that I haven't used, I want to know about that, but if it's in some .h, who cares? 2. An option to not print out all the "function declared but never used" and "function referenced but never declared". When you have a real big program spanning 100 files, you'd like to be able to run lint on just one file at a time as you work on that one file-- but when you do, you get reports about all the functions you used from the other files, and about the fact that nobody is calling any of the subroutines that you have in that one file. Basically, all I want is a quick syntax & types check, without a check on external references. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
peter@ficc.ferranti.com (Peter da Silva) (10/04/90)
In article <151806@felix.UUCP> asylvain@felix.UUCP (Alvin E. Sylvain) writes: > (BTW, even if you never check printf, IMAO you should *always* check scanf. IMHO you should never *use* scanf. Its behaviour is so mind-bogglingly stupid that it thinks that if you can't see it, it can't see you. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) (10/04/90)
karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <oazbx9O00VtqAheFBf@andrew.cmu.edu> ghoti+@andrew.cmu.edu (Adam Stoller) writes: >>I happen to agree that having printf() return an int is rather a waste, >>but if/when it bothers me, I either go through the code and put the void >>cast in front of each printf, or [fake it with a macro]. >My opinion: the disease is pretty mild, but so are the symptoms (a single >entry in one line of lint output); and I'd rather keep the latter around in >case I someday decide to repair the former. I actually have one program that >lints cleanly, modulo lint bugs, and does not do any such fudging: output is >done with > void pprintf(Player *p, char const *fmt, ...) { > va_list ap; > va_start(ap, fmt); > if (vfprintf(p->ofp, fmt, ap) < 0) bugcheck(); > va_end(ap); > if (fflush(p->ofp) == EOF) bugcheck(); > } Hmm. This idea could be carried a step further by providing a means of specifying a particular error handler at different points in the flow of the code. Maybe you don't always want to quit with a bug check at a critical portion of the code, instead you'd rather try your best to clean up before exiting or even ignore the write error if it doesn't affect the ultimate result of the program. (But then why did I try to write, you say? Well, the failed writes might be status messages for human viewing, which normally go to the tty but which someone redirected into a file on a filesystem which has now filled up. If you're in the middle of a critical data file manipulation when that happens, you likely don't want to just -- **boom** -- quit with files in a confused state.) -- Daniel R. Levy * uunet!tellab5!mtcchi!levy * These views not on behalf of MTC so far as I can remember, there is not one | ... THEREFORE BE AS SHREWD AS word in the gospels in praise of intelligence.| SERPENTS [SEE GEN. 3] AND HARM- -- bertrand russell [berkeley unix fortune] | LESS AS DOVES -- JC [MT. 10:16]
rcl@b15.INGR.COM (Rob Lemley) (10/04/90)
In <1014@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: >Something I think would help lint a lot would be the following two options: >1. An option to ignore extern declarations made in a .h that aren't used. > The same goes for declarations I put in my own .h files. Now if I have > an extern right there in the file that I haven't used, I want to know > about that, but if it's in some .h, who cares? I don't think you can do this on System V Release 3. >2. An option to not print out all the "function declared but never used" > and "function referenced but never declared". . . . You CAN do this on System V Release 3. From the UNIX System V Release 3 Programmer's Reference Manual, LINT(1), The following options are used to suppress certain kinds of complaints: -u Suppress complaints about functions and external variables used and not defined, or defined and not used. (This option is suitable for running lint on a subset of files of a larger program). -x Do not report variables referred to by external declarations but never used. -- -Rob Lemley 205-730-1546 System Consultant, Scanning Software, Intergraph Corp., Huntsville, AL ...!uunet!ingr!b15!rcl b15!rcl@INGR.COM 204-730-1546
rcl@b15.INGR.COM (Rob Lemley) (10/05/90)
In <151806@felix.UUCP> asylvain@felix.UUCP (Alvin E. Sylvain) writes: >Anyone else out there feel this way? Any thoughts toward a version >of lint that's a little less "mother-hen", but still tells you what >you need to know? Maybe we could program it with "ignore the following >problems with the following functions" instructions. I admit, this has been, and probably will continue to be, a problem with lint. A modular, customizable system (ahh Unix) is one answer that we now have. On System V Release 3, a great deal of customization can be done with the current lint. You must be willing to edit system include files (in /usr/include) and the lint libraries (usually in /usr/lib). Of course, this should be done in a local directory before installing changes in the system area. The following type script of a work session illustrates how this can be accomplished. Note that lint itself is a shell script which you may examine at your leisure :-). The last lint command in the sequence: lint -u -n -I. -L. -lc t.c uses an undocumented option of lint, the -L option, which specifies search directories where lint libraries should be found. Here is a description of the options used: -u Suppress complaints about functions and external variables used and not defined, or defined and not used. (This option is used because some new functions were added to the stdio.h file and not added to the lint library file.) -n Do not check compatibility against either the standard or the portable lint library. -I. Search for header files in the current directory before /usr/include, etc. -L. This is the undocumented option to lint which creates and adds directories to the search list for lint libraries. -lc Since the directory search list for lint libraries has now been defined, this option tells lint to use the c library lint library. (which will be found in the current directory.) Type script of work session (I have added blank lines before the prompts): $ cat t.c #include <stdio.h> main() { printf ("hello world\n"); return 0; } $ lint -u t.c ============== function returns value which is always ignored printf $ diff /usr/lib/llib-lc ./llib-lc.c 381c381 < int printf(s) char *s; { return (0); } --- > void printf(s) char *s; { return ; } $ diff /usr/include/stdio.h ./stdio.h 153c153 < extern int printf(const char *format, ...); --- > extern void printf(const char *format, ...); 189c189 < getw(), pclose(), printf(), fprintf(), sprintf(), --- > getw(), pclose(), fprintf(), sprintf(), 192a193 > extern void printf(); $ lint -n -v -x -I. llib-lc.c -o c "/usr/include/mon.h", line 30: warning: redefinition of: NULL llib-lc.c ============== (484) warning: struct/union region never defined $ lint -u -n -I. -L. -lc t.c $ End of work session type script. The fact that lint is a shell script also lends many possibilities for local customization. Another way to alleviate the problem of too much unnecessary output from lint would be to use some kind of post-processing. When I was using the BSD 4.1 system, we had a utility called "error" which would take the standard and/or error output of cc, cpp, lint, f77, etc. and insert special comments in the source files at the lines where errors were detected. The error command also would read a startup file ($HOME/.ignore or something like that) where you could specify errors that you wanted to be ignored. This is where I specified that I didn't want to here about printf(), exit(), etc. -- -Rob Lemley System Consultant, Scanning Software, Intergraph, Huntsville, AL ...!uunet!ingr!b15!rcl or b15!rcl@INGR.COM 205-730-1546
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (10/07/90)
In my makefile I have several lint targets that provide different
levels of linting. I normally do "make lint". Less often, I use a
different level. Each target filters through a different egrep
pattern.
lint0:
lint $(LINTFLAGS) $(SRCS)
lint1:
lint $(LINTFLAGS) $(SRCS) | \
egrep -v "`cat .stop.$@`"
lint2:
lint $(LINTFLAGS) $(SRCS) | \
egrep -v "`cat .stop.$@`"
lint3:
lint $(LINTFLAGS) $(SRCS) | \
egrep -v "`cat .stop.$@`"
The .stop.lint* files contain the lint output filtration patterns.
E.g., .stop.lint3 contains (all one line; broken with \ here for
clarity):
enumeration type clash|possible pointer alignment|\
unused in function|set but not used in function|\
but never used|iovec never defined
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesikarl@haddock.ima.isc.com (Karl Heuer) (10/08/90)
In article <151806@felix.UUCP> asylvain@felix.UUCP (Alvin E. Sylvain) writes: >In article <12141@crdgw1.crd.ge.com> volpe@underdog.crd.ge.com (Christopher R Volpe) writes: >>It fails to warn about ignored return values from *my* routines, and >>always warns about ignored return values from printf and scanf! > >I agree with this assessment of lint... As I pointed out to Chris V. by email, it's not true that lint distinguishes between user functions and library functions this way. And of course lint has no way of knowing the difference between a critical printf() call and a benign one, unless you tell it (see my example of enclosing the former in a routine that *does* check the return value). >IMHO, lint is a good idea, but it is usually so durnedably >verbose that I'd rather not bother. It's a matter (as expressed above) >of reporting problems one could just as well not hear about. The particular issue mentioned above is a single item at the bottom of the lint output--easy enough to visually skip past. If you're going to complain about inappropriate lint verbosity, complain about the malloc() bug, which yields a warning on every call. In article <1014@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: >1. An option to ignore extern declarations made in a .h that aren't used. > (Ever run lint on something that #includes <curses.h>? You get to wade > through 3 pages of curses routines that were extern'ed but not used.) Assuming you remember to specify "-lcurses", what you are observing is a bug in <curses.h> and/or llib-lcurses. Report it to your vendor. > The same goes for declarations I put in my own .h files. > Now if I have an extern right there in the file that I haven't used, I > want to know about that, but if it's in some .h, who cares? If the object being declared extern doesn't have a corresponding definition anywhere, then why does your header declare it? If a defining declaration does exist but is not visible to lint (because you're linting only some of the files), then you should be using the lint options that say so. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
cej@ll1a.ATT.COM (C. E. T. L. Jones) (10/09/90)
In article <1014@gistdev.gist.com> (Flint Pellett) writes: > >2. An option to not print out all the "function declared but never used" > and "function referenced but never declared" [...] >Basically, all I want is a quick syntax & types check, without a check >on external references. try 'lint -x' (To quote: "Do not report variables referred to by external declarations but never used") Charles Evan Thomas Llewellyn Jones "...and the contestant from Germany is a bi-lingual vacuum cleaner." ...att!ccsitn!cej [Just me, not AT&T] cej@ccsitn.att.com