==66427== 128 bytes in 1 blocks are definitely lost in loss record 22 of 25
==66427== at 0x4843738: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==66427== by 0x49B85EF: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==66427== by 0x49D6EF1: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==66427== by 0x49D6F6F: g_string_sized_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==66427== by 0x499AB00: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==66427== by 0x499B2D8: g_build_filename (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==66427== by 0x10A498: main (test-userdata-dir-invalid-home.c:74)
==66427==
==91379== 19 bytes in 1 blocks are definitely lost in loss record 2 of 9
==91379== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==91379== by 0x48D1948: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==91379== by 0x48ED5B0: g_strconcat (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==91379== by 0x48B845F: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==91379== by 0x48B869E: g_dir_make_tmp (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==91379== by 0x10935E: main (test-resolve-file-path.c:71)
g_assert() can be compiled out, so should not be used for tests
g_assert_true was removed
to fis https://bugs.gnucash.org/show_bug.cgi?id=792008 because
g_assert_true was introduced in glib-2.38 and at the time GnuCash required
only glib-2.26. GnuCash has required glib >= 2.40 since 8acbc41c6 so
g_assert_true can be restored.
Pass a boost::filesystem's c_str() rv to the ofstream constructor to
keep libstdc++ from transcoding it back to UTF8 and creating a broken
name or failing to match the directory name. Implemented in
gnc-filepath-utils to avoid spreading the boost::filesystem dependency
throughout the code base.
See https://github.com/boostorg/filesystem/issues/181 for why other
approaches don't work.
If a function that returns an allocated pointer is passed directly into
something that does not take ownership of the pointer, the allocation is
leaked. This can be fixed by assigning the pointer to a new variable
and freeing it after operation on the memory.
The idea behind this is to not assume the project is always built
as "gnucash" exactly.
One example where it can be useful to use a different project name
would be when building multiple development versions of the project
on the same system and don't want these different versions share
the same settings in GSettings or the same stored passwords.
Root cause is using boost::locale::translate because it ignores
the LANGUAGES environment variable and doesn't support different
values for LC_MESSAGES, LC_DATE, LC_MONETARY, and LC_NUMERIC.
That makes it impossible to configure a user environment that
presents translated strings in a different locale from the one
applied to formatting dates and numbers.
To correct this replace all use of boost::locale::translate
with GNU gettext.
By embedding a minimal Info.plist with a bundle ID into the executable.
This necessitated a change to binreloc because the unix-style install
depended on there being a bundle ID only when the program was run from
an application bundle.
significantly
Modify the DEBUG and PINFO macros to return unless qof_log_check is
true. Replace almost all direct calls to g_debug and g_message with
DEBUG and PINFO respectively.
Track the highest logging level sent to qof_log_set_level to provide a
short-circuit return in qof_log_check. Remove setting GNC_MOD_TESTS to
QOF_LOG_DEBUG so that the short-circuit threshold isn't defeated by
always being DEBUG.
Net result: 33% improvement in xml load times.
When compiling with -Werror, GNUCash fails to build due to various error: missing sentinel in function call.
This patch resolves the issue by passing nullptr instead of C-style casting NULL.
This requires a std::locale generated from a boost::locale::generator
The examples already in our code base used the wrong message_path while
creating the generator and as a result our message catalogs weren't found.
As with the std::locale I have added code to create a locale via
boost::locale only once instead of having each c++ file redo the work.
This code expects a message_path to set for the boost generator.
An earlier attempt queried for this path directly from within
gnc-locale-utils using gnc_get_locale_dir (from gnc-path.h).
That however broke several c++ tests depending on gnc_locale_utils as those
then also needed to be linked against gnc-path.o. I couldn't get the linker
to do this properly so I worked around it for now by splitting the boost_locale
functionality in two steps:
- an initializer step that takes the messages_path as a string and will
generate the locale
- a getter to get the locale.
The initializer should only be run once, and before the getter is called.
It won't hurt though if the initializer is called more often.
If the getter is called before the initializer it will still
generate a std::locale but without setting a messages_path. It will then
also log a warning explaining translations may not be properly found.
Richard Cohen
Christopher Lam
John Ralls
Maarten Bosmans
Geert Janssens
luz paz
Frank H. Ellenberger
luz paz
Bill Nottingham
Gaming4JC
Mike Alexander