mjansson / foundation_lib

Cross-platform public domain foundation library in C providing basic support data types and functions to write applications and games in a platform-independent fashion.

Foundation Library - Public Domain

This library provides a cross-platform foundation library in C providing basic support data types and functions to write applications and games in a platform-independent fashion. It provides:

• Abstractions and unification of basic data types
• Pluggable memory management
• Threads and synchronization
• Atomic operations
• Timing and profiling
• Object lifetime management
• Events processing
• File system access
• Dynamic library loading
• Process spawning
• Logging, error reporting and asserts
• String handling in UTF-8 and UTF-16
• Murmur hasing and statically hashed strings
• Math support for 32 and 64 bit floats
• JSON/SJSON parser
• SHA256/SHA512 digest
• Application, environment and system queries and control
• Regular expressions
• Exception utilities (SEH, signals)

It is written with the following API design principles in mind:

• Consistent. All functions, parameters and types should follow a well defined pattern in order to make it easy to remember how function names are constructed and how to pass the expected parameters.
• Orthogonal. A function should not have any side effects, and there should be only one way to perform an operation in the system.
• Specialized. A function in an API should perform a single task. Functions should not do completely different unrelated tasks or change behaviour depending on the contents of the variables passed in.
• Compact. The API needs to be compact, meaning the user can use it without using a manual. Note though that "compact" does not mean "small". A consistent naming scheme makes the API easier to use and remember.
• Contained. Third party dependencies are kept to an absolute minimum and prefer to use primitive or well-defined data types.

Platforms and architectures currently supported:

• Windows (x86, x86-64), Vista or later
• MacOS X (x86-64), 10.7+
• Linux (x86, x86-64, PPC, ARM)
• FreeBSD (x86, x86-64, PPC, ARM)
• iOS (ARMv7, ARMv7s, ARMv8/AArch64), 6.0+
• Android (ARMv6, ARMv7, ARMv8/AArch64, x86, x86-64, MIPS, MIPS64)
• Raspberry Pi (ARMv6)

Discord server for discussions https://discord.gg/M8BwTQrt6c

The latest source code maintained by Mattias Jansson is always available at
https://github.com/mjansson/foundation_lib

Main branch is used for development. Releases are tags on main branch. https://github.com/mjansson/foundation_lib/releases

Cross-platform build system uses Ninja
https://ninja-build.org/

This library is put in the public domain; you can redistribute it and/or modify it without any restrictions.

Created by Mattias Jansson (@maniccoder)

foundation_lib's Issues

Thread Pool support

The title says it all.
Thanks.

tests crash on VS2013 when building as debug and release

I downloaded the zip file and test this lib on windows. I used VS2013 and built it under all configs(debug, release, deploy and profile). when I run the tests, all of them crashed(100%) under debug and release. However, the tests are OK under deploy and profile. callstack shows a parameter passed to HeapReAlloc is 0xdeadbeef.
please try to run tests under debug, and I'm sure you can see it and resolve the problem. Thanks!

Build errors on OSX/iOS

This is on 10.4.8 with XCode 4.6.3, deployment target left at 10.6

• there is a name clash / typedef redeclaration using uuid_t as this is already defined in unistd.h as __darwin_uuid_t which is typedef unsigned char __darwin_uuid_t[16]; This can be avoided with #define _UUID_T in the apple define block.
• in fs.c in the posix include block there is < sys/inotify.h > which does not exist on OS X, I believe kqueue is used for this.
• memory.c includes <malloc.h> in the posix include block but on OSX needs to be < malloc/malloc.h > or of course < stdlib.h >
• semaphore_t typedef redeclaration from mach_types.h

build ？

How to build, can you give a template？thanks

Loading library from relative directory doesn't work

When using

library_load("my_path/some_lib");

The code assumes that there is no path in the in the name being sent in. The code will expand the string to look like this (on Mac)

"libmy_path/some_lib.dylib"

Which means that the current code always adds "lib" at the start regardless if there is a directory there or not.

Maybe a bug in POSIX fs_is_file

bool fs_is_file(const char* path, size_t length)
On Arch Linux if path does not exist, returned value is random.
Solution:

int rc = stat(finalpath.str, &st);
if (rc == 0 && (st.st_mode & S_IFREG))
    return true;

Typo

