A multi-platform compiler should not interfere with dereferencing NULL. No general purpose (cross) compiler for X86 should interfere with dereferencing NULL. Generating a warning is OK. Having compiler options to enable or disable such checks or interference is OK. Not being able to disable these interferences is not acceptable.
A compiler that supports ONE particular platform/CPU combination may interfere with dereferencing NULL if that is always to be prohibited in all cases for that particular platform. Luckily, both GCC and VC++ have combinations of options that allow one to get around most interference. And, the EDK II build system still allows one to specify additional options for particular packages and modules. The C specification is intended to mean that a conforming C compiler will never generate code that places a data or function object at an address that is the same as NULL so that NULL will remain distinct. It does not mean that a C program can't reference a pre-existing object at that location. "Unspecified" behavior means "we don't know how your particular HARDWARE or operating environment will behave when you do this". In other words, unspecified behavior is repeatable behavior that stems from factors beyond the compiler's control. And, these behaviors may change for different hardware or operating environments. Since we can't predict how future systems may behave, the behavior of some operations on those systems remains "unspecified". This is different from "indeterminate" behavior such as the value that uninitialized automatic variables have. It is "indeterminate" because we can't reasonably predict what value will have been left at that variable's location from some previous operation. The compiler has control of this but chooses not to force uninitialized automatic variables to a particular value. The programmer should not be prohibited from using "unspecified" or "indeterminate" operations. Their use just makes the resulting code non-portable. There are times when non-portable code is completely acceptable. Daryl McDaniel -----Original Message----- From: Brian J. Johnson [mailto:[email protected]] Sent: Friday, March 08, 2013 8:52 AM To: [email protected] Subject: Re: [edk2] Common, pedantic, bug in embedded C. * (char *)0x00000000 = 1 On 03/07/2013 08:12 PM, Mcdaniel, Daryl wrote: > ... > 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. We've implemented a similar "safety" check in our BIOS by modifying the segment descriptors (in 32-bit mode) and the 1:1 page tables (in 64-bit mode) to prohibit access to addresses 0-4095. That caught some bugs and unforseen end cases in our code. Unfortunately this check interfered with the CSM, so we were not able to use it in production. But it might be a handy option (under a PCD feature flag, of course) to have available in EDK2. -- Brian J. Johnson -------------------------------------------------------------------- "Great works are performed not by power, but by perseverance." -- Samuel Johnson ------------------------------------------------------------------------------ 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
