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

[Liu Hao]

On 2017/5/16 18:09, Jonathan Wakely wrote:
> Hmm, if it's not defined when compiling with GCC then where does the
> conflict come from?
> 
These macros weren't there until recently because of the feature request 
by David Grayson. They don't exist in any release versions of MinGW-w64 
so there is no problem.

But in practice I (so is MSYS2, as well as David I believe) follow 
closely with git master, which got broken a few days ago.

-- 
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

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

[Jonathan Wakely]

On 16 May 2017 at 11:09, Jonathan Wakely  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  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 
>> #include 
>>
>> 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 
>> #include 
>>
>> 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.

--
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

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

[Jonathan Wakely]

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  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 
> #include 
>
> 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 
> #include 
>
> 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.

--
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

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

[Liu Hao]

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  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 
#include 

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 
#include 

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

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

[Jonathan Wakely]

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?

> 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 order to avoid problems in
future.

--
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