Daryl, Glad you found the blog useful.
I would point out that given a link time optimizing compiler it is hard to know for sure what the end result of a function is. If the function gets inlined and optimized the NULL could be introduced by the optimization step. So a function boundary is not enough. You need to make the compiler think that the function is published to others in an opaque way to be safe. So for example a library function could be at risk, but a protocol member function would be safe. The danger here is as the optimize gets better it is possible that the complier will detect the undefined behavior due to a valid optimization. Thanks, Andrew Fish PS Chris Lattner Ph.D was the primary author of the LLVM compiler infrastructure and he is currently the Director and Architect of the Apple Developer Tools Department. So I would posit his blog is probably the most pedantic C document you are ever likely to come across. Given he runs the team that produces the Xcode compiler (clang) I don't think they are going to let anything the best current understanding and interpretation of the C language end up in the blog.... On Mar 7, 2013, at 6:12 PM, "Mcdaniel, Daryl" <[email protected]> wrote: > Thanks for the pointer to Chris Lattner's blog, Andrew. There is a lot of > interesting information there. Be careful though, he does not distinguish > between language features and compiler implementation features and > erroneously ascribes some compiler behaviors to language specification. He > also seems to think that "undefined" means "prohibited". > > Another interesting bit of trivia about null pointers from the ISO/IEC > 9899:199409 C language specification (C95, 1995): > "A null pointer is guaranteed to compare unequal to a pointer to any object > or function." > > "The C Programming Language", 1978, by Kernighan and Ritchie states: > "C guarantees that no pointer that validly points at data will contain zero, > so a return value of zero can be used to signal an abnormal event." > > This is only a problem if you attempt to create a pointer using constants, > such as (char *)0x00000000. By definition, this is a NULL pointer and cannot > point at data. But, any pointer that becomes zero (NULL) during program > operation can be dereferenced. "Safe" systems sometimes put a trapping > instruction at 0x00000000 so that if someone dereferences a NULL function > pointer it will be trapped before things disintegrate. If the trapping > instruction is read as data, it is a known value that if seen during debug is > an indication that you might be dereferencing a null pointer. > > Daryl McDaniel > > > -----Original Message----- > From: Andrew Fish [mailto:[email protected]] > Sent: Thursday, March 07, 2013 4:14 PM > To: [email protected] > Subject: [edk2] Common, pedantic, bug in embedded C. * (char *)0x00000000 = 1 > > We just ran into an issue that I thought was worth sharing with the group. We > just updated our compiler and a memory test got optimized away. At first we > thought it was a compiler bug. But then we were informed that in the C > language the dereference of a NULL pointer is undefined behavior. So > technically it is legal for the compiler to optimize it way. > > So to be pedantic in C if you ever dereference a NULL point on purpose you > need to make it a volatile to conform to the C standard. A memory test may > want to access address 0, and code that writes the ARM or 8086 vector table > may also end up dereferencing a NULL pointer. > > I think folks will find Chris Lattner's blog interesting > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html > > Andrew Fish > > > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
