<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Eric,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2/18/22 16:51, Eric Pouech wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c6a0050d-805e-af58-2164-8751083ae81d@orange.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Le 18/02/2022 à 14:53, Jacek Caban a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:99019a74-9cef-6f9f-534e-c665d04dbdd1@codeweavers.com">Signed-off-by:
Jacek Caban <a class="moz-txt-link-rfc2396E"
href="mailto:jacek@codeweavers.com" moz-do-not-send="true"><jacek@codeweavers.com></a>
<br>
--- <br>
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. <br>
<br>
dlls/bcrypt/gnutls.c | 4 ++-- <br>
tools/makedep.c | 6 +++++- <br>
2 files changed, 7 insertions(+), 3 deletions(-) <br>
<br>
</blockquote>
<p><font face="Helvetica, Arial, sans-serif">Hi Jacek</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">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</font></p>
<p><font face="Helvetica, Arial, sans-serif">and crossing fingers
for not having too many traces in unixlib side<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">and in last resort,
just #define WINE_NO_LONG_TYPES in .c files that requires it
(ie too many casts)<br>
</font></p>
<p>that what I tried to apply on the ntdll migration proposal, and
I didn't get any feedback from Alexandre on it...<br>
</p>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c6a0050d-805e-af58-2164-8751083ae81d@orange.fr">
<p> </p>
- the NO_LONG_TYPES is not a temporary artifact for the migration
(but I'm not sure someone even believed it) </blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c6a0050d-805e-af58-2164-8751083ae81d@orange.fr">
<p>- 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)</p>
<p><br>
</p>
<p>minor: tools exec should be also supported (winedump comes to
mind) if we keep that proposal</p>
<p><br>
</p>
<p>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</p>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jacek<br>
</p>
</body>
</html>