Re: Warn about ignored return codes

Dave Thompson <david.thompson1@worldnet.att.net>
7 Sep 2005 13:12:31 -0400

          From comp.compilers

Related articles
Warn about ignored return codes Markus.Elfring@web.de (Markus Elfring) (2005-08-24)
Re: Warn about ignored return codes alexc@TheWorld.com (Alex Colvin) (2005-08-31)
Re: Warn about ignored return codes Markus.Elfring@web.de (2005-08-31)
Re: Warn about ignored return codes Markus.Elfring@web.de (2005-09-02)
Re: Warn about ignored return codes david.thompson1@worldnet.att.net (Dave Thompson) (2005-09-07)
| List of all articles for this month |

From: Dave Thompson <david.thompson1@worldnet.att.net>
Newsgroups: comp.compilers
Date: 7 Sep 2005 13:12:31 -0400
Organization: AT&T Worldnet
References: 05-08-082 05-08-108
Keywords: debug

On 31 Aug 2005 00:33:46 -0400, Alex Colvin <alexc@TheWorld.com> wrote:


> >Some compilers can detect unused variables. Which tools can generate
> >warnings for ignored return values from function calls in a similar
> >way? How much can it help in static semantic checking and code
> >analysis for flaw detection?
>
> In a language like C (or LISP) functions often return some potentially
> useful value, even if it's not a status. The function caller doesn't
> always need this value.
> strcpy() returns the destination address. The caller often already
> knows this, having provided it.
> printf() returns a status. It's easier to check ferror(). Or to
> rely on the SIGPIPE exception


*printf() returns either a character count or an error flag. It's
usually easier to check ferror() (later) for the error flag, and in
the rare cases the count is useful for a file you can *often* use
ftell() (although on rare systems it isn't a byte count for text
streams, including stdout, and may be unsupported on nonstorage files
like a tty or pipe); for sprintf() it is sometimes useful.


signal() returns the previous handler, which when reverting is the one
you set, and when permanently overriding doesn't matter.


time() can return its value *or* store through an argument or (very
rarely useful) both.


> So it's common to ignore return values.
>
> You could annotate functions to distinguish error returns from such
> incidental value returns. You could also allow a printf status to be
> discarded as long as ferror() is used. If you have enough dataflow
> information you might be able to track error status flow.


- David.Thompson1 at worldnet.att.net



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.