Release 3.0.2

This is a production release that adds utf8 locale symlinks and removes an unused auto variable from the ceil() function in the extended math library.

Users do NOT need to update unless they want the locales.

$ sha512sum bc-3.0.2.tar.xz
2b9eb7cd9f3c589c35b4d271c97afd32bac3d8c7e845a3639571dfb26a48d0eb1649035ef0f7c63de5a7d65d31c61b2ac3cf584225237c53aeb9ce3828b8093d  bc-3.0.2.tar.xz

$ sha256sum bc-3.0.2.tar.xz
44975f59d979aefdf3f4735ac1072ef6920342b69003d8942752eb249a9a0e33  bc-3.0.2.tar.xz

$ stat -c '%s  %n'
199484  bc-3.0.2.tar.xz

$ sha512sum bc-3.0.2.tar.xz.sig
d78828e6cedf1a93b4a18d6e816732b8cf0bd41078baa5923406a908fb7a3f44a21539499c05630e42f0f2b2ae76d5c036b9ba0dfdf4efea515e7099d8a7dc2a  bc-3.0.2.tar.xz.sig

$ sha256sum bc-3.0.2.tar.xz.sig
0c504782fcb14b6b6e8705cafd8b375f66dd89aca01f5cd8d17f76872db138b9  bc-3.0.2.tar.xz.sig

$ stat -c '%s  %n'
662  bc-3.0.2.tar.xz.sig

Release 3.0.1

This is a production release with two small changes. Users do NOT need to upgrade to this release; however, if they haven't upgraded to 3.0.0 yet, it may be worthwhile to upgrade to this release instead.

The first change is fixing a compiler warning on FreeBSD with strict warnings on.

The second change is to make the new implementation of ceil() in lib2.bc much more efficient.

$ sha512sum bc-3.0.1.tar.xz
553d14b3439e6f7d5ec370db3a7104808e263692fdae795d5f97fca3bb40d371e75bbab615d81975c87da9c84fbbb39bc148cf12a122b0e0e3c9036abb9b7cd8  bc-3.0.1.tar.xz

$ sha256sum bc-3.0.1.tar.xz
a06a7791030e98b69004ba0f02d7dc625c444ccf0882c04c454e397aeb481283  bc-3.0.1.tar.xz

$ stat -c '%s  %n'
199732  bc-3.0.1.tar.xz

$ sha512sum bc-3.0.1.tar.xz.sig
9f840c5c756a09e24ed8aac3e17639dabf965badc8784fe6495d9a6f2b4b2a03d51ced1b98ae266285fba54124619ea734f9c5d6c52bc33dccef27cb7ffb2f7d  bc-3.0.1.tar.xz.sig

$ sha256sum bc-3.0.1.tar.xz.sig
6851e863f1fe70fa1b41fe29c03aad019b6b454073c6b9e75e99cbb4f8244ba6  bc-3.0.1.tar.xz.sig

$ stat -c '%s  %n'
662  bc-3.0.1.tar.xz.sig

Release 3.0.0

Notes for package maintainers:

First, the 2.7.0 release series saw a change in the option parsing. This made me change one error message and add a few others. The error message that was changed removed one format specifier. This means that printf() will seqfault on old locale files. Unfortunately, bc cannot use any locale files except the global ones that are already installed, so it will use the previous ones while running tests during install. If bc segfaults while running arg tests when updating, it is because the global locale files have not been replaced. Make sure to either prevent the test suite from running on update or remove the old locale files before updating. Once this is done, bc should install without problems.

Second, the option to build without signal support has been removed. See below for the reasons why.

This is a production release with some small bug fixes, a few improvements, three major bug fixes, and a complete redesign of bc's error and signal handling. Users and package maintainers should update to this version as soon as possible.

The first major bug fix was in how bc executed files. Previously, a whole file was parsed before it was executed, but if a function is defined after code, especially if the function definition was actually a redefinition, and the code before the definition referred to the previous function, this bc would replace the function before executing any code. The fix was to make sure that all code that existed before a function definition was executed.

The second major bug fix was in bc's lib2.bc. The ceil() function had a bug where a 0 in the decimal place after the truncation position, caused it to output the wrong numbers if there was any non-zero digit after.

The third major bug is that when passing parameters to functions, if an expression included an array (not an array element) as a parameter, it was accepted, when it should have been rejected. It is now correctly rejected.

