SimonKagstrom

kcov

C++2017–2021

SimonKagstrom / kcov

kcov

Code coverage tool for compiled programs, Python and Bash which uses debugging information to collect and report data without special compilation options

Explore on GitHub Read Hacker News discussions

4Distinct people

4Mentions

0Explicit recommenders

840GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Code coverage tool for compiled programs, Python and Bash which uses debugging information to collect and report data without special compilation options

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2017-12-04 15:42:22 UTC to 2021-09-12 06:58:34 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

tiehuis·Sep 12, 2021

This is a nice write-up. Since zig has quite extensive compile-time functionality, one drawback is it is often easy to miss untested branches, especially for non-native targets if they are not regularly tested. It would be quite beneficial to be able to combine coverage reports from different targets to get a full picture of the tested code. I have previously used kcov [1] to perform coverage testing which due to zig having good DWARF debugging information worked with no fanfare. However, I'm not too familiar with the shortcomings of this method vs. the more fully instrumented binary approach provided. [1] https://github.com/SimonKagstrom/kcov

In Code Coverage for Zig with Callgrind

JoshMcguigan·Aug 20, 2019

Hey HN, author here. Inspired by this great strange loop talk by Alan Shreve [0], which discusses a non-standard use for code coverage reports, I wrote a blog post about using kcov [1] and pycobertura [2] as a tool to help start understanding a new-to-you codebase. As a specific example, I take the use case of understanding how keypresses are handled within Alacritty [3], a terminal emulator written in Rust. [0]: https://www.youtube.com/watch?v=dSqLt8BgbRQ [1]: https://github.com/SimonKagstrom/kcov [2]: https://github.com/aconrad/pycobertura [3]: https://github.com/jwilm/alacritty

In Coverage Reports as a Code Reading Tool

susam·May 15, 2018

> POSIX shell, on the other hand, is everywhere. Indeed! The significance of this, I believe, is underappreciated. During 2008-2015, when I used to work for a network security company, we had a file transfer script[1] for Unix and Linux systems. It was written entirely as a shell script. It began as a simple wrapper around the scp and sftp commands for which a shell script was appropriate. The fact that every Unix and Linux system comes with a shell meant that we could ship a single file to all target Unix and Linux systems without requiring the administrator to install any new packages. The alternative was writing the file transfer functionality in C or C++ which would have required us to build and test the solution for every possible Unix system that our customers used or writing it in Java which would have required us to require the cu

Read the rest

stomer to install JVM on their systems. Many customer admins were averse to installing any additional packages on their systems. Given these constraints, a shell script was a good solution. Unfortunately, the initial shell script relied on several bashisms.[2] Some customers began complaining that their Solaris or AIX system did not have bash, and they needed the script to work with Bourne shell or Korn shell. The customers refused to install bash. So I decided to clean up the script, remove all bashisms from it, and ensure that only POSIX specified features were used, only POSIX specified commands were invoked with POSIX specified options only (with the exception of the scp and sftp commands of course because that was the primary reason why the customers wanted the script). I am not fond of bashisms. If I need bashims like arrays or regex substitutions in parameter expansions, it's a sign that the script is becoming complex and I switch to a modern programming language. These days, when I write a shell script[3], I restrict myself to POSIX.2001 (2004 edition)[4], write unit tests to exercise every line of code, run the unit tests with bash, ksh, zsh, dash, posh, and yash on Debian, run the tests with bash, ksh, and zsh on macOS, and use Kcov[5] to measure test coverage. [1]: https://community.rsa.com/docs/DOC-53124 [2]: https://mywiki.wooledge.org/Bashism [3]: https://github.com/susam/vimer [4]: http://pubs.opengroup.org/onlinepubs/009695399/ [5]: https://github.com/SimonKagstrom/kcov

In Shell Style Guide

fireflash38·Dec 4, 2017

https://github.com/SimonKagstrom/kcov Also uses LD_PRELOAD.

In Using LD_PRELOAD to cheat, inject features and investigate programs (2013)