<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED --- - replace tools/solar.h macros with osl versions"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63154#c55">Comment # 55</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED --- - replace tools/solar.h macros with osl versions"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63154">bug 63154</a>
from <span class="vcard"><a class="email" href="mailto:sbergman@redhat.com" title="Stephan Bergmann <sbergman@redhat.com>"> <span class="fn">Stephan Bergmann</span></a>
</span></b>
<pre>I just notice that this clean-up involves changing occurrences of sal_uLong to
sal_uIntPtr, and I doubt that is a good idea.
The sal_uLong typedef was originally introduced to do a mass removal of
tools/solar.h's ULONG (which clashed with a Windows typedef of the same name),
without having to inspect all uses of ULONG and decide for an appropriate
replacement type in each case---those inspections could be deferred for a later
time by preserving the information about ULONG occurrences via the newly
introduced sal_uLong (which happens to be a typedef to sal_uIntPtr because that
happens to have the exact same underlying type as ULONG did).
So, occurrences of sal_uLong should not be blindly changed to sal_uIntPtr.
(Semantically, that often does not make sense, anyway.) They should either be
left alone or inspected to determine what other type they should actually be
changed to (likely sal_uInt32, as the comment in tools/solar.h states).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>