This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 1/18/2012 17:02, Kai Tietz wrote: > Hi, > > my 5 cents for this thread. > > 2012/1/17 JonY <jon_y@users.sourceforge.net>: >> On 1/18/2012 04:26, Corinna Vinschen wrote: >>> On Jan 17 14:56, Christopher Faylor wrote: >>>> On Tue, Jan 17, 2012 at 06:22:42PM +0100, Corinna Vinschen wrote: >>>>> Hi Jon, >>>>> >>>>> On Jun 27 11:08, JonY wrote: >>>>>> Yes, using only the win32api headers is possible, see the --disable-crt >>>>>> option in the mingw-w64-headers configure. The headers are very much >>>>>> LLP64 though. >>>>>> >>>>>> Though mingw-w64-crt doesn't have this facility yet, it is possible to >>>>>> use only dlltool to build the stub w32api equivalent link libraries for >>>>>> win64 linking, but without mingw bits like libmingwex. >>>>>> [...] >>>>>> The hairy parts would be the LP64/LLP64 ABI difference. For now we need >>>>>> to decide which ABI to go with, the rest of the work will rest on this >>>>>> decision. >>>>> >>>>> Here's a question to warm up this age-old thread. >>>>> >>>>> Consider we would like to have Cygwin-64 being LP64, and consider we >>>>> would like to use the mingw64 headers and libs to build Cygwin. >>>>> >>>>> In that case, all mingw64 headers have a problem in conjunction with >>>>> a Cygwin 64 bit compiler: All definitions in the headers which are >>>>> based on 'long' or 'unsigned long' are wrong. All of them would have >>>>> to use 'int' or 'unsigned int' instead. >>>>> >>>>> So, here's my question: Would it be acceptable upstream to add changes >>>>> along the lines of this one, for instance, in winnt.h: >>>>> >>>>> #if defined (__CYGWIN__) && defined (__x86_64__) >>>>> typedef int LONG; >>>>> #else >>>>> typedef long LONG; >>>>> #endif >>>>> >>>>> ? >>>> >>>> I think it's very wrong to put understanding of __CYGWIN__ into w32api. >>>> >>>> I'm saying this without checking to see if it's already there because, >>>> if it is, that's not a justification, it's a bug. >>> >>> Windows headers in their current state as in Mingw32 and Mingw64 only >>> work for 32-bit compiler or LLP64 64-bit compilers. How do you manage >>> it so that they still work in conjunction with an LP64 compiler as the >>> 64-bit Cygwin compiler is supposed to be? >>> >>> There are three ways AFAICS, but all of them require to change the >>> header files: >>> >>> - As above. >>> >>> - Start every header with a redefinition of "long": >>> >>> #if defined (__CYGWIN__) && defined (__x86_64__) >>> # define long int >>> #endif >>> [...] >>> #if defined (__CYGWIN__) && defined (__x86_64__) >>> # undef long >>> #endif > > To use here __CYGWIN__ as marker in platform-headers seems to me > wrong. But compiler defines for LP64 IIRC already __LP64__ makro (or > if it doesn't we could teach it to do so along with __LLP64__). > Redefining long has some disadvantages here too. It might make it > impossible to use 'long long' as type, and causes issues to describe > types like 'long double'. Well, the latter shouldn't happen very > often, if there at all any 'long double' types in platform-headers. > Maybe in midl stuff. > >>> - Add a new target-independent pragma to GCC and add this to the headers: >>> >>> #pragma long_size (push, 4) >>> [...] >>> #pragma long_size (pop) >>> >>> or >>> >>> #pragma model64 (push, LLP64) // value one of LLP64, LP64, ILP64, SILP64 >>> [...] >>> #pragma model64 (pop) >>> >>> I would prefer the latter. > > Well, pragma approach looks more sane to me, but is of course for user > of platform-headers always challenging, as (s)he has to take care that > signature gets proper types on usage. But normally - IIUC - usage of > platform-headers by end-users is discuraged anyway. > > About the pragma approach I see some interesting (and sadly not that > easy to abstract) issue about type-sanity. > > Eg. > > long foo (long *p) > { > #pragma long_size (push, 4) > *p = 0; > #pragma long_size(pop) > return *p; > } > > Regards, > Kai > Make it settable via GCC command line option only? -mlong-abi=4? At least the whole translation unit has the same "long".
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |