On 16 May 2017 at 11:09, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
> On 16 May 2017 at 11:01, Liu Hao wrote:
>> On 2017/5/16 17:35, Jonathan Wakely wrote:
>>>
>>> On 11 May 2017 at 17:55, David Grayson wrote:
>>>>
>>>> Hello, gcc-help.
>>>>
>>>> There is an incompatibility between libstdc++ and the headers provided
>>>> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter
>>>> name in several places while the Microsoft headers define __in as a
>>>> preprocessor macro as part of their Source Annotation Language.
>>>
>>>
>>> Is it not possible to disable that noise somehow so that the macros
>>> aren't defined?
>>
>> The macros were introduced by ReactOS DDK. I have no idea where they came
>> from but I believe they must originate from Microsoft headers and nowhere
>> else.
>>
>> The disclaimer of <driverspecs.h> that defines `__in`, `__out` and `__inout`
>> describes the purpose of these macros:
>> ------------------------------------------------------------
>> /*
>> * PROJECT: ReactOS DDK
>> * COPYRIGHT: This file is in the Public Domain.
>> * FILE: driverspecs.h
>> * ABSTRACT: This header stubs out Driver Verifier annotations to
>> * allow drivers using them to compile with our header set.
>> */
>> ------------------------------------------------------------
>>
>> I am not familiar with Driver Verifier but after some quick googling it
>> seems something similar to valgrind for Windows drivers (i.e. libraries that
>> run in the kernel space).
>>
>> The macro `__in` is exposed to programs compiled using MSVC so it can hardly
>> be suppressed without causing incompatibility with MS code.
>> ------------------------------------------------------------
>> E:\Desktop>cat test.c
>> #include <stdio.h>
>> #include <windows.h>
>>
>> int main(){
>> #if defined(__in)
>> puts("__in is defined.");
>> #else
>> puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fea.exe
>> test.c
>>
>> E:\Desktop>cat test.c
>> #include <stdio.h>
>> #include <windows.h>
>>
>> int main(){
>> #if defined(__in)
>> puts("__in is defined.");
>> #else
>> puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fe:a.exe
>> test.c
>>
>> E:\Desktop>a.exe
>> __in is defined.
>>
>> E:\Desktop>gcc test.c
>>
>> E:\Desktop>a.exe
>> __in is not defined.
>> ------------------------------------------------------------
>
> Hmm, if it's not defined when compiling with GCC then where does the
> conflict come from?
Oh sorry, I re-read the earlier messages and understand now.
