[PATCH 1/2] makedep: Build Unix libraries with WINE_NO_LONG_TYPES.

[Eric Pouech]

Le 20/02/2022 à 12:35, Jacek Caban a écrit :


Hi Jacek

>>
>> I'd rather had the impression that Alexandre was more willing to not 
>> define WINE_NO_LONG_TYPES and push for not using windows long types 
>> in unixlib when possible
>>
>> and crossing fingers for not having too many traces in unixlib side
>>
>> and in last resort, just #define WINE_NO_LONG_TYPES in .c files that 
>> requires it (ie too many casts)
>>
>> that what I tried to apply on the ntdll migration proposal, and I 
>> didn't get any feedback from Alexandre on it...
>>
>
> I think that using WINE_NO_LONG_TYPES only for some files in a module 
> is not pretty. It would make it no longer easy to know which type 
> we're using when touching the code. It also may be confusing to things 
> like LTO.
>
agreed. I'm even thinking we should be homogenous across all unixlib
>
>
>> - from an architectural standpoint, it goes with the choice of being 
>> able to support transparently any windows type (vs saying the 
>> transformation must be done before the "syscall" to unix) ; 
>> wineserver is designed the other way (ie the caller must transform 
>> data into a windows indepedent format)
>>
>>
>> minor: tools exec should be also supported (winedump comes to mind) 
>> if we keep that proposal
>>
>>
>> so we need to shed some light on what should be the target for 
>> Unixlib, and your proposal could fit either as the target or as 
>> another intermediate step to ease another migration
>>
>
> I generally think that reasons for using ints for LONGs before PE 
> migration still apply to Unix libs. It's very convenient to have the 
> same builtin types for LONGs on 32-bit and 64-bit targets. We could 
> probably avoid this for Unix libs using __wine_unix_call, which have 
> more flexibility and could mostly avoid using LONGs on Unix side. But 
> I think that modules like ntdll or win32u which need to deal a lot 
> with Windows types will be better with WINE_NO_LONG_TYPES. My patch 
> uses it for all Unix libs, which was motivated by more consistency. It 
> seems to me like a good approach, but I'd be fine with other solution 
> as well.
>
No strong feeling either way. But we need a clear direction.

Let's wait for Alexandre view on this.

A+

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220220/754405bb/attachment.htm>