Beyond that, this bc got several improvements that both sped it up, improved the handling of signals, and improved the error handling.

First, the requirements for bc were pushed back to POSIX 2008. bc uses one function, strdup(), which is not in POSIX 2001, and it is in the X/Open System Interfaces group 2001. It is, however, in POSIX 2008, and since POSIX 2008 is old enough to be supported anywhere that I care, that should be the requirement.

Second, the BcVm global variable was put into bss. This actually slightly reduces the size of the executable from a massive code shrink, and it will stop bc from allocating a large set of memory when bc starts.

Third, the default Karatsuba length was updated from 64 to 32 after making the optimization changes below, since 32 is going to be better than 64 after the changes.

Fourth, Spanish translations were added.

Fifth, the interpreter received a speedup to make performance on non-math-heavy scripts more competitive with GNU bc. While improvements did, in fact, get it much closer (see the [benchmarks][19]), it isn't quite there.

There were several things done to speed up the interpreter:

First, several small inefficiencies were removed. These inefficiencies included calling the function bc_vec_pop(v) twice instead of calling bc_vec_npop(v, 2). They also included an extra function call for checking the size of the stack and checking the size of the stack more than once on several operations.

Second, since the current bc function is the one that stores constants and strings, the program caches pointers to the current function's vectors of constants and strings to prevent needing to grab the current function in order to grab a constant or a string.

Third, bc tries to reuse BcNum's (the internal representation of arbitary-precision numbers). If a BcNum has the default capacity of BC_NUM_DEF_SIZE (32 on 64-bit and 16 on 32-bit) when it is freed, it is added to a list of available BcNum's. And then, when a BcNum is allocated with a capacity of BC_NUM_DEF_SIZE and any BcNum's exist on the list of reusable ones, one of those ones is grabbed instead.

In order to support these changes, the BC_NUM_DEF_SIZE was changed. It used to be 16 bytes on all systems, but it was changed to more closely align with the minimum allocation size on Linux, which is either 32 bytes (64-bit musl), 24 bytes (64-bit glibc), 16 bytes (32-bit musl), or 12 bytes (32-bit glibc). Since these are the minimum allocation sizes, these are the sizes that would be allocated anyway, making it worth it to just use the whole space, so the value of BC_NUM_DEF_SIZE on 64-bit systems was changed to 32 bytes.

On top of that, at least on 64-bit, BC_NUM_DEF_SIZE supports numbers with either 72 integer digits or 45 integer digits and 27 fractional digits. This should be more than enough for most cases since bc's default scale values are 0 or 20, meaning that, by default, it has at most 20 fractional digits. And 45 integer digits are a lot; it's enough to calculate the amount of mass in the Milky Way galaxy in kilograms. Also, 72 digits is enough to calculate the diameter of the universe in Planck lengths.

(For 32-bit, these numbers are either 32 integer digits or 12 integer digits and 20 fractional digits. These are also quite big, and going much bigger on a 32-bit system seems a little pointless since 12 digits in just under a trillion and 20 fractional digits is still enough for about any use since 10^-20 light years is just under a millimeter.)

All of this together means that for ordinary uses, and even uses in scientific work, the default number size will be all that is needed, which means that nearly all, if not all, numbers will be reused, relieving pressure on the system allocator.

I did several experiments to find the changes that had the most impact, especially with regard to reusing BcNum's. One was putting BcNum's into buckets according to their capacity in powers of 2 up to 512. That performed worse than bc did in 2.7.2. Another was putting any BcNum on the reuse list that had a capacity of BC_NUM_DEF_SIZE * 2 and reusing them for BcNum's that requested BC_NUM_DEF_SIZE. This did reduce the amount of time spent, but it also spent a lot of time in the system allocator for an unknown reason. (When using strace, a bunch more brk calls showed up.) Just reusing BcNum's that had exactly BC_NUM_DEF_SIZE capacity spent the smallest amount of time in both user and system time. This makes sense, especially with the changes to make BC_NUM_DEF_SIZE bigger on 64-bit systems, since the vast majority of numbers will only ever use numbers with a size less than or equal to BC_NUM_DEF_SIZE.

Last of all, bc's signal handling underwent a complete redesign. (This is the reason that this version is 3.0.0 and not 2.8.0.) The change was to move from a polling approach to signal handling to an interrupt-based approach.

