Path: utzoo!attcan!uunet!samsung!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: Discarded Function Values (To Cast or Not to Cast) Message-ID: <11680@smoke.BRL.MIL> Date: 24 Nov 89 16:04:34 GMT References: <316@voa3.UUCP> <1989Nov17.154621.2698@aqdata.uucp> <1989Nov18.062322.12728@twwells.com> <11644@smoke.BRL.MIL> <1989Nov19.171815.17445@twwells.com> <20882@mimsy.umd.edu> <1989Nov23.233403.2841@twwells.com> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 31 In article <1989Nov23.233403.2841@twwells.com> bill@twwells.com (T. William Wells) writes: >function returns value which is always ignored > fprintf umask putenv > setgid setuid time > signal strcpy unlink > fflush printf sprintf > strcat sleep fputs >(The sum total of lint warnings from a program *under >development*. I can tell you why *each* of these is there. And I >can tell you, also, which I'm not going to get rid of in the >production version.) Anybody maintaining this code will have to determine why EACH warning occurs and whether or not it represents a potential problem. For example, when *printf() and fflush() report errors, is it really safe to not detect that? In most production applications, it would be a serious mistake to ignore an output error. Similar things could be said about most of these functions (the str*() family being the exception, since they never report failure). Your code may be perfectly okay, but from years of experience maintaining UNIX system code written by other people, I've found that I cannot afford to ignore such "lint" warnings. If, on the other hand, I've taken the trouble to completely inspect and de-lint a chunk of software, then at any future date when "lint" shows up in it I know there is a real problem. In the long run it saves me time. P.S. I don't think you should take counterarguments so personally. As I said, if your approach works for you, more power to you. Mine certainly works better for me.