RFC: Cygwin 64 bit?

[Andy Koppe]

On 19 January 2012 10:25, Corinna Vinschen wrote:
> On Jan 18 15:54, Corinna Vinschen wrote:
>> On Jan 18 14:23, Pedro Alves wrote:
>> > I was looking for a technical reason that's worse, other then the
>> > amount of mechanical work, which I'm sure could also be easily
>> > scripted, with the long/int hidden behind a #define,
>> > from the perspective of code that uses the headers.   It's obvious
>> > the pragma is less intrusive to the headers.
>>
>> I can't think of any.  In both cases you will get the type mismatches in
>> certain circumstances within the LP64 code of the application.
>>
>> Hmm.  The only other problem I could see with the #pragma approach is a
>> potential clash of debug information within the same CU.  If you use
>> Windows headers you would potentially have two entries for long in
>> .debug_info:
>>
>>  From the LLP64 code:
>>
>>    <1><d0>: Abbrev Number: 2 (DW_TAG_base_type)
>>       <d1>   DW_AT_byte_size   : 4
>>       <d2>   DW_AT_encoding    : 5        (signed)
>>       <d3>   DW_AT_name        : long int
>>
>>  From the LP64 code in the same CU:
>>
>>    <1><dc>: Abbrev Number: 2 (DW_TAG_base_type)
>>       <dd>   DW_AT_byte_size   : 8
>>       <de>   DW_AT_encoding    : 5        (signed)
>>       <df>   DW_AT_name        : long int
>
> That won't be the case, fortunately.  A collegue has created a POC patch
> which would result in only one entry for long, the "right" one with
> DW_AT_byte_size 8, while the LLP64 usage of long would be converted to
> the type int internally.

Great. Does that also avoid nonsensical error messages along the lines
of "Cannot assign 'long *' to 'long *'"?

Andy