<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c57">Comment # 57</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 <a class="email" href="mailto:vicenzi.alexandre@gmail.com" title="Alexandre Vicenzi <vicenzi.alexandre@gmail.com>"> Alexandre Vicenzi</a> <pre>(In reply to <a href="show_bug.cgi?id=63154#c55">comment #55</a>) > 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). Stephan, I understand your point of view, and probably it's the best idea. It's wrong to put sal_uLong definition in sal/types.h?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>