Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] -metrics discrepency Boron/Nitrogen

On Mon, 14 May 2012, Richard Bonichon wrote:

>    As a comment to my answer, let me add that assuming that it was a bug of
>    the Boron version is actually false.
> 
>    The (more satisfactory) explanation is simply that the normalization
>    process has changed between Boron and Nitrogen. In your case Nitrogen's
>    normalization behavior is the same as Carbon's. Or-conditions are
>    separated into two branches, and the code is shared through a goto
>    statement. In Boron, the same code is duplicated in both branches, thereby
>    not producing the "unexpected" goto.
> 
>    Therefore, both Frama-C versions are right in your example -- in a certain
>    subtle way.
>
a bit confused - thought thatt code-metrtics are there to allow judging of 
complexity of source code primarily, but if this is based on an intermediate representation then it actually does not describe the metrics of the sources that well, in fact it would possibly depend on the compiler/version ?

is it possible to get code metrics for the actual source representation of the code ? Or put differently what would the metrics of the internal representation be used for ?


thx!
hofrat