I want to share everyutil-c, a C utility library aimed at filling in gaps beyond the C standard library, with performance, modularity, and cross-platform consistency as first-class requirements. Below are some of the technical design decisions, recent improvements, and open areas where I’d love feedback or contributions.
Everyutil-C is meant as a “standard library extension” for C projects — lightweight, dependency-minimal, and structured so you can pull in only what you need. Key subsystems include:
4. wrapping malloc/free with alignment options, optional debugging hooks, etc.
5. handling Windows vs POSIX differences, proper __declspec(dllexport) stuff, platform detection, conditional compilation.
Recent Technical Milestones
1. Improved performance of iteration (fewer bounds checks, perhaps more inlining).
2. clearer ownership semantics, avoidance of buffer overruns in growth/resizing.
3. cleaner internal structure, possibly splitting core and helper functions so that the minimal subset (e.g. fixed-size dynamic arrays) can be used without pulling in everything.
4. Support for Make, Autotools, and CMake so as to integrate with different build pipelines.
build.sh script to automate configuration, especially helpful on MSYS2/Windows, where toolchain quirks (path separators, runtime linking, DLL visibility, etc.) can be a headache.
Proper handling of DLL exports on Windows; ensuring symbols are exported appropriately, avoiding linker errors.
Testing & correctness
Full test suite covering edge cases (zero length, null pointers, huge sizes, overflow).
Cross-platform tests to verify behavior is consistent on Linux, macOS, Windows.
Automated CI likely (or recommended) to verify builds under different compilers (gcc, clang, MSVC or mingw).
Technical Trade-offs & Design Choices
Some of the tricky technical decisions/constraints and how I addressed (or plan to address) them:
Minimal dependencies vs feature richness. I avoid bringing in large external libraries; aim is to stay in “pure C99 (or close)” so users don’t have to link dozens of other libs.
Memory allocation strategies: resizing vs doubling, growth factors, freeing, fragmentation. Trying to keep it reasonable without over-engineering.
Symbol visibility & binary interfaces: ensuring that the API headers are stable, and that users who build shared libs / static libs get consistent behavior. Handling extern "C" for C++ usage, etc.
Portability quirks: Windows’ path handling, _snprintf vs snprintf, difference in size_t, alignment issues; ensuring macros / config headers detect and adapt.
What I’m seeking feedback on
Are there any missing utility subsystems people commonly need in C that would integrate well here (e.g. logging, formatting, serialization)?
How do people prefer safe vs unsafe APIs: do you want always safe, or ability to sacrifice safety for speed?
What patterns for versioning/stability are helpful: semantic versioning, API deprecation path, binary compatibility?
Experiences integrating similar libraries (stb, klib, GLib, etc.): what patterns or pitfalls do you want to avoid?
Suggestions around documentation / API specification style: inline comments, header docs, external reference, examples.
Regarding documentation, comments in tens of .h files in third level directories are very user unfriendly, regardless of their quality (which seems fairly good).
You need:
1) an overview of the available functionality, design choices, aspects that need feedback and contributions etc.
2) a guide of what headers every function or macro is located in (consider fragmenting headers less, possibly adding "umbrella" headers that just include a set of the current headers that is likely to be used together)
Hey HN,
I want to share everyutil-c, a C utility library aimed at filling in gaps beyond the C standard library, with performance, modularity, and cross-platform consistency as first-class requirements. Below are some of the technical design decisions, recent improvements, and open areas where I’d love feedback or contributions.
Everyutil-C is meant as a “standard library extension” for C projects — lightweight, dependency-minimal, and structured so you can pull in only what you need. Key subsystems include:
1. dynamic array abstractions, safer iteration, bounds checking, contiguous resizing, insertion/removal, possibly span/view-like APIs.
2.enhancements over strlen, strcpy/strncpy, concatenation, splitting, trimming, maybe UTF or ASCII “safe” operations.
3. parsing, formatting, safe arithmetic (overflow detection), maybe integer ↔ string conversions.
4. wrapping malloc/free with alignment options, optional debugging hooks, etc.
5. handling Windows vs POSIX differences, proper __declspec(dllexport) stuff, platform detection, conditional compilation.
Recent Technical Milestones
1. Improved performance of iteration (fewer bounds checks, perhaps more inlining).
2. clearer ownership semantics, avoidance of buffer overruns in growth/resizing.
3. cleaner internal structure, possibly splitting core and helper functions so that the minimal subset (e.g. fixed-size dynamic arrays) can be used without pulling in everything.
4. Support for Make, Autotools, and CMake so as to integrate with different build pipelines.
build.sh script to automate configuration, especially helpful on MSYS2/Windows, where toolchain quirks (path separators, runtime linking, DLL visibility, etc.) can be a headache.
Proper handling of DLL exports on Windows; ensuring symbols are exported appropriately, avoiding linker errors.
Testing & correctness
Full test suite covering edge cases (zero length, null pointers, huge sizes, overflow).
Cross-platform tests to verify behavior is consistent on Linux, macOS, Windows.
Automated CI likely (or recommended) to verify builds under different compilers (gcc, clang, MSVC or mingw).
Technical Trade-offs & Design Choices
Some of the tricky technical decisions/constraints and how I addressed (or plan to address) them:
Minimal dependencies vs feature richness. I avoid bringing in large external libraries; aim is to stay in “pure C99 (or close)” so users don’t have to link dozens of other libs.
Memory allocation strategies: resizing vs doubling, growth factors, freeing, fragmentation. Trying to keep it reasonable without over-engineering.
Symbol visibility & binary interfaces: ensuring that the API headers are stable, and that users who build shared libs / static libs get consistent behavior. Handling extern "C" for C++ usage, etc.
Portability quirks: Windows’ path handling, _snprintf vs snprintf, difference in size_t, alignment issues; ensuring macros / config headers detect and adapt.
What I’m seeking feedback on
Are there any missing utility subsystems people commonly need in C that would integrate well here (e.g. logging, formatting, serialization)?
How do people prefer safe vs unsafe APIs: do you want always safe, or ability to sacrifice safety for speed?
What patterns for versioning/stability are helpful: semantic versioning, API deprecation path, binary compatibility?
Experiences integrating similar libraries (stb, klib, GLib, etc.): what patterns or pitfalls do you want to avoid?
Suggestions around documentation / API specification style: inline comments, header docs, external reference, examples.
Repo: https://github.com/dailker/everyutil-c
If you find it useful, I’d appreciate a on the repo.
Thanks, @dailker
Regarding documentation, comments in tens of .h files in third level directories are very user unfriendly, regardless of their quality (which seems fairly good). You need:
1) an overview of the available functionality, design choices, aspects that need feedback and contributions etc.
2) a guide of what headers every function or macro is located in (consider fragmenting headers less, possibly adding "umbrella" headers that just include a set of the current headers that is likely to be used together)
3) generated API docs in the web site.