intel / libnica Goto Github PK

Common C library functions

Shell 0.88% Perl 1.29% C 88.59% Makefile 2.87% M4 6.37%

raii function library c modern

libnica's Introduction

DISCONTINUATION OF PROJECT

This project will no longer be maintained by Intel.

Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.

Intel no longer accepts patches to this project.

If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project.

Contact: [email protected] libnica

DISCLAIMER

This library is undergoing an active development cycle. It is currently being developed in tandem with multiple projects, and as such the ABI and API should be considered currently unstable.

Scheduled changes:

Thread pool
Timing tests on all data types (and relevant improvements)
N-ary tree addition
List API changes
Move from C99 to C11
Thread-safe APIs (Atomic)
Improved file access functions
mmap helpers (RAII based)
Improved INI parser (lex-based w/ line continuation)
Fold in cve-check-tool changes/additions
Potential:
- Fold in the templating mini-lib from new cve-check-tool
- Simplified networking access (retaining underlying transparency)

Common C library functions

Lightweight library containing common functionality of typical "C utility libs".

Currently contains:

Dynamic array
List type
Simplified file manipulation functions (mkdir_p, rm_rf, etc)
A Hashmap implementation
A simple, efficient, INI File parser
Safe string manipulation functions for when strlen is out of the question

The majority of the API is designed to work on a RAII principle, using scope-based autofree helpers (see util.h) with minimal fuss.

Another important principle to keep in mind while hacking on libnica, is that memory leaks of any description in a successful usage, are forbidden. This includes any "possibly lost" memory through static initialisation as seen with heavier libraries.

License

LGPL-2.1

libnica's People

Contributors

Stargazers

Watchers

Forkers

bryteise phmccarty harriche ikeydoherty 9176324 ikeyd dorileo anselmolsm wldp alexandereric995 isabella232 564k

libnica's Issues

Start documentation

Add, at minimum, a Doxyen system to document the API, with real-world examples

Create proper filesystem APIs

A common pitfall in C programs that require filesystem manipulation, is actually testing them.

An example of this, and the biggest consumer of Nica, is clr-boot-manager. It has to go around
in circles to create fake roots, mock the content, and skip many important feature tests because
it would be dangerous to actually test them.

This is where we need real filesystem mocking.
The Nica APIs will provide the nc_fs namespace for all filesystem operations. Additionally, this will be achieved with an OOPish design, with each implementation handled with a simple vtable struct, kernel style.

There should be two implementations, the NativeFS, and the MemoryFS. The NativeFS will essentially be a pass through to native APIs, performing real operations.

The MemoryFS will provide an emulated filesystem. The operations only affect the backing story in memory, allowing for useful mocking, i.e. creation of fake VFS, etc.

List type (needs work!)
More string management functions (ala cve_string)
Add a pkg-config file
Install headers to a subdirectory ($includedir/nica ?)
Basic common file management functions
ABI versioned library
Find a non-stupid name

Consuming json data feeds instead of xml

NVD is now offering a BETA release for a new vulnerability data feed using the JSON format. According to them, these JSON feeds are intended to supplant the XML feeds.

Is there any plan to consume json feeds instead of xml feeds ?

Upstream the clr-boot-manager features

clr-boot-manager has a whole bunch of really nice APIs, which should be in libnica itself

Notably:

CbmWriter - a failsafe memstream based stream writer ✓
CbmMappedFile - a very simple mechanism for working with mapped files (with autofrees) ✓
File manipulation functions (atomic copies, etc) ✓
A trivial log mechanism (expand this to be libraryfied) ✓
Better string functions (string_printf) ✓

Perhaps:

Filesystem APIs which allow overriding the process-space vtable for all file ops? Enables easy, safe mocking (would be nice)
Port the cmdline reader into a generic config reader? Especially with the *.d/*.conf support (very low priority, ideally just nice "read this thing" APIs) (meh. maybe)

Add n-ary tree

Pretty obvious really. Likely candidate for name being NcNode