Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD

[Jonathan Wakely]

On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc,  wrote:

> On 26.11.2022 20:04, Pali Rohár wrote:
> > On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> >> But then, with you replying to
> >> me specifically, perhaps you're wrongly assuming that I would be
> >> planning to look into addressing any or all of these? My earlier reply
> >> was merely to point out that _some_ work has already been done ...
> >
> > I added into CC also gcc, ld and mingw mailing list. If this is not
> > enough, could you tell me who to contact about those issues?
>
> That's probably enough, sure. I merely tried to set expectations right,
> since you did reply To: me (and lists were only on Cc: - it being the
> other way around would have demonstrated that you're not asking me
> specifically).
>

That's just how most mailers do "Reply All", I don't think it out implies
anything. Removing the Cc list and *only* replying to you would be
different.

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::regex freezes in Japanese locale

[Jonathan Wakely]

On Sun, 24 Jan 2021 at 08:15, Liu Hao  wrote:
>
> 在 2021-01-24 02:05, Hannes Domani via Mingw-w64-public 写道:
> > Am Samstag, 23. Januar 2021, 16:46:18 MEZ hat Jeroen Ooms 
> >  Folgendes geschrieben:
> >
> >> A user of the R programming language has reported that std::regex
> >> causes a hang for certain regular expressions when running in Japanese
> >> locale. I was able to reproduce this both with our production
> >> toolchain (mingw-w64 v5 + gcc 8) as well as the latest msys2
> >> toolchains.
> >>
> >> Is this a bug in mingw-w64 or elsewhere? Below a minimal example:
> >>
> >> #include 
> >> int main() {
> >> setlocale(LC_ALL, "Japanese");
> >> std::regex reg("[0-9]");
> >> return 0;
> >> }
> >
> > I can reproduce this as well, it took 108 seconds to finish here.
> >
> > Deep in regex is this function:
> > std::__detail::_BracketMatcher, false, 
> > false>::_M_make_cache(std::integral_constant)
> >
> > This caches transformed values of the unicode values 0-255 to the current
> > locale, with strxfrm_l [1].
> > This fails for a lot of them for japanese, and as documented, strxfrm_l
> > returns INT_MAX in this case.
> > But std::collate::do_transform does not handle any error case, it uses all
> > return values as the length of the transformed string.
> > And then it creates a copy of this 2GB string, which takes a lot of time,
> > around ~1s for each failing character.
> >
> > It think this should be reported to gcc (libstdc++).
> >
> >
> > [1] 
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strxfrm-wcsxfrm-strxfrm-l-wcsxfrm-l?view=msvc-160
> >
> >
>
> Add CC libstdc++ and jwakely.
>
> Despite Microsoft docs, the standard `_?(str|wcs)xfrm(_l)?` functions don't 
> have return values to
> indicate errors. This issue seems to be caused by invalid MBCSs passed to 
> `_strxfrm_l`, which should
> be avoided.

I think this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723


___
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: [patch] Reimplement GNU threads library on native Windows

[Jonathan Wakely]

On 02/07/19 12:15 +0200, Jacek Caban wrote:


On 02/07/2019 12:12, Jacek Caban wrote:

On 02/07/2019 11:57, Liu Hao wrote:


在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers 
(as handles
imply resource ownership and are not unique identifiers); 
thread IDs (as

`DWORD` or `unsigned long`) would be a better alternative.
This was considered but ultimately rejected, as you can do 
nothing with a
thread Id, i.e. you need a handle for everything.  But the 
__gthread_equal

routine does compare the Ids and not the handles.


The `OpenThread()` function can obtain a handle by thread ID. It returns
a real handle that has to be closed when it is out of use. Using the
pseudo handle returned by `GetCurrentThread()` may be more efficient if
the target thread ID is equal to `GetCurrentThreadId()`.



The problem with thread id is that it's not valid nor guaranteed to 
be identical after the thread is terminated. A handle needs to be 
used for that.



I meant unique, not identical.


The C++ standard says:

"The library may reuse the value of a thread::id of a terminated
thread that can no longer be joined."

So that's not a reason to use a handle.



___
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: [patch] Reimplement GNU threads library on native Windows

[Jonathan Wakely]

On 02/07/19 20:14 +0800, Liu Hao wrote:

在 2019/7/2 下午8:00, Jonathan Wakely 写道:

The C++ standard says:

"The library may reuse the value of a thread::id of a terminated
thread that can no longer be joined."

So that's not a reason to use a handle.


According to MSDN [1] a thread ID is valid 'until the thread has been
terminated' so I presume a terminated but unclosed thread does not have
a thread ID.


What do you mean by "unclosed thread"? If I read it correctly, the MSDN page
refers to closing a handle (which makes sense), not closing a thread.