No need for checking definiton of FOUNDATION_ARCH_ARM here
#elif defined( arm ) || FOUNDATION_ARCH_ARM

Dead link

The link is dead in this:

Cross-platform build system uses Ninja
http://martine.github.io/ninja

Thanks.

What about closed/commercial project

Hi,
Excellent work on this library, I would like to use this foundation library as foundation code in my 3D game engine, I cannot understand well the Uni license, can I integrate it into my closed game engine, should I add credit?

Sorry for opening issue but didn't find your mail.

Thanks

Consider remove PNaCl support

As shown in Goodbye PNaCl, Hello WebAssembly!, PNaCl is being deprecated. Removing it would reduce your maintenance burden unless you are using it in other projects. The latest Chromium (64.0.3282.186) cannot run the PNaCl test suite anymore.
Thanks.

Problems building foundation_lib using MSYS2 (MinGW)

My workflow typically involves building Windows libraries from a Linux host using MSYS2 and a cross GCC tool-chain (e.g. cross compile on Linux for a Windows target). Microsoft's Visual Studio is not available.

First Question: Has anyone tried this work-flow or alternate Microsoft compiler?

I put together a GNU makefile to compile foundation_lib directly because in addition to the static archive (libfoundation.a) I also needed a shared library variant (libfoundation.so). On a Linux host (for a Linux target) this works fine - both static and shared libraries are produced using the makefile.

When building the Windows variant of foundation_lib I've encountered the following problem. It appears (somehow) that any file I build within foundation_lib has extra symbols defined (T) in the object file even though they're never referenced in that file. This seems to occur whenever #include <foundation/platform.h> is included in the source file. Here's a simple example function:

File: test.c

#include <string.h>
#include <stdio.h>
#include <math.h>

void test_it(char* buf)
{
        strcpy(buf, "hello");
        sprintf(buf, "%f", fabs(5.0));
        return;
}

Running nm on the resulting test.o I see the following:

0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_loc
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
                 U sprintf
0000000000000000 T test_it

If I add one line to the file to include <foundation/platform.h> . . .

#include <foundation/platform.h>
#include <string.h>
#include <stdio.h>
#include <math.h>

void test_it(char* buf)
{
        strcpy(buf, "hello");
        sprintf(buf, "%f", fabs(5.0));
        return;
}

and recompile and execute nm again to see the symbols I see . . .

0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_loc
0000000000000000 N .debug_str
0000000000000000 p .pdata
0000000000000000 r .rdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
0000000000000030 T _Exit
00000000000000e0 T __fpclassify
0000000000000140 T __fpclassifyf
00000000000000d0 T __fpclassifyl
                 U __imp__stricmp
                 U __imp__strnicmp
0000000000000180 T __isnan
00000000000001b0 T __isnanf
00000000000001d0 T __isnanl
                 U __mingw_vsprintf
00000000000001f0 T __signbit
0000000000000200 T __signbitf
0000000000000210 T __signbitl
                 U _exit
0000000000000330 T copysign
0000000000000380 T copysignf
                 U cosh
0000000000000250 T coshf
                 U exp
0000000000000290 T expf
00000000000000c0 T fabs
00000000000000a0 T fabsf
00000000000000b0 T fabsl
                 U frexp
00000000000002b0 T frexpf
                 U hypot
00000000000002f0 T hypotf
0000000000000080 T imaxabs
                 U ldexp
00000000000002d0 T ldexpf
0000000000000040 T llabs
                 U pow
0000000000000310 T powf
                 U sinh
0000000000000230 T sinhf
0000000000000000 t sprintf.constprop.0
0000000000000070 T strcasecmp
0000000000000060 T strncasecmp
                 U tanh
0000000000000270 T tanhf
00000000000003b0 T test_it

Where did all these (unreferenced) functions like frexpf() or sinhf() come from??? When I build the entire Foundation library for Windows and try to link a shared library (DLL) the linker complains about multiple definitions since each *.o file contains these duplicate symbols. The command line I'm using to compile this example is:

x86_64-w64-mingw32.static-gcc  -c -Wall -Werror -Wextra -Wpedantic -std=c11 -Wno-unknown-pragmas -Wno-unused-parameter -Wno-format -Wno-unused-function -Wno-pedantic -Wno-strict-aliasing -funit-at-a-time -fstrict-aliasing -fno-math-errno -ffinite-math-only -funsafe-math-optimizations -fno-trapping-math -ffast-math -g -DFOUNDATION_COMPILE=1 -DBUILD_DEPLOY=1 -funroll-loops -O4 -m64 -I/home/swdev/project -o test.o  test.c

