Re: Warn about ignored return codes

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

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