This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]