As discussed in
https://lists.gnucash.org/pipermail/gnucash-devel/2014-July/037868.html
as an exception the direct access to the kvp is enabled again in
import-export/aqb/gnc-ab-kvp.c because the way aqbanking transfer templates
are stored cannot be mapped directly on the properties mechanism.
With this implementation, at least the read access to the templates
works again, which means the aqbanking transfers can be used again (they
crashed immediately up until now).
However, writing a changed template to the kvp seems to not work - the
changed values seem not to be saved. This would be a bug, but not as severe
as the previous one. The unittest verifies both reading and writing,
though, and there also writing works fine. Well, this can be worked
on later.
Avoids overflowing the amount and is anyway much more realistic:
Value = Amount * price, so a large "rate" means a small price. Since
get_random_rate() is biased to producing large rates (denom is fixed
at 100), it was effectively testing infinitesimal prices.
The note has the details, but I wasn't able to get gnucash to build with
automake 1.14 without passing --disable-dependency-tracking regardless of
whether I used the subdir-objects option. If I could figure out a good way
to poison configure with automake 1.14 I would.
This change applies some recommendations from jralls. It better utilizes for loops,
and usage of swap. We also try to make sure the null guid is not freed since it's
reused, and catch a c++ exception to make sure it doens't escape into C code when
parsing a GUID.
Previously, guid_to_string had been marked deprecated with a note about
it not being thread-safe. It was much worse than "not thread safe", it
was only safe in a particular situation, and its safety was being violated
throughout the code. It was clear that users of guid_to_string did not
understand what it was purporting to do because of its varied uses. Most
uses simply treated it like a Garbage-Collected Java String (use and forget).
I actually found at least one instance where the string was being freed. (!!!)
I made the method have a particular easy-to-understand semantic: it returns
a pointer to a string which must be freed by the caller. I then tried to
track down all uses of this function and correct them. Mostly, I just changed
the usage to guid_to_string_buff with a stack-allocated string to avoid the
the malloc/free cycle.
To allocate a GUID, use guid_malloc. To allocate and construct a guid
(which is actually unique), use guid_new (and be sure to free it using
guid_free).
`new` implies some allocation. Since guid_new was actually constructing
a guid in place rather than allocating it, it makes much more sense to
call it guid_replace (or guid_construct). We went with guid_replace.
