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

2017-05-16 Thread 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.

2017-05-16 Thread 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.

2017-05-16 Thread 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.

2017-05-16 Thread 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.

2017-05-16 Thread 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

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

2017-05-15 Thread David Grayson 
If I were a mingw-w64 committer, I probably wouldn't make that change,
but I am OK with it.  An argument in favor of that change is that it
isn't too hard to just use sed or carefully-placed #defines to fix any
Microsoft-style code that uses __in and __out.  (It's not ideal, but
not terrible.)  And once we get libstdc++ to stop using those names,
we could undo the change.

And if we do change mingw-w64, I agree the way to do it is to comment
out the __in and __out lines in driverspecs.h, rather than reverting
the patch I posted at the beginning of this thread.

--David

On Mon, May 15, 2017 at 1:57 AM, Mateusz  wrote:
> W dniu 2017-05-15 o 08:51, Liu Hao pisze:
>> On 2017/5/11 23:11, Kai Tietz wrote:
>>> I would prefer this too, but I don't believe that we can convince
>>> libstdc++ maintainers to modify their code for this.  Sadly the MS'
>>> platform sdk defines a lot of stuff, which collides some times with
>>> some projects.  We made about this already a lot of bad experiences
>>> ... especially in context of MIDL ... defining
>>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>>> Nevertheless it might be worth a try to ask libstdc++ people for those
>>> __in A good argument (and bad one too) might be that the double
>>> underscore symbols are reserved to compilers/system headers.  And
>>> well, C++ headers aren't really system headers, which is in general
>>> just a POV ;)
>> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The
>> compatibility with GNU libstdc++ and LLVM libcxx is more essential than
>> that with Windows in my opinion.
>
> +1
>
>>
>> These macros are defined after including _windows.h_ from official
>> Windows SDK, as shown in this example:
>>
>> 
>> 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.
>> 
>>
>>
>
>
> --
> 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

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

2017-05-15 Thread Mateusz 
W dniu 2017-05-15 o 08:51, Liu Hao pisze:
> On 2017/5/11 23:11, Kai Tietz wrote:
>> I would prefer this too, but I don't believe that we can convince
>> libstdc++ maintainers to modify their code for this.  Sadly the MS'
>> platform sdk defines a lot of stuff, which collides some times with
>> some projects.  We made about this already a lot of bad experiences
>> ... especially in context of MIDL ... defining
>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>> Nevertheless it might be worth a try to ask libstdc++ people for those
>> __in A good argument (and bad one too) might be that the double
>> underscore symbols are reserved to compilers/system headers.  And
>> well, C++ headers aren't really system headers, which is in general
>> just a POV ;)
> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The 
> compatibility with GNU libstdc++ and LLVM libcxx is more essential than 
> that with Windows in my opinion.

+1

> 
> These macros are defined after including _windows.h_ from official 
> Windows SDK, as shown in this example:
> 
> 
> 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.
> 
> 
> 


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

2017-05-15 Thread Liu Hao 
On 2017/5/11 23:11, Kai Tietz wrote:
> I would prefer this too, but I don't believe that we can convince
> libstdc++ maintainers to modify their code for this.  Sadly the MS'
> platform sdk defines a lot of stuff, which collides some times with
> some projects.  We made about this already a lot of bad experiences
> ... especially in context of MIDL ... defining
> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
> Nevertheless it might be worth a try to ask libstdc++ people for those
> __in A good argument (and bad one too) might be that the double
> underscore symbols are reserved to compilers/system headers.  And
> well, C++ headers aren't really system headers, which is in general
> just a POV ;)
I suggest we comment out `__in` and `__out` from _driverspecs.h_. The 
compatibility with GNU libstdc++ and LLVM libcxx is more essential than 
that with Windows in my opinion.

These macros are defined after including _windows.h_ from official 
Windows SDK, as shown in this example:


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.



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

2017-05-12 Thread David Grayson 
For anyone who is getting errors from the libstdc++ headers due to the
name conflicts for __in and __out, here are the commands you should
run when building GCC 6.3.0 to fix it:

cd libstdc++-v3
sed -i 's/\b__in\b/___in/g' \
  include/ext/random.tcc \
  include/ext/vstring.tcc \
  include/std/utility \
  include/std/tuple \
  include/std/istream \
  include/tr2/bool_set.tcc \
  include/tr2/bool_set \
  include/bits/basic_string.h \
  include/bits/basic_string.tcc \
  include/bits/locale_facets.h \
  include/bits/istream.tcc \
  include/tr1/utility \
  include/tr1/tuple
