Re: [edk2] StdLib: the long standing build error

Subject: Re: [edk2] StdLib: the long standing build error

From: Laszlo Ersek <>


Date: 2014-08-07 01:43:48

On 08/06/14 17:03, Andrew Fish wrote:
> =

> On Aug 6, 2014, at 7:02 AM, Laszlo Ersek  > wrote:
> =

>> On 08/06/14 00:31, Olivier Martin wrote:
>>> Why do not put '*va_arg(ap, long double *) =3D res;' which seems to be
>>> the valid solution and add a #ifdef for the faulty toolchains.
>>> I do not feel fair to keep a workaround by default when it blocks all
>>> the other toolchains.
>> Would the attached patch work?
>> (Actually, since it is very trivial, I'm quite sure it has been
>> investigated before. So I'll reformulate: why isn't the attached
>> approach acceptable?)
> =

> Laszlo,
> =

> I=92d recommend using the compiler defined value and adding a comment on
> why it is needed:
> =

> #if defined(_MSC_EXTENSIONS)
> =

> and not adding a new #define for this. =

> =

> The code in the #ifdef assumes a specific compiler implementation of
> va_list and thus is totally non portable and tied a specific compiler. =

> =

> _MSC_EXTENSIONS  is used in other places in the edk2 to deal with
> compiler
> specifics:

That's awesome. I was incredulous that no such toolchain-dependent code
existed yet, but my searches for "MSFT" and "MSVC" in source files lead
to no results. It's great that the right macro,  _MSC_EXTENSIONS, is
already there. The question is now if a toolchain ifdef has been
considered before, and if so, why wasn't accepted. If I can see it
right, Olivier started the thread about one year ago.

Thank you!

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. =

Build a bridge from your legacy apps to the future.
edk2-devel mailing list