https://bugs.documentfoundation.org/show_bug.cgi?id=150537
Bug ID: 150537
Summary: Use standard C/C++ integer types where relevant
instead of sal_IntNN and sal_uIntNN
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: trivial
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
The C and C++ language standard have had specific-width types since C99 and
C++11 respectively :
https://en.cppreference.com/w/c/types/integer
https://en.cppreference.com/w/cpp/types/integer
and Boost has had specific-width integer types since before 2011:
boost::int_t<N>::exact
boost::uint_t<N>::exact
yet, for some reason, LO has custom code for defining specific-width type,
instead of just using the standard C types in C code, and the same, but after
an appropriate `using` declaration, in C++. So, some tinkering and deletions in
include/sal/types.h , then using int8_t, uint8_t, int16_t, uint16_t, and so on
(include size_t, the intptr_t types and
It looks like include/sal/types.h is a relic for pre-2011 C++, and even pre-C99
C, relying on things such as `__int64` and the like.
Benefits of doing this:
* Will make the LO code a little more idiomatic C++ rather than reinventing the
wheel in this respect. (Obviously there are many things which could be done to
avoid idiosyncrasies, that's just one of them).
* Will shorten the code slightly: `sal_Int32` is 9 chars, `int32_t` is 7 chars.
Detriments of doing this:
* Massive change, affects over 3,000 files
* To affect this change, the repository will probably need locking, as almost
any other change to C/C++ code will likely break this one
Bikeshedding:
If type name length is a factor, or if one wants to also do this for `sal_Bool`
which is trickier (no standard fixed-width boolean type in C++) - then the type
names, defined using `typedef X Y;` or `using Y = X;` statements, would be
`bool8`, `int8`, `uint8`, `int16`, `uint16` etc. - which would be more in line
with the suffixes of the current types. In this case, name lengthes are
shortened even more :-)
--
You are receiving this mail because:
You are the assignee for the bug.
