Character classification
Stephan Bergmann
sbergman at redhat.com
Thu Mar 23 11:47:43 UTC 2017
C character classification and case mapping functions in <ctype.h> are
notoriously hard to use.
For one, they take arguments of type int, but (quoting the C Standard):
"In all cases the argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value of the macro
EOF. If the argument has any other value, the behavior is undefined."
So passing in an argument of type plain char is generally undefined
behavior (when char is signed and the value is negative). (It appears
that glibc (un-)helpfully tries to mitigate that, by making the
functions work "as intended" for negative char values, but that hides
portability issues and can break down, depending on locale, for '\xFF'
if EOF is -1 (which it generally is). The MSVC debug runtime, on the
other hand, triggers asserts on invalid input to these functions.)
For another, those functions are locale dependent. For one, they change
behavior depending on preceding calls to setlocale. For another, even
in a process that never called setlocale, while most of the functions
(isalnum, isalpha, isblank, isdigit, islower, isspace, isupper,
isxdigit, tolower, toupper) have uniquely defined behavior, some
(iscntrl, isgraph, isprint, ispunct) still depend on what exactly
constitutes a printing character or a control character, something left
open by the C Standard.
(POSIX and MSVC have an additional isascii, but which accepts arbitrary
int values and returns true iff the value is in the 0..127 7-bit ASCII
range, so using it is "harmless" (modulo portability issues beyond POSIX
and MSVC). POSIX has additional is*_l variants that take an additional
locale_t argument, and MSVC has similar _is*_l variants. There appear
to be no uses of such across the LO code base.)
I audited all uses of such functions (outside of external/ source blobs)
on recent master:
In C++ code, I replaced them with calls to corresponding
rtl/character.hxx functions (and adding missing casts from char to
unsigned char where necessary; also see
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=7778d9f51bd1f4d086cafe95995406c3157afb89>
"Prevent calls to rtl/character.hxx functions with (signed) char
arguments"). A function corresponding to isspace was missing and has
been added with
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=f5c93d4149e7ae967e98dbce72528a04a204ca95>
"Use rtl::isAscii* instead of ctype.h is* (and fix passing plain char)
and add rtl::isAsciiWhiteSpace". Any calls thus replaced appeared to
either never pass in EOF or have been adapted accordingly
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a3f2cb747b2553485f48dc440e141e30ade5a70>
"Fix some usage of std::istream unformatted input in
hwpfilter/source/hwpeq.cxx"). (And there had been no uses of the
corresponding std-namespaced functions from <cctype>.)
What remains is the source of the five C programs
rsc/Executable_rsc.mk (rsc/source/rscpp/cpp{2,3,5,6}.c)
shell/Executable_uri_encode.mk (shell/source/unix/misc/uri-encode.c)
solenv/Executable_concat-deps.mk (solenv/bin/concat-deps.c)
soltools/Executable_cpp.mk (soltools/cpp/_{tokens,unix}.c)
soltools/Executable_mkdepend.mk
(soltools/mkdepend/{cppsetup,ifparser,parse}.c)
For one, I have added any casts from char to unsigned char where
missing. (But note that in some cases the input already was of the
expected form.)
For another, with a recent set of commits to master I have removed all
but one call to setlocale from the LO code base itself. (The remaining
one is in SetSystemLocale in vcl/unx/generic/app/i18n_im.cxx, and smells
like it is necessary for proper IME support in VCL-based applications on
Linux. None of those five C programs should be affected by it.) So
barring any calls to setlocale in external code, and ignoring the
somewhat fuzzy definition of isprint as called from
rsc/source/rscpp/cpp{5,6}.c, those five C programs should not (any
longer) be affected by locale issues.
Note that there are three remaining calls to toupper/tolower that are
currently being addressed by <https://gerrit.libreoffice.org/#/c/35303/>
"tdf#99589 change tolower/toupper to easytolower/upper."
Please avoid adding any new uses of any of those functions.
More information about the LibreOffice
mailing list