I am also attaching a file that contains the settings of all the macro definitions defined in the environment as well as in foundation/platform.h. This environment is derived by executing:

echo "#include  <foundation/platform.h>" | x86_64-w64-mingw32.static-gcc -I/home/swdev/project -E -dM - > env.txt

I've also run into some issues with MinGW where functions like _ftime_s() are not defined (had to fall back to using _ftime64()) and localtime_s() and gmtime_s() are not available either. Finally, there is also an issue with crash.c and specifically _crash_dump_file_buffer and _crash_dump_file. Apparently these aren't defined anywhere in the library either. Where are these defined in Windows?

Any help and/or suggestions would be very much appreciated. I'd love to be able to use this library but the Windows support under MinGW seems to be an issue at this time.

Thanks for your time and patience . . .

env.txt

CMake support?

Hi, i liked your library and since i use mainly Windows, its really complicated install 478MB-872MB of the Python runtime just to compile this small library, and CMake is more "small" and is widely used for C/C++ projects is more quick to set up.

I have this little quick and dirty CMakeLists.txt script based from configure.py script, i tested it in Windows 10 in a Visual Studio 2017 installation and compiled as intended (NOTE: i didn't added the test, nor the examples binaries yet).

Thanks.

platform.h MacOS and iOS defines

The macro TARGET_OS_IPHONE is defined in < TargetConditionals.h > therefore this header should be included after the initial test for __ APPLE __

edit: therefore building on device results in unknown arch

Python3 compatibility

When using python3 to generate ninja build script on develop branch, I got:

foundation_lib (git)-[develop] % python configure.py -t linux --host linux -c deploy

Traceback (most recent call last):
  File "configure.py", line 26, in <module>
    foundation_lib = generator.lib(module = 'foundation', sources = foundation_sources + extrasources)
  File "build/ninja/generator.py", line 119, in lib
    return self.toolchain.lib(self.writer, module, sources, libname, basepath, configs, includepaths, variables)
  File "build/ninja/toolchain.py", line 447, in lib
    return self.build_sources(writer, 'lib', 'multilib', module, sources, libfile, basepath, outpath, configs, includepaths, None, None, None, None, variables, None)
  File "build/ninja/toolchain.py", line 406, in build_sources
    buildpath = os.path.join('$buildpath', config, arch)
  File "/usr/lib/python3.6/posixpath.py", line 92, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib/python3.6/genericpath.py", line 151, in _check_arg_types
    raise TypeError("Can't mix strings and bytes in path components") from None
TypeError: Can't mix strings and bytes in path components

Arch Linux x64
Python 3.6

Thanks.

Question: why use objectmap for refcount objects

Thanks for this great library! As a game developer who also prefer C instead of C++, I extremely appreciate your work.

I have a question: why do you use objectmap as an indirection to manage reference counted objects, instead of manipulating object pointers directly (putting the counter inside the object struct intrusively)? I haven't seen this design before, and didn't find any information in this repository. Could you explain the rationale?

btw. I need that task_lib, and want to merge that library into foundation_lib. Will you accept the pull request?

Support for killing process

Hi,

Sorry to bug you with more feature requests but something that would be very useful is something like

FOUNDATION_API int process_kill( process_t* proc );

I'm not sure all platforms you support can use this but for desktop platforms this is quite useful. I have some cases where I spawn a program, run a bunch of tests (connecting with sockets) and the easiest way to shut it down is just to kill the process.

Why this library? Why C for game?

I do like C but I am not in the game industry, so I would like to ask for your opinions on why you created this library and why you use C for game development (I suppose) vs C++?

Lots of errors on Travis for macOS

Following is the log when I tried to use this lib in one of my projects on Travis for macOS:
https://travis-ci.org/pbtrung/cbup/jobs/343104973
Please scroll to the end.
Thanks.

Shared memory

Cross-platform shared memory API is nice for IPC.

random32_range(0, 1) doesn't return 1

As the title says, it doesn't return most high value.

Case insensible compare functions

Would be nice to have these in string.c/h as one thing one often runs into to is that stricmp may not exist or is named something different (like strcasecmp) depending on platform.