https://bugs.freedesktop.org/show_bug.cgi?id=63154
--- Comment #57 from Alexandre Vicenzi <vicenzi.alexandre@gmail.com> ---
(In reply to comment #55)
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?
--
You are receiving this mail because:
You are on the CC list for the bug.
Context
- [Bug 63154] replace tools/solar.h macros with osl versions · bugzilla-daemon
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.