Previously, every single loop condition had a check for signals. I suspect that this could be expensive when in tight loops.

Now, the signal handler just uses longjmp() (actually siglongjmp()) to start an unwinding of the stack until it is stopped or the stack is unwound to main(), which just returns. If bc is currently executing code that cannot be safely interrupted (according to POSIX), then signals are "locked." The signal handler checks if the lock is taken, and if it is, it just sets the status to indicate that a signal arrived. Later, when the signal lock is released, the status is checked to see if a signal came in. If so, the stack unwinding starts.

This design eliminates polling in favor of maintaining a stack of jmp_buf's. This has its own performance implications, but it gives better interaction. And the cost of pushing and popping a jmp_buf in a function is paid at most twice. Most functions do not pay that price, and most of the rest only pay it once. (There are only some 3 functions in bc that push and pop a jmp_buf twice.)

As a side effect of this change, I had to eliminate the use of stdio.h in bc because stdio does not play nice with signals and longjmp(). I implemented custom I/O buffer code that takes a fraction of the size. This means that static builds will be smaller, but non-static builds will be bigger, though they will have less linking time.

This change is also good because my history implementation was already bypassing stdio for good reasons, and unifying the architecture was a win.

Another reason for this change is that my bc should always behave correctly in the presence of signals like SIGINT, SIGTERM, and SIGQUIT. With the addition of my own I/O buffering, I needed to also make sure that the buffers were correctly flushed even when such signals happened.

For this reason, I removed the option to build without signal support.

As a nice side effect of this change, the error handling code could be changed to take advantage of the stack unwinding that signals used. This means that signals and error handling use the same code paths, which means that the stack unwinding is well-tested. (Errors are tested heavily in the test suite.)

It also means that functions do not need to return a status code that every caller needs to check. This eliminated over 100 branches that simply checked return codes and then passed that return code up the stack if necessary. The code bloat savings from this is at least 1700 bytes on x86_64, before taking into account the extra code from removing stdio.h.

$ sha512sum bc-3.0.0.tar.xz
4961e030274e763aa02541457aa5aab6cd0d61758861b98d2cdac6acc42c3fb55b6adba72749edd3b663225ab844d7ef60809972478992165b071645fe6af65f  bc-3.0.0.tar.xz

$ sha256sum bc-3.0.0.tar.xz
4a7c5cbd5c7c2d3fea4a898c6ce87ff705756dd362cb2e3b241ae55e514e8280  bc-3.0.0.tar.xz

$ stat -c '%s  %n'
199...

Version 2.7.2

This is a production release with one major bug fix.

The length() built-in function can take either a number or an array. If it takes an array, it returns the length of the array. Arrays can be passed by reference. The bug is that the length() function would not properly dereference arrays that were references. This is a bug that affects all users.

ALL USERS SHOULD UPDATE bc.

$ sha512sum bc-2.7.2.tar.xz
c2014b16165bf5f8bdadf42bb60ea967a060753c17e13a7c3569d16d218bb3fb644e6a46950e9e7b3aa5a9f6bee4da9b158694909a0ab1fe390b7bb4dc20b303  bc-2.7.2.tar.xz

$ sha256sum bc-2.7.2.tar.xz
c017a6c0482cf7c4a2b31dae1f406028017a5e939d98dd6c78aa94ce3ecc8d38  bc-2.7.2.tar.xz

$ stat -c '%s  %n'
189020  bc-2.7.2.tar.xz

$ sha512sum bc-2.7.2.tar.xz.sig
076fc464dd6c3825707bf75b413357bfe3ebe340c4ff8350da36ef6b33fdbcba00ffbcb16991d853bd9179a72befc94105241e0384a7d463c5807f2fada5b975  bc-2.7.2.tar.xz.sig

$ sha256sum bc-2.7.2.tar.xz.sig
487152d9585a9d39b7bc845c7b7b50c93ad23e1ffd0169c2a58590c2d1f91105  bc-2.7.2.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.7.2.tar.xz.sig

Version 2.7.1

This is a production release with fixes for new locales and fixes for compiler warnings on FreeBSD.

$ sha512sum bc-2.7.1.tar.xz
f4900ccb7ca09b33e663136df12e6b02c1ca69e46f049107f359968921289e85bf3435be835f47b2ad6e4b0d33faefa8920d389e9648734f9daf7d1641389904  bc-2.7.1.tar.xz

