Re: Warn about ignored return codes

Markus.Elfring@web.de
2 Sep 2005 14:22:53 -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: Markus.Elfring@web.de
Newsgroups: comp.compilers
Date: 2 Sep 2005 14:22:53 -0400
Organization: http://groups.google.com
References: 05-08-08205-08-108
Keywords: tools
Posted-Date: 02 Sep 2005 14:22:52 EDT

Alex Colvin wrote:
> 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.


We can distinguish between two use cases.




> strcpy() returns the destination address. The caller often
> already knows this, having provided it.


This kind of address is used as a reference to make it possible to
concatenate them in a function call chain. It does not represent a
value for new allocated memory.




> printf() returns a status. It's easier to check ferror(). Or
> to rely on the SIGPIPE exception


This seems also to be a matter of programming style. I would check
the value from the primary function for an error status indication if
I must guarantee that the desired effects took place.




> So it's common to ignore return values.


I'd like to highlight the cases when this ignorance leads to
unexpected behaviour in applications. How much do you really care for
complete checking in "ordinary situations"?




> 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.


Which annotation formats are "common sense" so that they are not only
useable with a single code analysis tool like Splint? Can
configuration tables be constructed to specify (e.g. alternate types)
where the result value may be safely ignored?


Regards,
Markus


Post a followup to this message

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