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?
>>
>>> You can see several uses of __in in Microsoft-style code here:
>>>
>>> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>>>
>>> I would be willing to create, test, and submit a patch that changes
>>> libstdc++ to use ___in (with three underscores) to avoid this issue.
>>
>>
>> Three underscores is disgusting and wrong.
>>
>>> I expect that to be a pretty safe change that doesn't break anything.
>>> Maybe I would add a test to help prevent this from happening in the
>>> future. Would the GCC maintainers consider accepting such a patch?
>>
>>
>> Yes, but not by simply adding an underscore.
>>
>> The patch should add "__in" to
>>
>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
>> and maybe to testsuite/17_intro/names.cc in ordr to avoid problems in
>> future.
>>
> Yes we can do that and we appreciate your respect for Windows users.
We want libstdc++ to be as portable as possible (as long as I don't
have to do all the work myself :-)
I had a quick look at our uses of __in and I think many of them could
be changed to __inp (for pointers) or __is (for istreams). A few might
need some extra thought.