$ sha256sum bc-2.7.1.tar.xz
6f1fd8900f0f5d98356730c11214a9adcf99a1d15b94b1991f33a4346533c624  bc-2.7.1.tar.xz

$ stat -c '%s  %n'
188584  bc-2.7.1.tar.xz

$ sha512sum bc-2.7.1.tar.xz.sig
925f308e9316392db01447ca4dceb6fbaaebe60374334a6721dbffa7b58521ecac4ebb8bed47a017627e36c786eaa59b24c894439c717e7155172d2e174d2a08  bc-2.7.1.tar.xz.sig

$ sha256sum bc-2.7.1.tar.xz.sig
fa8b23ab6d895a61a32c15c3feeb1364433c088fd9abcff3f69206ecac7952ef  bc-2.7.1.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.7.1.tar.xz.sig

Version 2.7.0

This is a production release with a bug fix for Linux, new translations, and new features.

Bug fixes:

• Option parsing in BC_ENV_ARGS was broken on Linux in 2.6.1 because glibc's getopt_long() is broken. To get around that, and to support long options on every platform, an adapted version of optparse was added. Now, bc does not even use getopt().
• Parsing BC_ENV_ARGS with quotes now works. It isn't the smartest, but it does the job if there are spaces in file names.

The following new languages are supported:

• Dutch
• Polish
• Russian
• Japanes
• Simplified Chinese

All of these translations were generated using DeepL, so improvements are welcome.

There is only one new feature: bc now has a built-in pseudo-random number generator (PRNG).

The PRNG is seeded, making it useful for applications where /dev/urandom does not work because output needs to be reproducible. However, it also uses /dev/urandom to seed itself by default, so it will start with a good seed by default.

It also outputs 32 bits on 32-bit platforms and 64 bits on 64-bit platforms, far better than the 15 bits of C's rand() and bash's $RANDOM.

In addition, the PRNG can take a bound, and when it gets a bound, it automatically adjusts to remove bias. It can also generate numbers of arbitrary size. (As of the time of release, the largest pseudo-random number generated by this bc was generated with a bound of 2^(2^20).)

IMPORTANT: read the bc manual and the dc manual to find out exactly what guarantees the PRNG provides. The underlying implementation is not guaranteed to stay the same, but the guarantees that it provides are guaranteed to stay the same regardless of the implementation.

On top of that, four functions were added to bc's extended math library to make using the PRNG easier:

• frand(p): Generates a number between [0,1) to p decimal places.
• ifrand(i, p): Generates an integer with bound i and adds it to frand(p).
• srand(x): Randomizes the sign of x. In other words, it flips the sign of x with probability 0.5.
• brand(): Returns a random boolean value (either 0 or 1).

$ sha512sum bc-2.7.0.tar.xz
a8ceff6455fa62e6656d1bbc7aab14db5839e980feb33c0e8f9e877b82fa73492bd51e7e460b19d04a68c8bcd45a81995f2df2bdbe45b4d411d346400592ed81  bc-2.7.0.tar.xz

$ sha256sum bc-2.7.0.tar.xz
192d0e3e51777f71e861a9d015c7c06b52f862cadf152ae2110bafbbb0d44093  bc-2.7.0.tar.xz

$ stat -c '%s  %n'
188752  bc-2.7.0.tar.xz

$ sha512sum bc-2.7.0.tar.xz.sig
3afc06f22ebd8d6f5f560b91f308951e06d4be0ccbf9e87f0da4ec8fe1d9567cbf79f9ebac930be6ebae730a89a2eb7541697f1fdbda22ab0289749f89b38660  bc-2.7.0.tar.xz.sig

$ sha256sum bc-2.7.0.tar.xz.sig
860b4d95c51e3f439359687998148da43b509b7865f116b4cb51336c4cd78f92  bc-2.7.0.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.7.0.tar.xz.sig

Version 2.6.1

This is a production release with a bug fix for FreeBSD.

The bug was that when bc was built without long options, it would give a fatal error on every run. This was caused by a mishandling of optind.

$ sha512sum bc-2.6.1.tar.xz
f9dbc384272a2f570fa3e8d1c3c9d7063349979e8245846a086ade4bfc3b22216e7115e95aeb13b9473939fd174aa50ea9237f7417477fd9f24477fb1f1933da  bc-2.6.1.tar.xz

