Make counters explicitly integer type and adjust the kvp load and save functions
to recognize that and behave accordingly so that other range options like day
threshold aren't affected.
- Also, remove unnecessary "static" in gnucash-style.c
The second one in guid.cpp is UB:
libgnucash/engine/guid.cpp:137:5: warning: undefined behavior, source object type 'const gnc::GUID' is not TriviallyCopyable [bugprone-undefined-memory-manipulation]
memcpy (&target, &source, sizeof (GncGUID));
^
A TXN_TYPE_PAYMENT will have non-APAR splits; a TXN_TYPE_LINK will not
have non-APAR splits. This bug manifests as a regular TXN_TYPE_PAYMENT
transaction being later voided being incorrectly changed to
TXN_TYPE_LINK.
The scrubbing routines are transaction oriented. Instead of
xaccAccountTreeScrubImbalance calling xaccAccountScrubImbalance for
each descendant, refactor so that the transaction list is generated
only once. The scrubbing is faster and progress bar is more accurate.
Bug 798930 caused some counters to be saved as KVP double. If the
correct int64_t value isn't found when reading, or if a double is
encountered when loading the option dialog, get the double value
and cast it to int64_t.
It was failing to produce a correct representation for input with more than
14 digits after the decimal poin. Fixes Bug 798916. The bug was in
powten so this fix may corect other problems too. For example conversion
of GncNumeric back to a string also failed in certain circumsances.
==515314== Invalid read of size 1
==515314== at 0x484AD67: __strcmp_sse42 (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x171D36: do_test_list_handler (unittest-support.c:181)
==515314== by 0x171DCE: test_list_handler (unittest-support.c:197)
==515314== by 0x51BD4C1: g_logv (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51BD7A2: g_log (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4D5D0D9: xaccSplitEqualCheckBal (Split.c:753)
==515314== by 0x4D5D841: xaccSplitEqual (Split.c:869)
==515314== by 0x4D647A5: xaccTransEqual (Transaction.c:981)
==515314== by 0x15C0E8: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:901)
...
==515314== Address 0x8725260 is 0 bytes inside a block of size 59 free'd
==515314== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x15BDB1: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:883)
...
==515314== Block was alloc'd at
==515314== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x5618677: __vasprintf_internal (vasprintf.c:116)
==515314== by 0x520E8C1: g_vasprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51DBBE0: g_strdup_vprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51DBC9C: g_strdup_printf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x15BBAC: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:879)
...
ok 78 /engine/Transaction/xaccTransEqual
Thanks, Valgrind:
==515314== Invalid read of size 8
==515314== at 0x4ED46F3: gncInvoiceRemoveEntries (gncInvoice.c:767)
==515314== by 0x142B35: teardown_with_invoice (utest-Invoice.c:274)
...
==515314== Address 0x8557b98 is 8 bytes inside a block of size 24 free'd
==515314== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x51B565D: g_list_remove (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4ED42EF: gncInvoiceRemoveEntry (gncInvoice.c:688)
==515314== by 0x4ED46A2: gncInvoiceRemoveEntries (gncInvoice.c:781)
==515314== by 0x142B35: teardown_with_invoice (utest-Invoice.c:274)
...
==515314== Block was alloc'd at
==515314== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x51BD948: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51B1CB9: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4ED4271: gncInvoiceAddEntry (gncInvoice.c:676)
==515314== by 0x142401: setup_with_invoice (utest-Invoice.c:142)
...
ok 57 /engine/gncInvoice/post trans - vendor bill
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.
At least one user has managed to get it set on their book so even
though it was supposed to be unimplemented it got through somehow.
Restoring it allows books with it set to load.
- Renamed option to "Account Balance" to avoid confusion with running
total.
- Added helper function to ensure running balance and balance forward
are only shown when transaction are grouped by account and sorted as
in register. In that case column heading remains "Running Balance"
and balance forward is shown. Otherwwise column heading is renamed
"Account Balance" and balance forward is not shown.
- Also added missing code for Common Currency conversion.
