The collection_compare_cb function set the user_data pointer to point to a local variable
of the function. That pointer is then used in the (only) calling function
qof_collection_compare to make decisions. This is undefined. It is likely not an actual
problem because the stack depth of the qof_collection_foreach followed by
collection_compare_cb is deeper than the qof_collection_get_data call (and others
in between if any) that the stack data user data stays uncorrupted.
But, it is undefined behavior, and could cause really subtle bugs if these there are code
changes that have deeper stack between the setting and using.
Also, using this local variable is not necessary, the qof_collection_compare function
already sets up a variable local to its scope for this that the collection_compare_cb can
use directly.
This commit removes the local (to collection_compare_cb) variable and uses the one setup
in qof_collection_compare.
The full coverage test for qofid.cpp passed before and after this change.
NOTE: This does not have full coverage because the "if (!target || !ent)" body in the
collection_compare_cp function cannot be reached. There is too much safety in the rest of
the system to test this error.
NOTE: I made this a separate test from the test-engine so that I was able to check that it
by itself could test the full coverage of the qofid.cpp file. If it was part of the larger
test, I could have missed some parts that were covered incidentally elsewhere.
Boost::date_time has changed to throwing a std::out_of_range instead of a
boost::date_time::gregorian::bad_year when a date is outside of the
1400-9999 year range it can deal with.
We also recently discovered that it will use the system localtime function
when creating a new date which can lead to a 2038 failure. Use std::chrono
to resolve that problem.
instead of vice-versa.
- avoids malloc/free in gnc_gdate_set_today
- avoids unnecessary dmy->julian->dmy(*) conversion
(*) the GDate is typically used by gdate_to_time64 which performs a
julian->dmy conversion, and this is now avoided
To mitigate potential impact, the Imbalance split is only removed when the split transitions to zero value during the commit of the transaction and the split's memo and action have no value.
foreign-currency transaction into a trading account transaction.
Disable scrubbing while committing the new trading split, otherwise
the recursed scrub will delete it causing a crash when GnuCash tries
to populate it.