bcal: A REPL Calculator for Storage Expressions and Byte Arithmetic

What bcal Solves and Who Needs It

Storage calculations are awkward in a general-purpose calculator. Converting 2 GiB to bytes, or evaluating an expression like "(2GiB * 2) / (2KiB >> 2)", requires knowing both the binary prefix values and the correct shift precedence. bcal addresses that directly. It is a REPL and single-execution CLI utility that understands storage units natively, treating them as first-class operands rather than constants you must look up.

The README describes bcal as useful for people who deal with bits, bytes, addresses, and binary prefixes frequently. That puts it squarely in the path of storage engineers, embedded systems developers, operating system developers, and anyone building or debugging disk partitioning, filesystem layout, or memory map calculations. It supports 64-bit operating systems only, so it is not an option on 32-bit targets.

Expression Evaluation, Units, and Base Conversion

The core operation in bcal is evaluating arithmetic expressions that mix storage units. Operators supported in storage expressions are addition, subtraction, multiplication, division, and modulo. Bitwise operators AND, OR, XOR, complement, left shift, and right shift are available. Mathematical functions include exp, log, ln, pow, root, and sum.

Unit conversions cover the full IEC and SI prefix sets: B, KiB, MiB, GiB, TiB on the binary side, and kB, MB, GB, TB on the decimal side. Unit names are case-insensitive. When a result is a non-integer number of bytes, bcal returns the floor value because fractional bytes cannot be addressed.

Base conversion handles binary, decimal, and hex. Hex inputs use the 0x prefix; binary inputs use 0b. The README notes that numeric precision reaches 128 bits when __uint128_t is available on the platform, or falls back to 64 bits. Floating-point operations use long double.

A separate mode, activated with -b or the prompt key b, provides general-purpose arithmetic outside the storage unit domain. This is where the functions exp, log, and pow are most useful.

Installing bcal from a Package Manager or Source

bcal is available in many Linux distribution package managers. The README recommends checking the Repology packaging status page to confirm the version in your distribution is not dated.

To build from source, clone the repository and run:

sudo make strip install

This installs to /usr/local by default. The PREFIX variable is supported to change the install destination. To link against BSD Editline instead of GNU Readline:

sudo make O_EL=1 strip install

To build without any readline dependency, using a native input prompt with history file support instead:

sudo make O_NORL=1 strip install

For Termux on Android (aarch64):

pkg install make clang readline-dev
make strip install

For a fully static binary, use the static target, which forces O_NORL=1. The Makefile also supports musl-libc builds by setting CC=musl-gcc.

REPL Mode, CHS/LBA Addressing, and History

Running bcal with no arguments starts the REPL. The last valid result is stored in the variable r and can be reused in subsequent expressions. This makes multi-step calculations straightforward: compute an intermediate value, then reference r in the next expression.

LBA and CHS disk addressing is a less common but concrete use case. The format follows a specific hyphen-separated syntax. An LBA argument starts with l (case-insensitive), a CHS argument starts with c. Default values are sector size 512 (0x200), max heads per cylinder 16 (0x10), and max sectors per track 63 (0x3f). These defaults match the traditional PC BIOS geometry and can be overridden with -s, -m, and -H flags respectively.

The history file is stored at $XDG_CONFIG_HOME/bcal/history, or $HOME/.config/bcal/history when XDG_CONFIG_HOME is not set. This applies to the readline and native prompt modes alike.

The -c flag shows an integer in binary, displaying each bit's position and value, which is useful when debugging bitmask operations or register layouts.

Limitations and Cases Where bcal Is the Wrong Tool

bcal does not support bit as a unit. If your calculation requires sub-byte granularity, the tool will not express it. The -p flag addresses bit position display, but operands must still be in bytes or larger units.

Only 64-bit operating systems are supported. This is a hard constraint in the codebase, not a soft recommendation.

Storage expressions do not accept negative values. A subtraction that would produce a negative intermediate result is undefined behavior in bcal's storage expression engine.

The tool has no concept of filesystem overhead, partition alignment padding, or reserved sectors beyond the CHS/LBA primitives. Engineers doing capacity planning that involves filesystem-level waste (journal size, superblock copies, alignment gaps) will need to account for those factors outside bcal.

For general scientific or financial calculations, a tool like Python or GNU bc is more appropriate. bcal's general-purpose mode (-b) handles arithmetic, but it does not provide symbolic algebra, complex numbers, or unit dimensions beyond storage.

bcal Compared to GNU bc and Python

GNU bc is the traditional arbitrary-precision calculator on Unix systems. It handles general arithmetic with configurable precision and supports user-defined functions. However, bc has no built-in knowledge of storage prefixes. You would need to define KiB, MiB, GiB yourself, and there is no LBA/CHS support at all.

Python's interactive interpreter is a common alternative for one-off calculations. It handles storage unit arithmetic well when you define the constants, and third-party libraries add more. The trade-off is startup time and the need to write out full Python expressions rather than compact storage notation like "2GiB".

bcal's distinguishing design is that storage units are part of the language, not constants you bolt on. An expression like "(512MiB * 4) / 2KiB" is valid input directly. This specificity is exactly what makes bcal the right choice for its target domain and a poor substitute for anything outside it.

Maintenance, Build Configuration, and License

bcal is written in C and licensed under GPL-3.0. The GPL-3.0 license means you can use, modify, and distribute bcal freely, but any derivative work you distribute must also be released under GPL-3.0. For tools used only internally, this restriction does not apply.

The build system is a straightforward Makefile with no autoconf or CMake dependency. The optional build flags O_EL, O_NORL, and O_STATIC give meaningful control over the readline dependency. Removing readline with O_NORL=1 is useful for sandboxed or minimal environments where the library is not available.

The repository released v2.6 on 2026-09-05, and the last push to master was on 2026-09-17. The CHANGELOG file tracks version history. The test suite runs via Python's pytest: make test invokes python3 -m pytest test.py, so Python 3 is a build-time testing dependency even though it is not needed at runtime.

Editorial conclusion

bcal fits engineers and system programmers who regularly calculate storage capacities, convert between binary prefixes, or work with disk sector addressing. Anyone who finds themselves reaching for a general calculator and then manually converting MiB to bytes will find a direct replacement here. bcal does not support fractional bytes, does not run on 32-bit operating systems, and does not provide a graphical interface. The project released v2.6 on 2026-09-05 and the last push was on 2026-09-17, confirming active development. Before adopting it, verify that your distribution packages a current version; if not, build from source with make strip install.

Frequently asked questions

Official sources

1. Issues
2. jarun/bcal on GitHub
3. License: GPL-3.0
4. README
5. Releases