Comments on: Guest Article: Static Analysis in Medical Device Software (Part 1) — The Traps of C http://rdn-consulting.com/blog/2009/05/15/guest-article-static-analysis-in-medical-device-software-part-1-the-traps-of-c/ Software Development and Biomedical Engineering Wed, 08 Sep 2010 06:37:34 -0400 hourly 1 http://wordpress.org/?v=3.0.1 By: Guest Article: Static Analysis in Medical Device Software (Part 3) — Formal specifications | Bob on Medical Device Software http://rdn-consulting.com/blog/2009/05/15/guest-article-static-analysis-in-medical-device-software-part-1-the-traps-of-c/comment-page-1/#comment-2637 Guest Article: Static Analysis in Medical Device Software (Part 3) — Formal specifications | Bob on Medical Device Software Tue, 09 Mar 2010 15:56:25 +0000 http://rdn-consulting.com/blog/?p=267#comment-2637 [...] Cuoq at Frama-C continues his discussion of static analysis for medical device software. Also see Part 1 and Part [...] [...] Cuoq at Frama-C continues his discussion of static analysis for medical device software. Also see Part 1 and Part [...]

]]> By: Pascal Cuoq http://rdn-consulting.com/blog/2009/05/15/guest-article-static-analysis-in-medical-device-software-part-1-the-traps-of-c/comment-page-1/#comment-1671 Pascal Cuoq Sat, 06 Jun 2009 07:02:26 +0000 http://rdn-consulting.com/blog/?p=267#comment-1671 Anonymous is right in his message message of June 5, 6:37pm. Reading the value of an uninitialized variable is clearly marked as "undefined" behavior in the standard, that I did not have handy at the time I was writing this. I did not want all my unspecifiedness examples to be about pointers, but I should have kept digging for another example. While on this subject, one more remark: the standard does not force the compiler to detect and report undefined behaviors even when it would be possible, or even easy, to do so. Someone's first impression regarding the mentioned wrong behavior of the evaluation of (L-L) reading from a nonexistent stack frame could be that this only happens in cases where the compiler can easily detect that L certainly is accessed uninitialized. Maybe so (I still have to think about it) but the compiler DOESN'T HAVE TO detect it (according to the standard anyway). Pascal Cuoq Anonymous is right in his message message of June 5, 6:37pm.
Reading the value of an uninitialized variable is clearly marked
as “undefined” behavior in the standard, that I did not have handy
at the time I was writing this. I did not want all
my unspecifiedness examples to be about pointers, but
I should have kept digging for another example.

While on this subject, one more remark: the standard does not
force the compiler to detect and report undefined behaviors
even when it would be possible, or even easy, to do so.
Someone’s first impression regarding the mentioned
wrong behavior of the evaluation of (L-L) reading from
a nonexistent stack frame could be that this only happens
in cases where the compiler can easily detect that L
certainly is accessed uninitialized. Maybe so (I still have
to think about it) but the compiler DOESN’T HAVE TO detect it
(according to the standard anyway).

Pascal Cuoq

]]> By: Anonymous http://rdn-consulting.com/blog/2009/05/15/guest-article-static-analysis-in-medical-device-software-part-1-the-traps-of-c/comment-page-1/#comment-1668 Anonymous Sat, 06 Jun 2009 02:37:48 +0000 http://rdn-consulting.com/blog/?p=267#comment-1668 > The “uninitialized variable” example in the list of undesirable behaviors in the article is in fact an example of unspecified behavior. Not in C or C++, it isn't. Trying to read the value of an uninitialized variable yields undefined behavior, not unspecified behavior. In your example, L has no value --- not "some value, but I'm not sure which" --- *NO* value. The dangers of reading uninitialized variables should be pretty obvious to anyone who's ever taken a compiler-construction course in which "liveness analysis" was mentioned. It's simply not the case that (L-L) will evaluate to zero; it might evaluate to something else, or it might even try to read a value off the nonexistent stack frame and cause a hardware fault. > The “uninitialized variable” example in the list of undesirable behaviors in the article is in fact an example of unspecified behavior.

Not in C or C++, it isn’t. Trying to read the value of an uninitialized variable yields undefined behavior, not unspecified behavior. In your example, L has no value — not “some value, but I’m not sure which” — *NO* value.

The dangers of reading uninitialized variables should be pretty obvious to anyone who’s ever taken a compiler-construction course in which “liveness analysis” was mentioned. It’s simply not the case that (L-L) will evaluate to zero; it might evaluate to something else, or it might even try to read a value off the nonexistent stack frame and cause a hardware fault.

]]> By: Guest Article: Static Analysis in Medical Device Software (Part 2) — Methodology | Bob on Medical Device Software http://rdn-consulting.com/blog/2009/05/15/guest-article-static-analysis-in-medical-device-software-part-1-the-traps-of-c/comment-page-1/#comment-1661 Guest Article: Static Analysis in Medical Device Software (Part 2) — Methodology | Bob on Medical Device Software Thu, 04 Jun 2009 23:41:41 +0000 http://rdn-consulting.com/blog/?p=267#comment-1661 [...] Pascal Cuoq at Frama-C continues his discussion of static analysis for medical device software. This is part 2 of 3. Part 1 is here. [...] [...] Pascal Cuoq at Frama-C continues his discussion of static analysis for medical device software. This is part 2 of 3. Part 1 is here. [...]

]]>