$ sha256sum bc-2.6.1.tar.xz
a153c849dfddd17750be609973a8f6a134e0400b1dc704adb792d67fae090ccc  bc-2.6.1.tar.xz

$ stat -c '%s  %n'
165812  bc-2.6.1.tar.xz

$ sha512sum bc-2.6.1.tar.xz.sig
907f2e0a6925e0edc73e638c8b5266cb131a6cdd3d0f8bcf06f6eb9c39d511de00d43d6bc702d462aa6e30e1918db8adafb9b801af9255c0f845367c70416a8c  bc-2.6.1.tar.xz.sig

$ sha256sum bc-2.6.1.tar.xz.sig
4f26bd5a2e59fe2233a5a1e97b61b075a68a6eedcf086b9477de5b89e9a34094  bc-2.6.1.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.6.1.tar.xz.sig

Version 2.6.0

This release is a production release with no bugfixes. If you do not want to upgrade, you don't have to.

No source code changed; the only thing that changed was lib2.bc.

This release adds one function to the extended math library: p(x, y), which calculates x to the power of y, whether or not y is an integer. (The ^ operator can only accept integer powers.)

This release also includes a couple of small tweaks to the extended math library, mostly to fix returning numbers with too high of scale.

$ sha512sum bc-2.6.0.tar.xz
809ca124d110bb96ded253fe8799786b48dc5ff8ab540aa97dc8ed43f5a835841d44a71ed082ded17c1df39b6fe5dc2ce7247be0c771b22d7d354aec40434411  bc-2.6.0.tar.xz

$ sha256sum bc-2.6.0.tar.xz
2b9f08ee9db9ca8b1d3c159a5af5fed981fcd98899630add72d327083673eb80  bc-2.6.0.tar.xz

$ stat -c '%s  %n'
163300  bc-2.6.0.tar.xz

$ sha512sum bc-2.6.0.tar.xz.sig
36e6c204480bc154079ea1744f78f9bb8e90a914b73c2fa524bf0b2e9e1f7d584c08fc6cc42dd9c9f3b92c4931aa91f55b8b1197a50b2fcf13e07f4f6f4846e4  bc-2.6.0.tar.xz.sig

$ sha256sum bc-2.6.0.tar.xz.sig
c44d3ccb471dfea0347a46dcddf37fefe212bd9221731bcd04acdbc7671a85cd  bc-2.6.0.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.6.0.tar.xz.sig

Version 2.5.3

This release is a production release which addresses inconsistencies in the Portuguese locales. No bc code was changed.

The issues were that the ISO files used different naming, and also that the files that should have been symlinks were not. I did not catch that because GitHub rendered them the exact same way.

$ sha512sum bc-2.5.3.tar.xz
97c0722969c4f2fd907786e0a89f9b403662b1bcdd1aab59418ab3fe140c50584b45eb346008ad94916335418f08433d2634b52b94ae1d7463b665a746f1a608  bc-2.5.3.tar.xz

$ sha256sum bc-2.5.3.tar.xz
f7cec2a1bf6be2e805dfda6955b4631ec64d3397e96ce33f5a69909ba7aaf5c5  bc-2.5.3.tar.xz

$ stat -c '%s  %n'
162784  bc-2.5.3.tar.xz

$ sha512sum bc-2.5.3.tar.xz.sig
dbd8383eefdc8692cded29d296debd1eddc1e57cf33b2cbcff583a8ea756eaed5c6c9623a6dd85f9207a4142614f9f08b665c5cf374254ad20ba8e774053ae90  bc-2.5.3.tar.xz.sig

$ sha256sum bc-2.5.3.tar.xz.sig
112040a82ae5ba005aa1b15ffcba726e17ef540be5c1529a4345e374dbdf7ba5  bc-2.5.3.tar.xz.sig

$ stat -c '%s  %n'
662  bc-2.5.3.tar.xz.sig

Version 2.5.2

This release is a production release.

No code was changed, but the build system was changed to allow CFLAGS to be given to CC, like this:

CC="gcc -O3 -march=native" ./configure.sh

If this happens, the flags are automatically put into CFLAGS, and the compiler is set appropriately. In the example above this means that CC will be "gcc" and CFLAGS will be "-O3 -march=native".

This behavior was added to conform to GNU autotools practices.