Re: [Mingw-w64-public] [PATCH] sal.h: Fix redefinition of _Field_range_.

2015-10-29 Thread David Grayson
Yep, that looks like a good change to me. Sorry for not catching that earlier. --David On Thu, Oct 29, 2015 at 3:34 PM, Nakai Yuta wrote: > > Please review. > > > _Field_range_ is also defined at the next line of _Field_z_ definition. > > > -

[Mingw-w64-public] [PATCH] sal.h: Fix redefinition of _Field_range_.

2015-10-29 Thread Nakai Yuta
Please review. _Field_range_ is also defined at the next line of _Field_z_ definition. From fa3481bc350967a9d655a4392d67e3ebcb8d41a9 Mon Sep 17 00:00:00 2001 From: Yuta Nakai Date: Fri, 30 Oct 2015 07:20:22 +0900 Subject: [PATCH] sal.h: Fix redefinition of _Field_range_. --- mingw-w64-header

Re: [Mingw-w64-public] [patch] Replace struct timeval usage with PTIMEVAL and define TIMEVAL differently on LP64

2015-10-29 Thread David Grayson
The types "const struct timeval *" and "struct timeval * const" are not the same. The first type is a pointer to a timeval struct that the compiler should not try to modify, or at least it shouldn't modify that struct through this particular pointer. The second type is just a pointer to an ordina

Re: [Mingw-w64-public] libc++ on MinGW-w64

2015-10-29 Thread Martell Malone
> > You have a functional Clang/libc++ toolchain? That's awesome! Are all > patches upstreamed already and how can I make my own? > :) Hey ruben I know this is something you were looking for a long time. :) ATM I have 90% of the patches upstreamed. As alexey said I have created mingw-w64 packages

Re: [Mingw-w64-public] [patch] Replace struct timeval usage with PTIMEVAL and define TIMEVAL differently on LP64

2015-10-29 Thread Burkhardt, Glenn B UTAS
There was a patch made to _ip_types.h and winsock.h in 2012 that I wish had been made differently. All the function prototypes using timeval* were changed to use PTIMEVAL. I think it would have been better to change the typedef for 'timeval' for LP64 instead. I'm working with a library, which

Re: [Mingw-w64-public] libc++ on MinGW-w64

2015-10-29 Thread Alexpux
> 29 окт. 2015 г., в 12:51, Ruben Van Boxem > написал(а): > > 2015-10-29 3:54 GMT+01:00 Martell Malone >: > My second reason is clang. > I currently have a mingw-w64 toolchain with this stack. > clang + libc++ + compiler-rt + lld > this equates to > gcc + libstd

Re: [Mingw-w64-public] libc++ on MinGW-w64

2015-10-29 Thread Ruben Van Boxem
2015-10-29 3:54 GMT+01:00 Martell Malone : > My second reason is clang. > I currently have a mingw-w64 toolchain with this stack. > clang + libc++ + compiler-rt + lld > this equates to > gcc + libstdc++ + libgcc + binutils. > > If we want a standalone clang stack using lld we should not have to bu