[cfe-dev] math.h on Windows

[Douglas Gregor]

On Oct 13, 2009, at 1:02 PM, John Thompson wrote:

> There is a compile error when compiling VC++'s math.h.
>
> Apparently, the GNU extentions are still enabled by default for  
> Windows VC++ builds, in particular "_Complex".
>
> This conflicts with the parameter name in:
>
> _CRTIMP double  __cdecl _cabs(__in struct _complex _Complex);
>
> During my investigation, I tried turning off the GNU extensions when  
> the Microsoft extensions are enabled, but this is problematic with a  
> number of the tests, which use _Complex, and probably lots of other  
> places.  This raised the question in my mind as to whether the GNU  
> extensions should be enabled in this case, but I figure it's  
> probably better that way, making the compiler more flexible.

_Complex is currently a keyword in every mode. We could make it only  
be a keyword in C99 or GNU mode, then make sure that neither of these  
modes is turned on by default when Clang is built with VC++. That  
probably makes sense, since VC++ doesn't support C99 or many GNU  
extensions anyway.

We can always force tests into specific modes (turning off Microsoft  
extensions, turning on GNU extensions or C99, whatever), rather than  
trying to work around problems that are unlikely to show up in code  
that compiles with VC++.

> Therefore, one way to make this work would be to change the parser a  
> bit to detect this case, and treat the _Complex token as an  
> identifier in this case.  The error originates from line 410 of  
> DeclSpec.cpp.
> Would this be a reasonable solution?

I'd really rather not do this. We currently have one hack of this  
form, with __is_pod, because it occurs in a super-critical library  
(GNU libstdc++ <= 4.2), but we should try not to do that often. It's  
very obscure, and will lead to weird behavior. ("If I include  
<math.h>, I can no longer use complex types!")

> Actually, today there are two other errors in compiling this file,  
> related to wchar_t being defined already.  One solution is to define  
> _WCHAR_T_DEFINED for the Visual Studio targets, which will disable  
> the conflicting definition in crtdefs.h, and possibly elsewhere.   
> The enclosed patch does this, which if you will approve it, I'll  
> check it in.


What is the actual issue with the redefinition of wchar_t? Are they  
creating a typedef of wchar_t in their headers? Does the VC++ compiler  
implicitly define _WCHAR_T_DEFINED?

Regarding the patch itself: if VC++ is implicitly defining  
_WCHAR_T_DEFINED, then we should be doing so based on the Microsoft  
flag in the preprocessor-definitions, since it is effectively a  
Microsoft extension. Defining this information in the target probably  
isn't what we want.

> To make the tests less dependent on headers, I've also enclosed a  
> mathtest.patch file for eliminating the math.h inclusion in the  
> failed tests I've looked at so far.

These look good, thanks!

	- Doug