feat(patch): At least fix ifdefs for additional platforms (#251)

fix(patch): Tighten the scope between wallclock and cpu total (#249)

fix: support github markdown table style (#247)

fix(patch): Fix build on old Linux versions (#244)

Fix build on Linux pre 5.13 kernels.

feat(minor): Add logical writes as syscalls for macOS, add instructio…

…n count for m… (#243)

Adding new instruction counter for macOS (rusage) as well as Linux (using perf events)
Added logical writes for macOS to represent the sys call write counter.

fix(patch): memory unsafe file read on Linux (#234)

## Description

When reading from the file descriptor into the temporary buffer, it was
only by happenstance that the buffer would contain a terminating nul
byte.

The buffer is uninitialized and thus may contain any data.

And the `/proc` files that are read into the buffer are **not** nul
terminated.

If the temporary buffer happened to be zero-initialized, then this would
accidentally work correctly.

If the temporary buffer happened to have a nul byte somewhere after the
read data and in-bounds, then the end of the resulting String would be
corrupted with arbitrary crud. This crud would ostensibly be after a
terminating newline and thus parsers might have ignored it?

If the temporary buffer happened to not have any nul bytes after the
read data, then other Bad Things could happen, including silent success
or a crash due to segmentation fault or various checks in String being
violated.

The repair is to append a nul byte after the read data (ensuring that
the nul byte is not placed after the end of the buffer).

What motivated me to go look for this issue is that I have a benchmark
suite in a non-public project that crashes due to this issue. That
benchmark suite runs lots of iterations and somehow seems to have a
memory access pattern that regularly leads to the conditions where the
ill-effects of this bug can manifest.

## How Has This Been Tested?

Regarding testing, I did some one-off testing that pre-filled the
temporary buffer with non-zero bytes and then observed those bytes were
erroneously present in the resulting `String`.

I have not attempted to craft a unit test that triggers this bug. That
would require either directly or indirectly manipulating the system
allocator to affect the initial state of this temporary buffer. Too much
effort, IMO.

## Minimal checklist:

- [x] I have performed a self-review of my own code 
- [x] I have added `DocC` code-level documentation for any public
interfaces exported by the package
- [ ] I have added unit and/or integration tests that prove my fix is
effective or that my feature works

---------

Signed-off-by: Peter Grayson <[email protected]>
Co-authored-by: Joakim Hassila <[email protected]>

fix(patch): Always surface plugin run errors to CI, fixes #230 (#231)

Always surface failed job return codes up to CI, fixes #230.

docs(patch): correct typo (#228)

docs(patch): Add example on how parameterization is done (#225)

Added a sample for how to run parametrised benchmarks

feat(minor): Support thresholds for absolute checks (#223)

For benchmarks that are not completely stable (in e.g. syscall/malloc count) due to use of e.g. async or networking, it is desirable to also be able to specify some leeway for benchmarks even for the absolute checks from thresholds.

Co-authored-by: dimlio <[email protected]>