On Mar 8, 2013, at 3:08 PM, David Woodhouse <[email protected]> wrote:
> On Fri, 2013-03-08 at 14:59 -0800, Andrew Fish wrote: >> >> David I'm with you on this, and I would point to the behavior of >> modern compilers (as our examples on the list show) follow the C99 >> definition of undefined behavior. >> >> It is my understanding that MSVC does not fully support C99, just a >> subset of features. > > Oh, wow. I concede I don't really follow the Windows world very much and > haven't done for years — the pollution of EDK2 with Windowsisms is the > closest I've had the misfortune to get. > > I didn't realise MSVC was such a substandard compiler. If that's really > the case then I suppose we're kind of stuck. We can't necessarily expect > everyone to upgrade to a saner build platform. > > In that case we should definitely use appropriate -std arguments on more > modern toolchains though, to make them enforce the use of anachronistic > code. Writing code targeted at C standard which was obsoleted 14 years > ago is definitely *not* going to come naturally to a lot of people. > Well everything works find today so turning on -std=iso9899:199409 would potentially cause new issues and fix NOTHING. I would also guess that the -std argument on modern compiler only changes the behavior of the parser and not the behavior of the optimizer. So for example if I add -std=iso9899:199409 -pedantic to clang I still get the same optimizing out null dereference behaviors. Not to mention the -pedantic makes it so you can't compile any edk2 code. In practice the MSVC subset of C99 (also called C95 + extensions) is not really a big issue. In practice setting warning equal errors causes a bigger practical issue as the different compilers can have different levels of pickiness about a given chunk of C code, so updating code and testing on one compiler could pass, but the code will generate a warning with another compiler. I can't think of a C99 language feature, other than named struct elements, that does not work. Again most of the MSVC C99 compatibility issues relate to includes and libraries that the edk2 does not use. At this point the biggest issue I've seen with C99 vs. C95 + extensions is a pedantic discussion on the mailing list about how the inventor/architect/manager of llvm and clang does not understand C standards. Thanks, Andrew Fish PS I'm curious if adding -std=iso9899:199409 to gcc changes its behavior in regards to NULL pointer optimization. If someone else is interested maybe they could give it a try and let us know what happens? > -- > dwmw2 > ------------------------------------------------------------------------------ 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
