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]

Re: RFC: Cygwin 64 bit?


2012/1/19 Corinna Vinschen:
> On Jan 19 14:25, Kai Tietz wrote:
>> Hi,
>>
>> So I read me through the mail-archive to get an overview of discussion.
>>
>> 2012/1/19 JonY :
>> > On 1/19/2012 20:38, Corinna Vinschen wrote:
>> >> On Jan 19 12:21, Pedro Alves wrote:
>> >>> On 01/19/2012 12:19 PM, Pedro Alves wrote:
>> >>>>
>> >>>> 1. is probably acceptable by gcc upstream. ?Googling around,
>> >>>> I find precedent in other compilers for something like that.
>> >>>
>> >>> Obviously, I meant 4., the pragma.
>> >>
>> >> Understood. ?What I mean with "upstream" here is not gcc, though.
>> >>
>> >> Upstream is the Mingw64 project in the first place. ?Is it acceptable
>> >> for Mingw64 to adapt the Windows header files to a LP64 compiler? ?And
>> >> if so, which solution is preferred?
>> >>
>> >>
>> >> Corinna
>>
>> Well, as more I think about the #pragma-approach vs abstracting types
>> in platform-headers, I come to the conclusion that the latter might be
>> the more sane approach here.
>> By this switch, we might get in troubles for C++'s name mangling, for
>> debugging info in some corner-cases, and such constency issues as
>> shown in my first reply.
>> So IMHO the way to go would be to abstract types in platform-headers
>> for LP64/LLP64. ?Obviously our platform-headers are right now made for
>> LLP64 and ILP32, as those are the official existing ABIs for IA
>> Windows.
>> So it is doable, and mingw-w64 would be willing to support such a request.
>
> Oh, good! ?I assume you read all of the thread so far? ?If we come to
> a conclusion how to do it, I'd be willing to do the ground work.

Great.

> Did you see http://cygwin.com/ml/cygwin-developers/2012-01/msg00023.html?
> The extra header file is one possible approach I can think of.
>
> Another way to do it would be to drop all `long' and `int' types in
> favor of fixed-size types from stdint.h, int32_t and uint32_t.

The stdint.h approach I would prefer here, as it is the most portable
way IMHO.  Using defines can lead easily to issues, especially in
user-land.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]