|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 firstname.lastname@example.org (Dave Thompson) (2005-09-07)|
|From:||Dave Thompson <email@example.com>|
|Date:||7 Sep 2005 13:12:31 -0400|
|Posted-Date:||07 Sep 2005 13:12:31 EDT|
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
Return to the
Search the comp.compilers archives again.