sandboxed-api/oss-internship-2020/lodepng
Christian Blichmann dbaf95c724 Move utility code into sandboxed_api/util
This change should make it less confusing where utility code comes from.
Having it in two places made sense when we were debating whether to publish
Sandbox2 separately, but not any longer.

Follow-up changes will move `sandbox2/util.h` and rename the remaining
`sandbox2/util` folder.

PiperOrigin-RevId: 351601640
Change-Id: I6256845261f610e590c25e2c59851cc51da2d778
2021-01-13 09:25:52 -08:00
..
examples Move utility code into sandboxed_api/util 2021-01-13 09:25:52 -08:00
patches renamed project folder 2020-09-28 15:11:44 +00:00
.gitignore renamed project folder 2020-09-28 15:11:44 +00:00
CMakeLists.txt removed computer specific line in CMakeLists.txt 2020-09-29 19:31:30 +00:00
README.md renamed project folder 2020-09-28 15:11:44 +00:00

LodePNG Sandboxed API

Sandboxed version of the LodePNG library, using Sandboxed API

Details

With Sandboxed API, many of the library's functions can be sandboxed. However, they need the extern "C" keyword defined so that name mangling does not happen, which is why a patch that adds it is used. The only differences are found in the header file. An alternative to this is to define another library that wraps every needed function, specifying the required keyword.

Even if many of the functions from the library can be sandboxed, there are some that are not supported (those which have std::vector parameters, overloaded functions etc.). If you really need these functions, a solution is to implement a custom library that wraps around these functions in order to make them compatible.

Patches

In the patches folder there is a patch file that adds extern "C" to the required functions in the header file in order to sandbox them. This patch is applied automatically during the build phase.

Build

First, run git submodule update --init --recursive to update submodules. After this, run the following commands:

mkdir -p build && cd build

cmake .. -G Ninja

cmake --build .

The example binary files can be found in build/examples.

Examples

The code found in the examples folder features a basic use case of the library. An image is generated, encoded into a file and then decoded to check that the values are the same. The encoding part was based on this example while decoding was based on this.

This example code is structured as:

  • main_unsandboxed.cc - unsandboxed example
  • main_sandboxed.cc - sandboxed version of the example
  • main_unit_test.cc - tests(using Google Test).

On top of those files, there are other files used by all three of the examples:

  • sandbox.h - custom sandbox policy
  • helpers.h and helpers.cc - constants and functions used in the main files.

The executables generated from these files will create a temporary directory in the current working path. Inside that directory the two generated png files will be created. At the end, the directory is deleted. If those programs do not stop midway or return a failure code, then everything works fine.