summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix regression in sorted_amountsMartin Michlmayr2020-10-301-0/+17
| | | | | | | | | | Commit 557ab32 ("Expose a new utility function for balances: sorted_amounts") split out some code into a separate function. Unfortunately, in the process an "if" statement was dropped, leading to amounts being shown that shouldn't be shown because they are smaller than the display precision. Fixes #1969
* run demo.py test only when Python is enabledMartin Michlmayr2020-05-181-5/+7
| | | | | | | | Commit 92b6072ffd ("run demo.py with ctest") made demo.py part of the test suite. But we can only run it if Python is enabled in ledger. Fixes #1910
* Add regression test for issue #1895Martin Michlmayr2020-05-181-0/+31
| | | | Thanks to Feiko Nanninga for the test case.
* run demo.py with ctestAndy Clayton2020-05-181-0/+6
| | | | | Fix error from newer cmake/FindPython versions not printing internal Python_EXECUTABLE variable.
* Improve testcase for issue #1894 slightlyMartin Michlmayr2020-05-091-3/+8
|
* Add regression tests for issue #1894Rahix2020-05-092-0/+37
| | | | | | Add tests for wrong behavior caused by commit 49b07a1c1948 ("Correction to the way parens are parsed in query expressions") which was reverted with commit 869302ae9ce3. The bug report was issue #1894.
* Ensure that apply directives have an argumentMartin Michlmayr2020-04-271-0/+20
| | | | | | | | The directive `apply account` and similar directives (fixed, year...) require an argument. Ensure that an argument is given. Fixes #553 Fixes #1854
* fix: Fix #543 by tracking an account's real balanceDaraul2020-04-054-0/+104
| | | | | | | | | | | | | | Without these changes, whether an account's balance is virtual or real is not considered when asserting it's balance. This lead to situations where the user must consider their virtual postings when attemping to assert the real balance of the account. See test/regress/543_a.test for that testcase, taken from the original issue. This commit also includes other, fringe, situations that I noticed while working on the fix. It essentially just adds a separate attribute to the account class(?) that hold's the account's "real" balance, which is only updated when the user attempts an assertion on a real account. The virtual account's balance is updated the way it always was.
* Make explicit option a no-opCandyAngel2020-04-031-1/+1
| | | | Fixes #1877
* py3: ensure python output is not lostAndy Clayton2020-03-262-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unbuffer python's stdio to avoid output getting stuck in buffer when stdout is not a TTY. Normally buffers are flushed by `Py_Finalize` but Boost has a long-standing issue preventing the proper shutdown of the interpreter with `Py_Finalize` when embedded [1]. This applies the same fix as 139beba but to any ledger usage rather than only the test suite. I removed `PYTHONUNBUFFERED=1` from tests as there is no expectation that users should need to have this set for ledger to function. For example without this fix piping ledger into cat usually loses any output (unless the output is large enough to cause the buffer to flush): $ ./ledger -f "test/baseline/feat-value_py3.test" reg <class 'bool'> True [...] $ ./ledger -f "test/baseline/feat-value_py3.test" reg | cat $ Interestingly `--verify` causes `python_interpreter_t` to be destroyed -- it doesn't appear to be otherwise -- which does call `Py_Finalize`. As expected this fixes the issue but can also crash due to the boost issue mentioned above: $ ./ledger -f "test/baseline/feat-value_py3.test" --verify reg <class 'bool'> True [...] Segmentation fault (core dumped) $ ./ledger -f "test/baseline/feat-value_py3.test" --verify reg | cat <class 'bool'> True [...] $ 1. https://www.boost.org/doc/libs/1_62_0/libs/python/doc/html/tutorial/tutorial/embedding.html
* Revert expected test time value to correct valueAndy Clayton2020-03-251-1/+1
| | | | | | This was changed to be specific to the author's local TZ in 139beba. With the test TZ override fixed, revert this back to the value that is correct across all environments (including travis).
* fix setting TZ in testsAndy Clayton2020-03-252-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was regressed in 139beba which set `PYTHONUNBUFFERED` to fix other test issues. When setting multiple environment variables in this way they need to be delimited with semicolons rather than spaces. As it is `PYTHONUNBUFFERED` is being set to `1 TZ=America/Chicago`. The CMake docs are not as clear about this as they probably should be. This can be verified by throwing together a CTestTestfile.cmake: add_test(incorrect_env "printenv" "PYTHONUNBUFFERED" "TZ") set_tests_properties(incorrect_env PROPERTIES ENVIRONMENT "PYTHONUNBUFFERED=1 TZ=America/Chicago") add_test(correct_env "printenv" "PYTHONUNBUFFERED" "TZ") set_tests_properties(correct_env PROPERTIES ENVIRONMENT "PYTHONUNBUFFERED=1;TZ=America/Chicago") When run with `ctest -V`: 1: Test command: /usr/bin/printenv "PYTHONUNBUFFERED" "TZ" 1: Environment variables: 1: PYTHONUNBUFFERED=1 TZ=America/Chicago 1: Test timeout computed to be: 10000000 1: 1 TZ=America/Chicago 1/2 Test #1: incorrect_env ....................***Failed 0.00 sec test 2 Start 2: correct_env 2: Test command: /usr/bin/printenv "PYTHONUNBUFFERED" "TZ" 2: Environment variables: 2: PYTHONUNBUFFERED=1 2: TZ=America/Chicago 2: Test timeout computed to be: 10000000 2: 1 2: America/Chicago 2/2 Test #2: correct_env ...................... Passed 0.00 sec
* Add test for --average-lot-pricesMartin Michlmayr2019-12-252-1/+16
|
* test: split value_py.test into py2/py3 versions.Dimitri John Ledkov2019-12-073-0/+32
|
* test: No baseline tests for average-lot-pricesDimitri John Ledkov2019-12-071-0/+1
|
* test: Unbreak one more test case with python3 bridgeDimitri John Ledkov2019-12-063-5/+5
| | | | | | | | | | | python3 has buffered output by default, hence testcase option_py returned no output when executed under test harness. I think this is a real problem in the way python interpreter is embeded, and i.e. stdout is not flushed until after test case has died. However, running things unbuffered seems to make everything work. But for some reason I had to adjust 1057.test slightly. I have no idea what those numbers mean, and if running things unbuffered break stuff.
* Remove dependency on other testAlexis Hildebrandt2019-12-051-3/+3
|
* Make tests scripts Python 3 compatibleAlexis Hildebrandt2019-12-0515-81/+137
|
* Modernize CMake using backported FindPython module.Dimitri John Ledkov2019-12-052-9/+9
|
* Format annotations using format that can be parsedOleg Bulatov2019-11-274-5/+5
| | | | | | | | | | | | | | | | | I expect an output of `ledger print` to be consumable by ledger. But on the next journal ``` 2019/11/25 * test Foo 1 AAPL {1.00 EUR} [2019/11/24] Bar ``` it prints [19-Nov-24], which it does not understand with default options. With this patch it prints [2019/11/24].
* Remove know-ification of elements due to post stateCandyAngel2019-08-272-2/+14
|
* Add support for '%F' date format specifierMichael Budde2019-04-021-0/+20
| | | | | | | | | '%F' is equivalent to '%Y-%m-%d'. Using the '%F' format without this change this would not give any hard errors but instead give dates with wrong years because the 'has_year' trait would not be correctly detected and thus parsed dates would get set to the current year. Fixes #1775
* Fix tag value parsingMichael Budde2019-03-301-0/+17
| | | | | | | | | | | | If a tag is more than 2 characters from the beginning of the comment the tag value offset will be wrong. #1702 gives an example where the tag line starts with `;;` and the tag value thus becomes `: Bar` because of this bug. The use `index` in the offset calulation seems to be a lucky coincidence that works in the common case: "; tag: value" Fixes #1702
* Reject postings with comment after flagMichael Budde2019-03-301-0/+12
| | | | Fixes #1753
* Remove the 'org' command, which was always a hack to begin withJohn Wiegley2019-03-151-28/+0
|
* Corrections to opt-lots.testJohn Wiegley2019-03-151-1495/+1495
|
* Fix possible stack overflow in option parsing routineMartin Michlmayr2019-01-261-0/+7
| | | | | | | | | | | | | | | It is possible to create a stack overflow by giving an option that is longer than the buffer that is used during option parsing because the length of the input string is not checked. Prevent the issue by always checking the input string length and discarding options that does not fit in the buffer as invalid. This issue has been assigned CVE-2017-12481. Thanks to Gwan Yeong Kim for reporting this issue. Fixes #1222
* Fix possible stack overflow in date parsing routineMichael Budde2019-01-261-0/+9
| | | | | | | | | | | | | | | It is possible to create a stack overflow by giving a date that is longer than the buffer that is used during date parsing because the length of the input string is not checked. The `VERIFY` macro is only enabled when debug-mode is enabled and the `--verify-memory` argument is used. Prevent the issue by always checking the input string length and discarding dates that does not fit in the buffer as invalid. This issue has been assigned CVE-2017-12482. Fixes #1224
* Merge pull request #1743 from scfc/move-garbage-dat-to-test-using-itJohn Wiegley2019-01-252-30/+30
|\ | | | | Move garbage-input.dat to test case using it
| * Move garbage-input.dat to test case using itTim Landscheidt2019-01-222-30/+30
| |
* | Merge pull request #1744 from scfc/do-not-set-dependencies-for-target-checkJohn Wiegley2019-01-252-7/+0
|\ \ | | | | | | Do not set dependencies for target check
| * | Do not set dependencies for target checkTim Landscheidt2019-01-222-7/+0
| |/ | | | | | | | | | | The set_target_properties() commands themselves do not cause the tests to run if the target check is made, and as the target check executes ctest, all tests will be run anyway.
* / Ignore null deferred postingsMichael Budde2019-01-231-0/+5
|/ | | | | | | | | | | | | | | | | | All-null transactions (i.e. a transaction where all postings have a null amount) are discarded during parsing and the `xact` object is free'd. But if the transaction contains a deferred posting this results in a use-after-free vulnerability because a reference to the deferred posting is stored in the account object which is later read when deferred postings are applied after parsing is finished. Ignore null deferred postings to prevent this – they should not have any effect any way. Thanks to Cory Duplantis for reporting this issue and providing an initial analysis. Ref TALOS-2017-0304, CVE-2017-2808 Fixes #1723
* Fix parsing issue involving effective datesMartin Michlmayr2019-01-151-0/+12
| | | | | | | | | | | | | | | | | Cory Duplantis reported that "A specially crafted journal file can cause [an] integer underflow resulting in code execution". Cory provided this test case: Expenses:Food:Groceries $ 37.50 ; ] [=2004/01/01] Note the ] that comes before [ after the ;. This issue was reported and described in great detail by Cory Duplantis of Cisco Talos. This issue is known as TALOS-2017-0303 and has been assigned CVE-2017-2807. Cory's description can be found at https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0303 Fixes #1722
* Add test case for issue #1703Martin Michlmayr2019-01-121-0/+11
| | | | | Add a test case for issue #1703 which John Wiegley fixed in commit 56025cde ("Don't attempt to invert a value if it's already zero").
* Merge remote-tracking branch 'origin/master' into nextJohn Wiegley2018-07-191-0/+18
|\
| * Add parse error testManuel Amador (Rudd-O)2016-02-081-0/+18
| |
* | Add the test to make sure it works in the future.Pascal Fleury2018-07-181-0/+36
| |
* | Remove TOK_A_YEAR tokenChristoph Dittmann2018-06-103-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes #1626. The tokenizer eagerly classifies 4-digit integers as TOK_A_YEAR tokens. In some contexts such as "every 1000 years", this causes errors. I think the tokenizer does not have enough information available to distinguish between integers and years. After this patch, the tokenizer will always classify integers as TOK_INT tokens. The "has 4 digits" heuristic to determine if an integer is a year is moved to the place where it's actually needed (and it can be slightly more generic there, too).
* | Make automated transactions work with assertionsChristoph Dittmann2018-06-091-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes issue #1127. In my understanding, PR #552 was meant to fix this, but was incomplete. Without this patch, automated transactions are invisible to assertions. This patch fixes this by adding a flag to the account to tell it that there is a new posting, analogous to the behavior of finalize(). I dug up issue #1127 too late to find that this is the same solution proposed by @tbm. Although I wrote this independently, credit goes to Martin Michlmayr (@tbm).
* | budget_posts: Keep pending items until the last day they applysmr8942018-04-041-0/+79
| |
* | Merge pull request #519 from mbudde/accounts-prepend-formatJohn Wiegley2018-01-272-0/+10
|\ \ | | | | | | Add support for --prepend-format in accounts command
| * | Add support for --prepend-format in accounts commandMichael Budde2018-01-252-0/+10
| | | | | | | | | | | | | | | Add support for the `--prepend-format` and `--prepend-width` options in the `accounts` command.
* | | Merge pull request #521 from mbudde/fix-trimAlexis Hildebrandt2018-01-271-0/+33
|\ \ \ | | | | | | | | Fix handling of edge cases in trim function
| * | | Fix handling of edge cases in trim functionMichael Budde2018-01-251-0/+33
| |/ / | | | | | | | | | Fixes #520
* / / [misc] Update year in copyright notice to 2017Alexis Hildebrandt2018-01-271-1/+1
|/ / | | | | | | [ci skip]
* | Fix segfault when using --market with --group-byMichael Budde2018-01-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | `changed_value_posts::create_accounts()` reuses the `<Revalued>` account from `display_filter`, but when clearing `changed_value_posts` `create_accounts()` would be called before the account had been recreated by `display_filter_posts`. This results in a segfault when using the --group-by option. I'm not sure if `display_filter_posts` has the same problem but I reordered the calls there too for good measure.
* | Merge pull request #494 from jjlee/fix-totalJohn Wiegley2017-10-262-0/+58
|\ \ | | | | | | Fix bug where .total used in value exprs breaks totals
| * | Fix bug where .total used in value exprs breaks totalsJohn Lee2017-10-262-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Re-initialize (to VOID) totals for the account and its ancestors on adding postings. Otherwise the cache intended for use by recursive calls of C++ function total() in computing family (i.e. account hierarchy) totals is incorrectly retained from one top-level call to the next, causing inconsistent and broken behaviour. * Re-initialize (to false) calculated and gathered. Otherwise we won't e.g. recalculate stale totals for ancestor accounts (e.g. won't recalculate Assets:Savings total if Assets:Savings changes via a posting). Although the value expression total function is used by ledger itself in computing totals, this bug would only appear on use of .total in user-supplied value expressions computed *during parsing* of ledger files, rather than after parsing (I believe ledger only ever calls it for internal purposes after parsing is complete). It is possible this bug also affected other functions than total (perhaps even in circumstances other than analagous to that described in the preceding paragraph). I have not checked that.
* | | Merge pull request #484 from mk12/bug-1182-ptrJohn Wiegley2017-10-262-0/+29
|\ \ \ | |/ / |/| | Fix Bug 1182: Error message for parse failure after '='
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-04 07:32:32 +0000