--- layout: fc_discuss_archives title: Message 38 from Frama-C-discuss on May 2012 ---
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