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.
------------------------------------------------------------
>
>> 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.
--
Best regards,
LH_Mouse
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
