From: Tim Frink on
Hi,

I've a design question: I've implemented a static program
analysis (for C programs) which currently does not support
the data type float and double in the output program.

My question is now how to react when the user provides a C
source code with floats as input which cannot be analyzed.
Since the analysis is embedded in a larger project and its
results are not mandatory, an assertion when float/doubles
detected is not acceptable. My ideas are:
1) When creating an object to my program analysis, its constructor
runs an internal method to check if the input program
contains any unsupported data types. If so, the analysis
will be not performed (it will do nothing) when run by the
user. So, the user need not to take care if the program
analysis succeeded.
2) I add a public function which checks if the input program
can be analyzed and return either true of false. In this
scenario, the user must first create an object to the program
analysis, then run the public check-method and if true was
returned, the actual analysis can be started. The advantage
here is that the information if the analysis is feasible is
not hidden to the user but on the other hand the user must always
take care that he starts the check-method in advance. Forgetting
it might lead to problems.

In my eyes, both approach are not really perfect and I'm looking
for a better solution. How would you handle such an issue?

Best regards,
Tim
From: Bart van Ingen Schenau on
Tim Frink wrote:

> Hi,
>
> I've a design question: I've implemented a static program
> analysis (for C programs) which currently does not support
> the data type float and double in the output program.
>
> My question is now how to react when the user provides a C
> source code with floats as input which cannot be analyzed.
> Since the analysis is embedded in a larger project and its
> results are not mandatory, an assertion when float/doubles
> detected is not acceptable. My ideas are:
> 1) When creating an object to my program analysis, its constructor
> runs an internal method to check if the input program
> contains any unsupported data types. If so, the analysis
> will be not performed (it will do nothing) when run by the
> user. So, the user need not to take care if the program
> analysis succeeded.
> 2) I add a public function which checks if the input program
> can be analyzed and return either true of false. In this
> scenario, the user must first create an object to the program
> analysis, then run the public check-method and if true was
> returned, the actual analysis can be started. The advantage
> here is that the information if the analysis is feasible is
> not hidden to the user but on the other hand the user must always
> take care that he starts the check-method in advance. Forgetting
> it might lead to problems.
>
> In my eyes, both approach are not really perfect and I'm looking
> for a better solution. How would you handle such an issue?
>
> Best regards,
> Tim

It is not entirely clear from your description, but I am assuming that
your tool performs a lint-like analysis of a C program.

First of all, a simple textual scan for the keywords 'float'
and 'double' is not sufficient to determine if a file contains
floating-point operations. The keywords might be hidden with some
macro, or they might appear in a context that should not be processed
(such as a comment or #if 0-ed section).
It is also possible to use floating point operations without using the
keywords 'float' and 'double' at all.

The best you can do is to add floating-point support to the tool.
Initially, this could be such that the lexer recognises (and accepts)
the floating point constructs, but no further checking is performed on
them.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/