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

[Jacek Caban]

Hi Eric,

On 2/18/22 16:51, Eric Pouech wrote:
> Le 18/02/2022 à 14:53, Jacek Caban a écrit :
>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>> ---
>> I don't know if there are other plans for unix libs, but it seems to 
>> me that WINE_NO_LONG_TYPES fits them well.
>>
>>  dlls/bcrypt/gnutls.c | 4 ++--
>>  tools/makedep.c      | 6 +++++-
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
> 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.


> - the NO_LONG_TYPES is not a temporary artifact for the migration (but 
> I'm not sure someone even believed it) 


It would need to stay even if we applied it only for selected few files. 
And it seems worth keeping as an option for winelib anyway.


> - 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.


Thanks,

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