sed -i 's/\b__out\b/___out/g' \
  include/ext/random.tcc \
  include/ext/algorithm \
  include/ext/pb_ds/detail/debug_map_base.hpp \
  include/std/ostream \
  include/std/thread \
  include/tr2/bool_set \
  include/bits/ostream.tcc \
  include/bits/regex.tcc \
  include/bits/stl_algo.h \
  include/bits/locale_conv.h \
  include/bits/regex.h \
  include/bits/ostream_insert.h \
  include/tr1/regex \
  include/parallel/algo.h \
  include/parallel/set_operations.h \
  include/parallel/multiway_merge.h \
  include/parallel/unique_copy.h \
  include/experimental/algorithm \
  config/locale/dragonfly/c_locale.h \
  config/locale/generic/c_locale.h \
  config/locale/gnu/c_locale.h

--David

On Thu, May 11, 2017 at 9:55 AM, 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.
>
> 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.
> 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?
>
> Please note that I'm not trying to assign blame, I'm just trying to
> get Qt to compile with the latest mingw-w64 without using hacky
> workarounds.
>
> --David
>
> On Thu, May 11, 2017 at 7:29 AM, Liu Hao  wrote:
>> On 2017/5/11 21:51, David Grayson wrote:
>>> Unfortunately, my patch seems to break several classes in libstdc++,
>>> preventing Qt from building.  The problem is that driverspecs.h defines
>>> __in to be empty so we can compile Microsoft-type code that uses __in as a
>>> source annotation on function parameters while GCC's libstdc++ uses __in as
>>> the name of an input argument for many of its methods:
>>>
>>> $ egrep -lr '\b__in\b' /mingw32/include/
>>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>>> /mingw32/include/c++/6.3.0/ext/random.tcc
>>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>>> /mingw32/include/c++/6.3.0/istream
>>> /mingw32/include/c++/6.3.0/tr1/tuple
>>> /mingw32/include/c++/6.3.0/tr1/utility
>>> /mingw32/include/c++/6.3.0/tr2/bool_set
>>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>>> /mingw32/include/c++/6.3.0/tuple
>>> /mingw32/include/c++/6.3.0/utility
>>>
>>> One of the errors I get looks like this:
>>>
>>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>>> call to 'move()'
>>>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>>
>>> I don't think this is necessarily a problem with mingw-w64, or a problem
>>> with that patch.  Adrien Nader's attitude on this mailing list in
>>> 2015-11-03 was "Really, there's a platform and software is built on top of
>>> it; it is that software that is supposed to adapt to the platform."  
>>> Microsoft
>>> Windows and mingw-w64 are platforms that define __in to have a special
>>> meaning.  The software built on that platform (libstdc++) should adapt to
>>> the platform.
>> I CC'd gcc-help. Hope it helps.
>> Anyway Windows headers are really a can of worms (think about the macros
>> `min` and `max` for example).
>>
>>> One odd thing is that our __in gets defined in driverspecs.h, while
>>> Microsoft defines their __in in sal.h.  But specstrings.h (for both
>>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>>> shouldn't affect when the bug appears.
>> Both headers seem to be out of sync for years. I hope they can be
>> updated someday.

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

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

2017-05-11 Thread David Grayson 
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.

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

Please note that I'm not trying to assign blame, I'm just trying to
get Qt to compile with the latest mingw-w64 without using hacky
workarounds.

--David

On Thu, May 11, 2017 at 7:29 AM, Liu Hao  wrote:
> On 2017/5/11 21:51, David Grayson wrote:
>> Unfortunately, my patch seems to break several classes in libstdc++,
>> preventing Qt from building.  The problem is that driverspecs.h defines
>> __in to be empty so we can compile Microsoft-type code that uses __in as a
>> source annotation on function parameters while GCC's libstdc++ uses __in as
>> the name of an input argument for many of its methods:
>>
>> $ egrep -lr '\b__in\b' /mingw32/include/
>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> /mingw32/include/c++/6.3.0/ext/random.tcc
>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> /mingw32/include/c++/6.3.0/istream
>> /mingw32/include/c++/6.3.0/tr1/tuple
>> /mingw32/include/c++/6.3.0/tr1/utility
>> /mingw32/include/c++/6.3.0/tr2/bool_set
>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> /mingw32/include/c++/6.3.0/tuple
>> /mingw32/include/c++/6.3.0/utility
>>
>> One of the errors I get looks like this:
>>
>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>> call to 'move()'
>>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>
>> I don't think this is necessarily a problem with mingw-w64, or a problem
>> with that patch.  Adrien Nader's attitude on this mailing list in
>> 2015-11-03 was "Really, there's a platform and software is built on top of
>> it; it is that software that is supposed to adapt to the platform."  
>> Microsoft
>> Windows and mingw-w64 are platforms that define __in to have a special
>> meaning.  The software built on that platform (libstdc++) should adapt to
>> the platform.
> I CC'd gcc-help. Hope it helps.
> Anyway Windows headers are really a can of worms (think about the macros
> `min` and `max` for example).
>
>> One odd thing is that our __in gets defined in driverspecs.h, while
>> Microsoft defines their __in in sal.h.  But specstrings.h (for both
>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> shouldn't affect when the bug appears.
> Both headers seem to be out of sync for years. I hope they can be
> updated someday.

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

2017-05-11 Thread David Grayson 
Oh, I thought we should just get libstdc++ to patch their project.  I would
look for __in and any other badly-named parameters, and perhaps add a third
underscore to their names or something like that.  In the long term, that
would be nicer, because then users can have Microsoft-style code and
libstdc++ code used in the same translation unit and they don't have to
remember to use a guard on the include.

--David

On Thu, May 11, 2017 at 7:24 AM, Kai Tietz  wrote:

> Yes, that is a bit annoying ... sadly we can't do much about it.
>
> So I would suggest to add a guard to the include, so that it is
> user-defined, if this header should be included, or not.
> This might be a work-a-round for this, which should work for most.
>
> Regards,
> Kai
>
> 2017-05-11 15:51 GMT+02:00 David Grayson :
> > Unfortunately, my patch seems to break several classes in libstdc++,
> > preventing Qt from building.  The problem is that driverspecs.h defines
> > __in to be empty so we can compile Microsoft-type code that uses __in as
> a
> > source annotation on function parameters while GCC's libstdc++ uses __in
> as
> > the name of an input argument for many of its methods:
> >
> > $ egrep -lr '\b__in\b' /mingw32/include/
> > /mingw32/include/c++/6.3.0/bits/basic_string.h
> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> > /mingw32/include/c++/6.3.0/bits/istream.tcc
> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
> > /mingw32/include/c++/6.3.0/ext/random.tcc
> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
> > /mingw32/include/c++/6.3.0/istream
> > /mingw32/include/c++/6.3.0/tr1/tuple
> > /mingw32/include/c++/6.3.0/tr1/utility
> > /mingw32/include/c++/6.3.0/tr2/bool_set
> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> > /mingw32/include/c++/6.3.0/tuple
> > /mingw32/include/c++/6.3.0/utility
> >
> > One of the errors I get looks like this:
> >
> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
> for
> > call to 'move()'
> >  { return __pair_get<_Int>::__move_get(std::move(__in)); }
> >
> > I don't think this is necessarily a problem with mingw-w64, or a problem
> > with that patch.  Adrien Nader's attitude on this mailing list in
> > 2015-11-03 was "Really, there's a platform and software is built on top
> of
> > it; it is that software that is supposed to adapt to the platform."
> Microsoft
> > Windows and mingw-w64 are platforms that define __in to have a special
> > meaning.  The software built on that platform (libstdc++) should adapt to
> > the platform.
> >
> > One odd thing is that our __in gets defined in driverspecs.h, while
> > Microsoft defines their __in in sal.h.  But specstrings.h (for both
> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> > shouldn't affect when the bug appears.
> >
> > --David Grayson
> >
> > On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> > wrote:
> >
> >> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I
> purposely
> >> used the same include guard name as Microsoft.
> >>
> >> --David
> >>
> >> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
> >>
> >>>
> >>>
> >>>
> >>>  Forwarded Message 
> >>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
> >>> specstrings.h.
> >>> Date:   Wed, 10 May 2017 08:24:25 -0700
> >>> From:   David Grayson 
> >>> To: Liu Hao 
> >>>
> >>>
> >>>
> >>> OK, thanks.  I've attached a new patch where the #include is after the
> >>> __cplusplus stuff.
> >>>
> >>> I also included a second patch that will add an include guard for
> >>> specstrings.h, since Microsoft seems to do that too.
> >>>
> >>> driverspecs.h is also missing an include guard but it is part of the
> >>> React DDK so I didn't want to mess around with editing at the moment.
> >>>
> >>> --David
> >>>
> >>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao >> lh_mo...@126.com>> wrote:
> >>>
> >>> On 2017/5/10 10:34, David Grayson wrote:
> >>>
> >>> This patch adds "#include " near the end of
> >>> specstrings.h,
> >>> because the same is done in Microsoft's version of
> >>> specstrings.h.  With
> >>> this patch, I am able to build Microsoft's devcon utility
> without
> >>> modification.  Thanks!
> >>>
> >>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
> >>> #endif` block.
> >>>
> >>> Anyway, this header seems short of a header guard. I shall ask
> >>> someone for sure.
> >>>
> >>> -- 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
>

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

2017-05-11 Thread Liu Hao 
On 2017/5/11 21:51, David Grayson wrote:
> Unfortunately, my patch seems to break several classes in libstdc++,
> preventing Qt from building.  The problem is that driverspecs.h defines
> __in to be empty so we can compile Microsoft-type code that uses __in as a
> source annotation on function parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
> 
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
> 
> One of the errors I get looks like this:
> 
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>   { return __pair_get<_Int>::__move_get(std::move(__in)); }
> 
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
I CC'd gcc-help. Hope it helps.
Anyway Windows headers are really a can of worms (think about the macros 
`min` and `max` for example).

> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
Both headers seem to be out of sync for years. I hope they can be 
updated someday.


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

2017-05-11 Thread Kai Tietz 
Yes, that is a bit annoying ... sadly we can't do much about it.

So I would suggest to add a guard to the include, so that it is
user-defined, if this header should be included, or not.
This might be a work-a-round for this, which should work for most.

Regards,
Kai

2017-05-11 15:51 GMT+02:00 David Grayson :
> Unfortunately, my patch seems to break several classes in libstdc++,
> preventing Qt from building.  The problem is that driverspecs.h defines
> __in to be empty so we can compile Microsoft-type code that uses __in as a
> source annotation on function parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
>
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
>
> One of the errors I get looks like this:
>
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
>  { return __pair_get<_Int>::__move_get(std::move(__in)); }
>
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch.  Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform."  Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning.  The software built on that platform (libstdc++) should adapt to
> the platform.
>
> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h.  But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
>
> --David Grayson
>
> On Wed, May 10, 2017 at 9:44 AM, David Grayson 
> wrote:
>
>> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I purposely
>> used the same include guard name as Microsoft.
>>
>> --David
>>
>> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
>>
>>>
>>>
>>>
>>>  Forwarded Message 
>>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>>> specstrings.h.
>>> Date:   Wed, 10 May 2017 08:24:25 -0700
>>> From:   David Grayson 
>>> To: Liu Hao 
>>>
>>>
>>>
>>> OK, thanks.  I've attached a new patch where the #include is after the
>>> __cplusplus stuff.
>>>
>>> I also included a second patch that will add an include guard for
>>> specstrings.h, since Microsoft seems to do that too.
>>>
>>> driverspecs.h is also missing an include guard but it is part of the
>>> React DDK so I didn't want to mess around with editing at the moment.
>>>
>>> --David
>>>
>>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > lh_mo...@126.com>> wrote:
>>>
>>> On 2017/5/10 10:34, David Grayson wrote:
>>>
>>> This patch adds "#include " near the end of
>>> specstrings.h,
>>> because the same is done in Microsoft's version of
>>> specstrings.h.  With
>>> this patch, I am able to build Microsoft's devcon utility without
>>> modification.  Thanks!
>>>
>>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>>> #endif` block.
>>>
>>> Anyway, this header seems short of a header guard. I shall ask
>>> someone for sure.
>>>
>>> -- 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
>>>
>>>
>>
> --
> 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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

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

2017-05-11 Thread David Grayson 
Unfortunately, my patch seems to break several classes in libstdc++,
preventing Qt from building.  The problem is that driverspecs.h defines
__in to be empty so we can compile Microsoft-type code that uses __in as a
source annotation on function parameters while GCC's libstdc++ uses __in as
the name of an input argument for many of its methods:

$ egrep -lr '\b__in\b' /mingw32/include/
/mingw32/include/c++/6.3.0/bits/basic_string.h
/mingw32/include/c++/6.3.0/bits/basic_string.tcc
/mingw32/include/c++/6.3.0/bits/istream.tcc
/mingw32/include/c++/6.3.0/bits/locale_facets.h
/mingw32/include/c++/6.3.0/ext/random.tcc
/mingw32/include/c++/6.3.0/ext/vstring.tcc
/mingw32/include/c++/6.3.0/istream
/mingw32/include/c++/6.3.0/tr1/tuple
/mingw32/include/c++/6.3.0/tr1/utility
/mingw32/include/c++/6.3.0/tr2/bool_set
/mingw32/include/c++/6.3.0/tr2/bool_set.tcc
/mingw32/include/c++/6.3.0/tuple
/mingw32/include/c++/6.3.0/utility

One of the errors I get looks like this:

/nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
call to 'move()'
 { return __pair_get<_Int>::__move_get(std::move(__in)); }

I don't think this is necessarily a problem with mingw-w64, or a problem
with that patch.  Adrien Nader's attitude on this mailing list in
2015-11-03 was "Really, there's a platform and software is built on top of
it; it is that software that is supposed to adapt to the platform."  Microsoft
Windows and mingw-w64 are platforms that define __in to have a special
meaning.  The software built on that platform (libstdc++) should adapt to
the platform.

One odd thing is that our __in gets defined in driverspecs.h, while
Microsoft defines their __in in sal.h.  But specstrings.h (for both
mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
shouldn't affect when the bug appears.

--David Grayson

On Wed, May 10, 2017 at 9:44 AM, David Grayson 
wrote:

> Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I purposely
> used the same include guard name as Microsoft.
>
> --David
>
> On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:
>
>>
>>
>>
>>  Forwarded Message 
>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>> specstrings.h.
>> Date:   Wed, 10 May 2017 08:24:25 -0700
>> From:   David Grayson 
>> To: Liu Hao 
>>
>>
>>
>> OK, thanks.  I've attached a new patch where the #include is after the
>> __cplusplus stuff.
>>
>> I also included a second patch that will add an include guard for
>> specstrings.h, since Microsoft seems to do that too.
>>
>> driverspecs.h is also missing an include guard but it is part of the
>> React DDK so I didn't want to mess around with editing at the moment.
>>
>> --David
>>
>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao  lh_mo...@126.com>> wrote:
>>
>> On 2017/5/10 10:34, David Grayson wrote:
>>
>> This patch adds "#include " near the end of
>> specstrings.h,
>> because the same is done in Microsoft's version of
>> specstrings.h.  With
>> this patch, I am able to build Microsoft's devcon utility without
>> modification.  Thanks!
>>
>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>> #endif` block.
>>
>> Anyway, this header seems short of a header guard. I shall ask
>> someone for sure.
>>
>> -- 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
>>
>>
>
--
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.

2017-05-10 Thread David Grayson 
Yeah, sorry, I only sent those patches to LH by mistake.  Yes, I purposely
used the same include guard name as Microsoft.

--David

On Wed, May 10, 2017 at 8:55 AM, Liu Hao  wrote:

>
>
>
>  Forwarded Message 
> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
> specstrings.h.
> Date:   Wed, 10 May 2017 08:24:25 -0700
> From:   David Grayson 
> To: Liu Hao 
>
>
>
> OK, thanks.  I've attached a new patch where the #include is after the
> __cplusplus stuff.
>
> I also included a second patch that will add an include guard for
> specstrings.h, since Microsoft seems to do that too.
>
> driverspecs.h is also missing an include guard but it is part of the React
> DDK so I didn't want to mess around with editing at the moment.
>
> --David
>
> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > wrote:
>
> On 2017/5/10 10:34, David Grayson wrote:
>
> This patch adds "#include " near the end of
> specstrings.h,
> because the same is done in Microsoft's version of
> specstrings.h.  With
> this patch, I am able to build Microsoft's devcon utility without
> modification.  Thanks!
>
> You must `#include` that header AFTER the `#ifdef __cplusplus ...
> #endif` block.
>
> Anyway, this header seems short of a header guard. I shall ask
> someone for sure.
>
> -- 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
>
>
--
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