The gnc_numeric is serialised as "num/denom" with no whitespace, and
denom > 0. This function takes advantage of std::from_chars to parse
it. The "num" serialisation is also optimised as a free side effect of
this function.
Covers the final case where having the reconcile window open and
auto-completing a transaction then deleting the transaction before
committing it leaves the transaction in the reconcile window.
We need to signal that the account is modified even if it isn't
because that's what the reconcile window is watching.
Calling xaccSplitDestroy without also calling xaccSplitCommitEdit then
deleting the split list before calling xaccTransCommitEdit prevents
xaccSplitCommitEdit from being called on the supposedly deleted
splits. Not only does this leak them it leaves them in the book
potentially with a dangling parent pointer.
The problem with take 1 was that the duplicate split uses the same lot
and account pointers without adding itself to those lists, causing
checks in unit tests to fail.
This reverts commit 4dbf803041.
The use-after free errors are caused by the compiler reordering the
steps in xaccSplitFree and Transaction's do_destroy. Unfortunately the
corrections here caused trouble in other places, leading to test failures.
- all quote sources are now vector
- get_quote_source_from_type to convert QuoteSourceType to vector<gnc_quote_source>
- the quote sources are modifiable, therefore cannot be const:
see gnc_quote_source_set_fq_installed
"Import CSV" wizard
In MSWin the UnicodeString(char*) ctor assumes that the input string
is encoded in the current codepage, but the input to
gnc_list_formatter is encoded in UTF8. Use the static class function
UnicodeString::fromUTF8 instead.
To use pass -DCMAKE_BUILD_TYPE=Debug or Asan -DCOVERAGE=ON and build as
usual, then do ninja lcov-initialize && ninja check && ninja
lcov-collect. The result will be a directory, <Builddir>/Coverage
containing lcov tracefiles, including an aggregate file gnucash.info
which you can use for further processing. It will also report an overall summary.
Note that only C/C++ files are included.
There's one more target, lcov-generate-html, that you can run after
lcov-collect. It will generate a simple website in
<Builddir>/Coverage-HTML showing coverage by source directory (the
directories in <Builddir> have coverage for generated files). Each
directory path is a clickable link to a page that shows coverage for
each source file; the filenames link to a page for each showing which
lines have been exercised.
strptime will reasonable return false for an incomplete date but it
still fills in the parts of the struct tm that it understands, so bail
out of qof_scan_date_internal when it fails only if all three fields
are present.
xaccSplitComputeCapGains creates gains_split pointers in both the Cap Gains Split and its Income split to the original split, but the original's gains_split pointer can point to only one of them, the Cap Gains split. When the original split is freed both the Cap Gains split's and its Income split need their gains_split pointers NULLed or when it's the Income split's turn to be freed it will try to deref the dangling pointer.
The intent was always to default to today if the input string isn't
parsable, but two problems prevented that: First,
qof_scan_date_internal didn't check the return value of strptime and
return FALSE if it failed and second gnc_date_edit_get_date_internal
would unnecessarily munge a valid struct tm from gnc_tm_get_today_neutral.
Caused by trying to set the account on the blank split. The blank split
was present because the method used to clear the split list for the
receiving transaction in gnc_float_txn_to_txn_swap_accounts only removed
splits that belong to the transaction, and the blank split doesn't.
Adds new function xaccTransClearSplits to do a more thorough job.
Also improve the documentation for xaccSplitDestroy to better explain when
a transaction will be destroyed if it empties the split list.
# Please enter the commit message for your
changes. Lines starting
- Balancing lots always involves splits in the same account. So
the relevant number to use in the calculations is the split
amount, not the split value.
- Additionally don't assume transactions are single-currency.
So if amounts change, recalculate the associated values
based on deduced exchange rates.
- Finally if the lot balancing resulted in a split to be broken up
into two splits use conservative calculations for the new
splits' values to avoid introducing imbalances due to
rounding errors.
The conditions being containing a split from a voided transaction.
Instead of trying to destroy zero-value splits (doomed to fail in
that instance and generally rude otherwise) just remove them from
the lot list.