This could also mean that there is no effect way to denote a thread
uniquely. As a consequence libstdc++ may have to its own bookkeeping
mechanism.


As I said in my last mail, libstdc++ does not need a way to denote a
thread uniquely.

I'm not objecting to Eric's use of a HANDLE for a thread::id, as
his justification makes sense. I'm just saying we don't need a unique
ID that outlives the thread, because that's not a requirement.



[1]
https://docs.microsoft.com/en-us/windows/desktop/ProcThread/thread-handles-and-identifiers

--
Best regards,
LH_Mouse







___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 7.2 build bugs on Windows 8.1 and Windows 10

[Jonathan Wakely]

On 25 October 2017 at 12:24, Liu Hao wrote:
> On 2017/10/25 18:35, Jonathan Wakely wrote:
>>
>> Is this because -std=c99 sets __STRICT_ANSI__?
>>  > The C++ runtime is not built with -std=c99, of course.
>
>
>>
>
>
> No. It will not compile despite the `-std=` option, because
> `_aligned_{malloc,free}` are conditionally `#ifdef`'d out by the following
> code (and that is why I think it is a bug because avoidance of spurious
> `collisions` results in no declarations at all):
>
> ```
> /* Make sure that X86intrin.h doesn't produce here collisions.  */
> #if (!defined (_XMMINTRIN_H_INCLUDED) && !defined (_MM_MALLOC_H_INCLUDED))
> || defined(_aligned_malloc)
> #define __DO_ALIGN_DEFINES
> #endif
>
> (... abridged ...)
>
> #ifdef __DO_ALIGN_DEFINES
>   _CRTIMP void __cdecl _aligned_free(void *_Memory);
>   _CRTIMP void *__cdecl _aligned_malloc(size_t _Size,size_t _Alignment);
> #endif
> ```
>
>> I don't really care whether _aligned_malloc works in arbitrary C
>> programs, what I care about is whether it works in
>> libsupc++/new_opa.cc when _GLIBCXX_HAVE__ALIGNED_MALLOC is defined.
>>
>> I assume new_opa.cc does build for MinGW-w64, but does it build for
>> MinGW? That still seems to be stuck on GCC 4.x
>>
>
> Yeah this reminds me that the bulk of the community is still having problems
> with distinguishing MinGW-w64 from MinGW. Unless the OP clarify which one
> he/she is using exactly, this discussion is much likely going to be
> meaningless. o_O

I was asking David about his previous build failures, where he clearly
said "the 32-bit MinGW" so I assume that's what he meant.

You're the one who added the w64 mailing list when we weren't discussing w64 :-)

--
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] GCC 7.2 build bugs on Windows 8.1 and Windows 10

[Jonathan Wakely]

