If an application provides a malloc replacement through
hb_malloc_impl() it is important that it is used to allocate
everything, but the use of strdup() circumvents this and
causes system malloc() to be called instead. This pairs
badly with the custom hb_free_impl() being called later.
API changes:
- If NDEBUG is defined, define HB_NDEBUG
- Disable costlier sanity checks if HB_NDEBUG is defined.
In 1.2.3 introduced some code to disable costly sanity checks if
NDEBUG is defined. NDEBUG, however, disables all assert()s as
well. With HB_NDEBUG, one can disable costlier checks but keep
assert()s.
I'll probably add a way to define HB_NDEBUG automatically in
release tarballs. But for now, production systems that do NOT
define NDEBUG, are encouraged to define HB_NDEBUG for our build.
- use '-w' instead of '\<...\>' for check-header-guards
grep manpage says these are the same
- put '-q' first in the grep options
- move VAR into hb-private.hh
- hb-font-private.hh - use [VAR] instead of [] for variable array
Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio,
which defines the bitwise operators for the enumerations that we want to
mark as hb_mark_as_flags_t, which will take care of the situation on newer
Visual Studio (>= 2012), where the build breaks with C2057 errors as the
underlying types of the enumerations is not clear to the compiler when we
do a bitwise op within the declaration of the enumerations themselves.
Also disable the C4200 (nonstandard extension used : zero-sized array in
struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false'
(performance warning)) warnings as the C4200 is the intended scenario and
C4800 is harmless but is so far an unavoidable side effect of using
DEFINE_ENUM_FLAG_OPERATORS.
This code is C++ only. There isn't a single C++ compiler that fails to
understand the "inline" keyword, since it's required by C++98. Any
compiler older than C++98 is likely to choke on the template usage
further down, so this isn't necessary.
Moreover, the C++ standard says you cannot define macros.
[lib.macro.names] says "Nor shall such a translation unit define macros
for names lexically identical to keywords." -- technically, it's a
promise that the Standard Library headers won't do it, the wording means
that the entire translation unit won't do it, which implies no source
can do it.
MSVC complains about it:
fatal error C1189: #error : The C++ Standard Library forbids macroizing
keywords. Enable warning C4005 to find the forbidden macro.
Author: Thiago Macieira <thiago.macieira@intel.com>
Ebrahim Byagowi
Sebastian Rasmussen
Behdad Esfahbod
Steve Lhomme
Konstantin Ritt
Steven R. Loomis
Chun-wei Fan
ThePhD