On 03/08/13 23:01, David Woodhouse wrote: > On Fri, 2013-03-08 at 21:49 +0000, Mcdaniel, Daryl wrote: >> The EDK II code base does not support C99 for non-platform-specific >> code, only C95 is supported. >> This is because we must support a compiler which is only C89 (Strict >> mode) or C95 with extensions. > > I'm a little confused by this. Why "must" we support such an ancient > compiler? Why can't we have a whip-round and buy them a licence for GCC > or CLANG, for crying out loud? > > Why would someone be stuck on such a compiler, and yet *still* be > updating to newer EDK2 code? That seems rather schizophrenic.
I disagree :) A stable development environment may have cost many people significant resources, so it's reasonable to withstand unwarranted change. (The new environment will cost you, even if you could legally acquire the bits for zero cost.) You shouldn't give people the stick without giving them the carrot :) If you go over the list of "new features" in C99 (see the Foreword), there are huge improvements, but not much that would make you throw away your old C89 environment that already builds the project(s) you care about. The development environment is your tool, you want it to be stable and reliable. The effort is being put in the product under development. Better tools are nice to have, broken (regressing) tools are catastrophic. <rant> For example, the Single Unix Specification Version 2 is C89 based, and it is a very capable and portable environment. (IOW C89, the language, is not too restrictive for practical purposes, especially in the manner most compilers support it). >From comp.lang.c I seem to remember people mentioning that Microsoft had explicitly decided against implementing C99 in their tools. I think this is unfortunate (the most recent version of a development product should support the most recent standard), but I can understand users (developers) not wanting to upgade, hence their supplier not wanting to spend effort on preparing the upgrade. Personally I absolutely don't care about C11 *yet*, for example. I'll start when the next SUS comes out that is based on it (which should imply that several independent platforms implement it). C99 is not portable enough for edk2, apparently; and I can relate, as I was developing for *only* SUSv2, and building on Solaris, GNU/Linux, Tru64, maybe AIX, smiling, while other UNIX(R) users were cursing about ./configure and programs written against GNU/Linux man pages solely. (Yes, I know, it's not auto-tools' fault, its the wrong use thereof. Still.) In recent years, as I personally can't really log into anything non-GNU/Linux, I started to accept SUSv3 (released in 2004 :)) and SUSv4 (2008) too. </rant> > It looks like we're missing appropriate -std= arguments for GCC, if we > really do want to be stuck on a language which is 20 years old. You're likely correct. Maybe -std=iso9899:199409. > And as we progress further into the 21st century, I expect support for > ancient obsolete versions of the C standard will become less and less > reliable. You'll end up with breakage on *modern* compilers, just to > support the Luddites. Is that really a path we want to go down? You have to convince the Luddites somehow, or risk losing them as your user base. Give them a killer feature, or at least show them their training / environment won't become worthless. <rant> For example, my editor doesn't support UTF-8, and I did raise an eyebrow when you submitted a SeaBIOS patch with the (C) copyright sign code-point :) UTF-8 would bring me nothing in a programmer's editor, and I *love* my current editor. NEdit 5.5 / Sep 30, 2004; with OpenMotif-2.1.32. OTOH git has killer features, it convinced me instantly. I don't mind trying new stuff, but please don't drag me kicking & screaming into enlightenment :) </rant> Laszlo (Luddite :)) ------------------------------------------------------------------------------ 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