On 25 October 2017 at 02:50, Liu Hao wrote:
> On 2017/10/24 23:55, Jonathan Wakely wrote:
>>
>> On 23 October 2017 at 15:55, David Gressett wrote:
>>>
>>> gcc needs some substantial patching to to build on Windows.
>>> The details depend on whether you are building a 64-bit or a 32-bit gcc.
>>>
>>> There are two projects on Sourceforge which deal with gcc  on Windows:
>>>
>>> MinGW  (32-bit) and MinGW-w64 (64-bit)
>>>
>>> The mailing lists for those projects are the best places to go to for
>>> information about
>>>   building on Windows for a Windows target.
>>
>>
>> Did you ever get to the bottom of the problem in
>> https://gcc.gnu.org/ml/gcc-help/2017-04/msg00133.html ?
>>
>> I see _aligned_malloc in MinGW's  so if the configure script
>> found it then I don't understand how it can be missing later.
>>
>> If that code still doesn't build we need a bug report.
>>
>
> The attached program would not compile if the first line were uncommented,
> which looks like a bug to me.
>
> ```
> // #include 
> #include 
> #include 
>
> int main(void){
> void *ptr;
>
> ptr = _aligned_malloc(1000, 32);
> printf("ptr = %p\n", ptr);
> _aligned_free(ptr);
> }
> ```
>
> ```
> E:\Desktop>gcc -Wall -Wextra -pedantic -pedantic-errors -std=c99 test.c

Is this because -std=c99 sets __STRICT_ANSI__?

The C++ runtime is not built with -std=c99, of course.

I don't really care whether _aligned_malloc works in arbitrary C
programs, what I care about is whether it works in
libsupc++/new_opa.cc when _GLIBCXX_HAVE__ALIGNED_MALLOC is defined.

I assume new_opa.cc does build for MinGW-w64, but does it build for
MinGW? That still seems to be stuck on GCC 4.x

--
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 <jwakely@gmail.com> 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.

[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] Adding a new thread model to GCC

[Jonathan Wakely]

On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is referenced in 
>> gcc/libstdc++-v3/include/std/mutex:157
>>   __gthread_time_t __ts = {
>> static_cast(__s.time_since_epoch().count()),
>> static_cast(__ns.count())
>>   };
>> This definition uses a braced-init-list that has two elements and is 
>> unsuitable for scalar types.
>
> Yes I know.
>
> What I meant is that there's no fundamental reason it needs to be a
> struct. That code could be changed.

However, that code in  is only needed for timed mutexes, and I
thought you said that wouldn't be supported.

There is code using __gthread_time_t in  that
needs to work even if timed mutexes are not supported.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it 
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
>   SHLIB_PTHREAD_CFLAG = -pthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
>
> I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified 
> the two lines to:
>   SHLIB_PTHREAD_CFLAG = -lmcfgthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread
>
> It didn't work and I got a number of undefined references. The command line 
> that invoked the linker didn't include either option.
>
> How to solve this problem?

What are the linker errors? When do they happen?

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 17 April 2016 at 17:56, lh_mouse  wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements 
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_time_t be a struct or a plain integral type?
> The 'struct timespec' used by pthread is a struct introduced in POSIX.
> However my implementation uses a plain uint64_t.

I don't see why it has to be a struct, it just has to be suitable as
an argument to the relevant __gthread functions.

If the current code assumes a struct and the Windows API calls need an
integer then either the existing code needs to be made more flexible,
or you need to define it as a struct and then convert to an integer
inside your new gthread wrapper functions.


> 1) How to obtain a __gthread_time_t representing the current time?
> According to Linux man pages, the timeout parameter of 
> pthread_cond_timedwait() is the same as gettimeofday() - that is, it uses the 
> wall clock.
> My implementation uses GetTickCount64() - that is, my implementation uses a 
> monotonic clock.

std::condition_variable::__clock_t must be a typedef for the clock
used by the underlying implementation, so it sounds like you should
use std::chrono::steady_clock for your thread model.


> Quoting from ISO/IEC WG21 Draft N4582 (C++1z):
> [quote]
> 30.4.1.3.1 Class timed_mutex [thread.timedmutex.class]
> ...
> template 
> bool try_lock_for(const chrono::duration& rel_time);
> template 
> bool try_lock_until(const chrono::time_point& abs_time);
> ...
> [/quote]
> the std::timed_mutex::try_lock_for() function template shall accept any clock 
> type, hence we have to do timestamp translation. It is also important to know 
> how libstdc++ handles this.

All conversions are done using the std::chrono facilities, before any
conversion to __gthread_time_t. That means the conversions are
portable.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 13 April 2016 at 10:17, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being 
> compatible with very old Windows versions, also having a number of drawbacks:
>   0) its implementation is very inefficient, and
>   1) its mutexes and condition variables require dynamic initialization and 
> are unusable in C++11 as std::mutex requires a `constexpr` constructor, and
>   2) allocating a number of rarely used mutexes or condition variables would 
> eventually make the system run out of kernel objects.
>
> As a solution for 1) and 2), Microsoft introduced keyed events, details of 
> which can be found here:
> http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/
>
> In one word: the Windows SRWLOCK and CONDITION_VARIABLE have been introduced 
> since Vista and are working well without any dynamic initialization, just 
> like FUTEX.
> But there are still some major drawbacks:
>   0) the SRWLOCK can be used as an exclusive mutex but it does not have an 
> equivalent function to pthread_mutex_timedwait, and

Some of our supported targets don't support pthread_mutex_timedwait
either (at least Mac OS X and HP-UX) so we have code in libstdc++ to
support mutexes but not timed mutexes. That might also work for your
new model.

>   1) the CONDITION_VARIABLE can only be used with SRWLOCK and 
> CRITICAL_SECTION and no user-defined mutexes can be supportd.

That's OK, std::condition_variable only needs to work with std::mutex,
and then std::condition_variable_any (which works with user-defined
mutexes) only requires std::mutex and std::condition_variable. The
code to use user-defined mutexes is portable C++11, so doesn't need
any platform-specific code.

> As a solution, I come up with my own library: 
> https://github.com/lhmouse/mcfgthread
> With 4 threads contending my mutex implementation turns to be 10 times faster 
> than the gthr-win32 implementation on my Xeon E3-1230 v3 processor.
> I have also done some research on gthr.h and successfully created a wrapper 
> for __gthread_* functhins, which can be found in mcfgthread/src/env/gthread.h.

Great! I haven't looked at the code, but I've been hoping someone
would do something like this to improve the std::mutex and
std::condition_variable implementations for modern Windows systems.


> I am currently looking for ways to integrate this library into gcc as a new 
> thread model, let's say 'nt6' for example, so GCC can be configured with 
> --enable-threads=nt6.
> But there is so little documentation about that. If someone know how to add a 
> new thread model in GCC, I would appreciate that.

See line 1589 in gcc/configure.ac, where the allowed thread models are
defined. Your gthreads wrapper header should be added as
libgcc/config/i386/gthr-nt6.h and you might also need some changes to
libgcc/configure.ac (see how it handles the existing gthr-win32.h
model).

You will need to use autoconf to regenerate the configure files after
editing the configure.ac files (or for now you can just edit the
configure files by hand, but eventually changes must go into the
configure.ac files). I can probably help with that, although I can't
build or test anything on Windows.

Once you've added the new thread model as a gthr-xxx.h file in libgcc
there will also be some work needed in libstdc++ to detect and
correctly use the new model (e.g. to detect that the timedwait
functions are not supported, so that timed mutexes will be disabled).

We might want to discuss that latter part on the libstdc++ list.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] toUpper()

[Jonathan Wakely]

On 30 June 2015 at 23:58,  p...@arbolone.ca wrote:
 I would like to write a function to capitalize letters, say...
 std::wstring toUpper(const std::wstring wstr){
 for ( auto it = wstr.begin(); it != wstr.end(); ++it){
global_wapstr.append(std::towupper(it));

 }
 }

 This doesn’t work, but doesn’t the standard already have something like
 std::wstring::toUpper(...)?

This is not a question about using GCC, it's about general C++
programming, so is inappropriate for the gcc-help list.

See 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/strings.html#std.strings.string
for some more information on the points Martin made.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCCG with C++11

[Jonathan Wakely]

On 28 May 2015 at 18:22, Martin Sebor wrote:
 [*] The Feature Testing Recommendations For C++ proposal (N4440
 being the latest I could find) tries to alleviate it by providing
 test macros for individual features. I know Clang implements parts
 of it but don't know what its status is in GCC.
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html

4.9 and above define those macros.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] I am in a in-path

[Jonathan Wakely]

On 28 May 2015 at 00:15, Hotmail (ArbolOne) wrote:
 I know, I know, this is not a C++ question, but, as I said, I am in a
 in-path, I don't know what to do in this case.

I have no idea what an in-path is (impasse?) but you've sent another
off-topic post that is not about GCC.

For general programming questions please find somewhere like
StackOverflow.com to seek help. This list is for questions about using
GCC.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCCG with C++11

[Jonathan Wakely]

On 28 May 2015 at 16:51, Martin Sebor wrote:
 The standard specifies that implementations conforming to C++
 11 must define the __cplusplus macro to 201103L, and recommends
 that non-conforming compilers (presumably those that aim to be
 C++11 conforming but whose support is incomplete) should use
 a value with at most five decimal digits.

 C++ 98 defines __cplusplus to 199711L, and C++ 14 to 201402L.

 With that, the following should cover past and future cases:

   #if __cplusplus == 199711L
 // C++ 98 conforming implementation
   #elif __cplusplus == 201103L
 // C++ 11 conforming implementation
   #elif __cplusplus == 201402L
 // C++ 14 conforming implementation
   #elif __cplusplus  201402L
 // future C++ implementation
   #elif 0  __cplusplus  __cplusplus  10L
 // non-conforming C++ implementation
   #else
 // not C++ or a non-conforming C++ implementation
   #endif

Until GCC 4.7.0 __cplusplus was always defined to 1, even though C++11
support in 4.6.4 was OK, and C++98 support was mostly complete.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCCG with C++11

[Jonathan Wakely]

On 28 May 2015 at 16:24, Hotmail (ArbolOne) arbol...@hotmail.ca wrote:
 If I am not mistaken _MSC_VER = 1600 is the version that started
 implementing C++11. So, I test for that version of the compiler in my code,
 i.e.
 #ifdef _MSC_VER = 1600

 #endif
 I would like to do the same for __GNUG__, but what version of g++ started
 implementing C++11?

4.3 (see https://gcc.gnu.org/projects/cxx0x.html) but it's not much
use knowing when support started appearing if you need to use a
feature that wasn't supported until later.

GCC 4.8.1 has complete C++11 language support, 5.1 has complete C++11
library support.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 10 May 2012 15:03, K. Frank wrote:

 Neither of these shows --enable-threads of any flavor (in gcc -v), but both
 show Thread model: win32 in the gcc -v output.

Yep, if you don't explicitly configure with --enable-threads then the
configure script picks a suitable default, which is win32 on
Windows.


 If you use GCC built with --enable-threads=posix then you shouldn't
 need to implement thread, it should be provided.

 No, this is not strictly true.  Prior to Kai's winpthread implementation
 and Ruben's thread-enabled build (or the tweaks I made to get
 thread working), building a windows version of gcc with
 --enable-threads=posix won't, in and of itself, give you a working
 thread.  One reason, among others, is that the posix version of
 gcc's thread relies on the pthreads thread handle being a primitive
 integral type.  This is not required by the posix standard, but is how
 unix / linux pthreads has historically been implemented.  However,
 pthreads-w32 uses (a pointer to) a struct as its thread handle,

Yes, I don't think we have an open bugzilla report about that
portability problem, but it's a known issue.

 So you either need a little tweak to accommodate this handle
 difference, or follow Kai's approach of providing a windows version
 of pthreads that uses an integral thread handle (winpthreads).

Have those changes come back upstream? It sounds as though they should do.


 The code is all open source, feel free to read it.

 Yes, of course, as a last resort.  But it's generally not my first choice.
 (By way of analogy, I find it more practical to read the c++11 standard
 for thread, or ask questions in the c++ news group, rather than read
 the gcc source code for thread.)

That makes sense for thread because the standard is the
authoritative source.  For GCC's configuration the GCC sources are the
authoritative source :-)

Sorry if my last mail seemed impatient, I do appreciate your feedback
based on your own experience of implementing thread.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 7 May 2012 18:35, K. Frank wrote:
 Hello Ruben and Gabriel!

N.B. I'm not on the mingw lists, so please keep me CC'd if you want
responses or any help from me in enhancing libstdc++ to work better on
Windows.


 And my P.S.:  As I mentioned in my earlier post, I have been using Ruben's
 thread-enabled build, and it passes all of my tests.  So the approach of
 sticking with the winpthreads implementation of thread and directing
 any available manpower to fixing and/or improving it rather than to building
 a separate implementation seems on the surface sensible.

The C++11 thread library exposes native OS handle via the
native_handle() member functions.  A thread implementation based
on Windows thread primitives would allow mixing std::thread with
WaitForMultipleObjects, which may be preferable to people who want to
use mingw's std::thread and combine it with their own code.  I don't
know if such people exist, I never use Windows except to run Putty to
connect to GNU/Linux hosts.  If no mingw users care about
--enable-threads=win32 and don't want a new --enable-threads=win64
then yes, just using --enable-threads=posix and winpthreads seems
sensible.  I guess that's a decision for the mingw maintainers.

If however, users want --enable-threads=win32, then my first
suggestion seems like a reasonable way to give them a better
experience than they have today.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 7 May 2012 18:28, K. Frank wrote:
 Hello Gabriel (and Ruben)!

 By the way, I'm the guy Ruben mentioned in his subsequent post.

 On Sat, May 5, 2012 at 11:20 PM, Gabriel Dos Reis
 g...@integrable-solutions.net wrote:
 Including the mingw64 project about this.

 On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely jwakely@gmail.com 
 wrote:
 For GCC 4.7 I enabled most of thread (without timed mutexes) on Mac
 OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained.  I
 think we could quite easily do the same again for the win32 thread
 model (defined in gthr-win32.h) so that thread and mutex are
 available (including timed mutexes), but without condition_variable
 and future.

 Just my opinion:  One could make the macro more fine-grained, but I
 really wouldn't want to do this.  If I'm using thread I'm using c++11,
 so I like to think I'm in the modern world.  I think (in the modern world)
 that condition variables are a core part of threading, so I'd find is a
 significant limitation if my c++11 implementation didn't have them.

Well currently you get none of the thread support when GCC is built
with --enable-threads=win32.  IMHO that's an even more significant
limitation than no condition_variable


 (Also, I think that once you have the threading primitives (thread,
 mutex, and condition_variable), you get future for free in the
 sense that it's written on top of the primitives, and you don't need any
 further os-specific support.)

Right.

 It's harder to support condition_variable because Windows didn't
 provide condition variables until Vista, and even then they interact
 with a CRITICAL_SECTION and gthr-win32.h defines mutexes in terms of a
 semaphore not a critical section.

 Even leaving condition variables aside, I really don't think you want to
 implement mutexes in terms of windows semaphores (or windows mutexes)
 (unless your primary goal is to support older (pre-xp?) versions of windows.)

Too late. That's how they're implemented when GCC is built with
--enable-threads=win32

 I believe (speaking from memory) that I built a trial implementation of 
 thread
 using  windows mutexes and that it was much slower than using windows
 critical sections.  I think both creation and locking were slower, but I don't
 remember the details.  This is reasonable, because windows mutexes (and
 semaphores) are heavier-weight objects -- they provide cross-process
 synchronization, not just intra-process, cross-thread synchronization.

 And, as you mentioned, if you want to support condition variables (in terms
 of windows condition variables), you need to base your mutexes on windows
 critical sections.

 Douglas Schmidt describes an
 implementation of condition variables at
 http://www.cs.wustl.edu/~schmidt/win32-cv-1.html but that also
 requires mutexes to be critical sections - maybe that could be adapted
 to use the gthr-win32.h semaphore-based definition of
 __gthread_mutex_t, I haven't looked into it in detail.   My suggestion
 would be to support thread and mutex but not condition_variable
 (or future because our implementation uses a
 std::condition_variable.)

 My personal feeling is that a version of thread that is complete
 (i.e., supports condition variables and futures), but requires windows
 vista or later is a fine way to go.

 Certainly given an either-or choice of an incomplete thread that
 works pre-vista, or a complete thread that requires vista or later,
 I would certainly vote for the complete thread and forgo pre-vista
 support.

 I have some untested implementations of
 __gthread_create, __gthread_join etc. if anyone wants to work on
 implementing that suggestion.  I don't have a Windows machine or
 enough free time to do that myself in the near future.

 As a second idea, supporting the full C++11 thread library could be
 done by creating a new thread model to be used instead of win32, which
 would only be supported on Vista or later and would use Windows
 critical sections for std::mutex and Windows  condition variables for
 std::condition_variable.

 I've done this, and it seems to work fine.  I would recommend it.

 (I'm not sure what you mean by a new thread model to be used instead
 of win32.

I mean instead of GCC's win32 thread model that you get by building
with --enable-thread=win32

That existing thread model uses semaphores.

My first suggestion is to improve that one in limited ways, retaining
backwards compatibility but adding thread and mutex which AFAIK
don't currently work.

My second suggestion is to write a replacement (call it
--enable-threads=win64 for the sake of argument) which would use
critical sections and support thread, mutex, ondition_variable
and future.

The suggestions are independent of each other.



 The way I look at it I used win32, i.e., I implemented thread
 on top of the vista-and-later version of win32.)

 Critical sections don't support a timed
 wait, so that thread model would be similar to the Mac OS X support
 and omit timed mutexes

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 9 May 2012 16:58, K. Frank wrote:
 Hello Jonathan!

 I've taken the liberty of cross-posting this to the mingw list
 (a separate project from mingw-w64), as they are the other
 big windows-focused downstream consumer of gcc.

 On Wed, May 9, 2012 at 9:29 AM, Jonathan Wakely jwakely@gmail.com wrote:
 On 7 May 2012 18:28, K. Frank wrote:
 Hello Gabriel (and Ruben)!

 By the way, I'm the guy Ruben mentioned in his subsequent post.

 On Sat, May 5, 2012 at 11:20 PM, Gabriel Dos Reis
 g...@integrable-solutions.net wrote:
 Including the mingw64 project about this.

 On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely jwakely@gmail.com 
 wrote:
 For GCC 4.7 I enabled most of thread (without timed mutexes) on Mac
 OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained.  I
 think we could quite easily do the same again for the win32 thread
 model (defined in gthr-win32.h) so that thread and mutex are
 available (including timed mutexes), but without condition_variable
 and future.

 Just my opinion:  One could make the macro more fine-grained, but I
 really wouldn't want to do this.  If I'm using thread I'm using c++11,
 so I like to think I'm in the modern world.  I think (in the modern world)
 that condition variables are a core part of threading, so I'd find is a
 significant limitation if my c++11 implementation didn't have them.

 Well currently you get none of the thread support when GCC is built
 with --enable-threads=win32.  IMHO that's an even more significant
 limitation than no condition_variable

 Ah, okay.  I don't use  --enable-threads=win32 or really know what
 it is.  With what I think is the thoughtful and powerful threading
 support in c++11, my main focus has been to write standard,
 portable threading code using thread, hence my motivation
 to get thread working on mingw / mingw-w64.

 One note:  In my experimentation, I wrote some windows-api
 threading programs and built them without specifying
  --enable-threads=win32, and they all seemed to work.,  So I
 guess I don't understand what  --enable-threads=win32 is
 supposed to do.

You use it when GCC is *built* not when you invoke GCC. It sets the
value shown for Thread model when you run gcc -v



 ...
 It's harder to support condition_variable because Windows didn't
 provide condition variables until Vista, and even then they interact
 with a CRITICAL_SECTION and gthr-win32.h defines mutexes in terms of a
 semaphore not a critical section.

 Even leaving condition variables aside, I really don't think you want to
 implement mutexes in terms of windows semaphores (or windows mutexes)
 (unless your primary goal is to support older (pre-xp?) versions of 
 windows.)

 Too late. That's how they're implemented when GCC is built with
 --enable-threads=win32

 Again, I'm not all that big on backward compatibility, and, as noted
 above, I don't understand what  --enable-threads=win32 is for.  But
 my gut reaction is if that the gcc implementation (with
  --enable-threads=win32) is sub-optimal, maybe it makes sense to
 do it right, even at the cost of backward compatibility.

That's not an option.  If there is to be a non-backwards-compatible
implementation then it must be a new thread model,
e.g.--enable-threads=win64 (yes, that name is wrong, it's just an
example.)

 ...
 ...
 My first suggestion is to improve that one in limited ways, retaining
 backwards compatibility but adding thread and mutex which AFAIK
 don't currently work.

 Yeah, okay.  I would see value in making incremental improvements
 to something that's already in use.

 My second suggestion is to write a replacement (call it
 --enable-threads=win64 for the sake of argument) which would use
 critical sections and support thread, mutex, ondition_variable
 and future.

 Just to be clear:  Why would mingw-w64's winpthreads-based thread
 implementation not fit the bill for the replacement you suggest?

Maybe Ruben can confirm but I assume that can be used when GCC is
built with --enable-threads=posix

That's no use for people who use a GCC built with --enable-threads=win32

 The suggestions are independent of each other.

 Yes, I understand that now.

 The way I look at it I used win32, i.e., I implemented thread
 on top of the vista-and-later version of win32.)

 Critical sections don't support a timed
 wait, so that thread model would be similar to the Mac OS X support
 and omit timed mutexes.

 I had to write some extra code to get timed mutexes to work.  I used
 windows critical sections (just as for untimed mutexes), but spawned
 a helper thread that blocked on the critical section, and had the original
 thread use a timed windows WaitForSingleObject to wait (with a
 timeout) for the helper thread.

 Spawning a new thread to block on a mutex seems over the top, but if
 it works it works.

 This approach didn't seem ideal to me, either.

 However, given my two self-imposed constraints:

   use windows critical sections for timed mutexes (for performance

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 9 May 2012 17:28, Earnie Boyd wrote:
 On Wed, May 9, 2012 at 11:58 AM, K. Frank kfrank2...@gmail.com wrote:
 Again, I'm not all that big on backward compatibility, and, as noted
 above, I don't understand what  --enable-threads=win32 is for.  But
 my gut reaction is if that the gcc implementation (with
  --enable-threads=win32) is sub-optimal, maybe it makes sense to
 do it right, even at the cost of backward compatibility.

 If you enable something new how does it affect backward compatibility?
  Perhaps with-in the coding itself, in that case the coding would need
 some method to know when it was different.  If it is a run time or
 library compatibility issue my suggestion to all users using a new
 version of a compiler is to always rebuild the library with that
 compiler.  It rarely gets done but it is the users detriment if they
 do not and then have issues; i.e. not a problem I worry about.

GCC already uses mutexes on Windows when using the win32 thread
model, for its internal locking, but it doesn't provide std::mutex
yet.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely]

On 9 May 2012 20:06, K. Frank wrote:
 However, as noted in my previous post, I have happily done some
 (limited) windows-api threading programming with Ruben's build
 (and also did the windows-api threading programming necessary
 to implement thread),

If you use GCC built with --enable-threads=posix then you shouldn't
need to implement thread, it should be provided.

In any case, as you're not using the win32 thread model you shouldn't
are about my proposals and you're just derailing the topic ;-)


 all, I guess, with a gcc build built using
 --enable-threads=posix, so what then does --enable-threads=win32
 actually do?

The code is all open source, feel free to read it.

--enable-threads=win32 tells GCC to use the gthr-win32.h header to
implement the gthreads abstraction API.  Gthreads provides a
pthreads-like API which libstdc++ (and libobjc and other bits of GCC)
use for threading facilities.  WIth --enable-threads=posix GCC uses
the gthr-posix.h file which provides an implementation of gthreads
based on pthreads (which is a one-to-one mapping.) With
--enable-threads=win32 GCC uses the gthr-win32.h file which provides
an implementation based on Windows primitives, which as I said several
days ago means that the __gthread_mutex_t type is implemented as
semaphores.

libstdc++ uses the __gthread_mutex_t type internally when it needs a
mutex, and when gthr-posix.h is used also uses __gthread_mutex_t to
implement std::mutex.

My original email, which I now seem to be repeating over and over,
suggests changes to gthr-win32.h to allow std::mutex and C++11 other
types to be defined in terms of the Windows primitives currently used
in gthr-win32.h

That gthr-win32.h header already exists, and already defines
__gthread_mutex_t in terms of a semaphore, and it's too late to change
that.  So maybe if you re-read my original mail now it will make more
sense.  I proposed extending gthr-win32.h to allow std::thread and
std::mutex to be provided WITHOUT CHANGING THE EXISTING IMPLEMENTATION
OF gthr-win32.h, which would not allow native condition variables to
be used because std::mutex is based on a semaphore and changing
gthr-win32.h to not use a semaphore would not be backwards compatible
and so is not an option.

In order to solve that problem I proposed a completely new gthreads
implementation, for argument's sake gthr-win64.h, which being
completely new could implement std::mutex differently, e.g. as a
critical section, and std::condition_variable as a Windows condition
variable,

As you are using gthr-posix.h you shouldn't need to care, you should
already have std::mutex, std::thread, std::condition_variable etc.

So now I hope everyone's on the same page, but I don't actually think
this thread has anything new since my original email on this subject
four days ago  :-\

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

[Jonathan Wakely]

On 27 June 2011 20:50, Ruben Van Boxem wrote:
 (If it is liked here, I see no reason not to also propose it to LLVM's
 libc++).

Why? libc++ only supports Mac OS X, so adding Windows-only extensions
seems pointless.

How does the Rogue Wave / Apache stdcxx support whar_t filenames on Windows?

N.B. this change was proposed for standardisation and and rejected:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

[Jonathan Wakely]

On 26 June 2011 16:06, Ruben Van Boxem wrote:
 Hi,

 I have implemented a small patch that mirrors Microsoft's STL
 extension, where one can use wide strings as an argument to
 std::(w)fstream. This is very useful on Windows, where, without this
 extension, there is no way to open an fstream for a filename
 containing non-ASCII characters not in the Windows local codepage. The
 workaround would be to subclass a streambuf to accept a wchar_t*
 filename, but I think a lower-level fix (ie on library level) is much
 more suitable, and provides more robustness. In the C API provided by
 Microsoft in their MSVCRT (catered for by MinGW(-w64)), a function
 _wfopen, which imitates plain fopen, but accepts wchar_t* arguments
 for the exact purpose I use it in my patch. Documentation for _wfopen
 is here:
 http://msdn.microsoft.com/en-us/library/yeby3zcb%28v=VS.100%29.aspx

 No extra #includes are necessary, and for now I #ifdef'ed the extra
 code with #if _WIN32. Perhaps cleaner would be a configure check for
 OS or CRT used and a __GLIBCXX* macro to enable this functionality.

I think that would be better.

 I understand the patch is not complete (no Changelog, etc...), but I
 would like to know your thoughts on how I implemented this
 functionality. The changes:
  - libstdc++-v3/config/io/basic_file_stdio.cc: wfopen_mode: new
 function, copy of fopen_mode, but returns wchar_t*
  - libstdc++-v3/config/io/basic_file_stdio.cc:
 __basic_filechar::open: new overload, taking wchar_t* argument, and
 uses new wfopen_mode and Windows' _wfopen instead of plain fopen.
  - libstdc++-v3/config/io/basic_file_stdio.h: open: new overload
 taking wchar_t* argument
  - libstdc++-v3/include/bits/fstream.tcc: open: new overloads, taking
 wchar_t* argument
  - libstdc++-v3/include/std/fstream: open: new overloads taking
 wchar_t* and if C++0x is enabled, also overloads taking a std::wstring
  - libstdc++-v3/config/abi/pre/gnu.ver: modify regex statements to
 also include new symbols.

You cannot add the new symbols to the old versions, they must be
versioned using a new version, not an old one that has already been
released. You can't change the symbols exported by a released library
version.

 Simple testing of the functionality works as it should. I first
 modified GCC trunk, created a patch, and applied that to the 4.6
 branch. Conclusion: this change should work for GCC 4.6 and up for
 sure, maybe even 4.5. As it stands, only Windows is affected, and
 should be affected. Perhaps systems where Unicode filenames aren't
 UTF-8 (oh wait: that's pretty much Windows only) could also benefit
 from this.

As a new feature I think this would only be suitable for trunk (i.e. 4.7)

There are some formatting issues with whitespace (missing blank lines,
#ifdef _WIN32 should not be indented with the code) but generally I
think the patch is a good idea.  I don't know enough about the Windows
API to feel confident approving the change though.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Windows/MinGW extension: opening std::fstream with a wstring/wchar_t*

[Jonathan Wakely]

On 26 June 2011 16:26, Jonathan Wakely wrote:
 On 26 June 2011 16:06, Ruben Van Boxem wrote:

 No extra #includes are necessary, and for now I #ifdef'ed the extra
 code with #if _WIN32. Perhaps cleaner would be a configure check for
 OS or CRT used and a __GLIBCXX* macro to enable this functionality.

 I think that would be better.

N.B. it should be _GLIBCXX with a single underscore, not two.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public