modified readme

oss-internship-2020/sapi_lodepng/CMakeLists.txt

@@ -26,9 +26,7 @@ add_library(lodepng STATIC
 )
 
 # Build SAPI library
-#set(SAPI_ROOT "" CACHE PATH "Path to the Sandboxed API source tree")
-set(SAPI_ROOT "/usr/local/google/home/amedar/internship/sandboxed-api" CACHE PATH "Path to the Sandboxed API source tree")
-
+set(SAPI_ROOT "" CACHE PATH "Path to the Sandboxed API source tree")
 
 add_subdirectory("${SAPI_ROOT}"
   "${CMAKE_BINARY_DIR}/sandboxed-api-build"

oss-internship-2020/sapi_lodepng/README.md

@@ -1,40 +1,33 @@
-# LodePng Sandboxed
+# LodePNG Sandboxed API
 
-Sandboxed version of the [lodepng](https://github.com/lvandeve/lodepng) library, using [Sandboxed API](https://github.com/google/sandboxed-api)
+Sandboxed version of the [LodePNG](https://github.com/lvandeve/lodepng) library, using [Sandboxed API](https://github.com/google/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 fork of the **lodepng** library 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.
+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 fork of the **LodePNG** library 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.
 
+## 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`
+`ninja`
+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](https://github.com/lvandeve/lodepng/blob/master/examples/example_encode.c) while decoding was based on [this](https://github.com/lvandeve/lodepng/blob/master/examples/example_decode.c).
 
-This folder is structured as:
-- `main.cc` - unsandboxed example
-- `sandbox.h` - custom sandbox policy
+This example code is structured as:
+- `main_unsandboxed.cc` - unsandboxed example
 - `main_sandboxed.cc` - sandboxed version of the example
-- `main_unit_test.cc` - testing file using [Google Test](https://github.com/google/googletest).
+- `main_unit_test.cc` - tests(using [Google Test](https://github.com/google/googletest)).
 
-The executables generated from these files will create the png files in the current directory. However, for the 
-`main_sandboxed.cc` file there is also the `images_path` flag which can be used to specify a different directory.
+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.
 
-<!-- 
-TODO
-
-- ~~check return value of functions~~
-- ~~integrate unit testing~~
-- add more functions
-- this readme
-- include abseil flags for unit testing
-- ~~improve tests (images, generating images etc.)~~
-- clear redundant includes
-- ~~check if security policy can be stricter~~
-- ~~use addDirectoryAt instead of addDirectory~~
-- ~~modify tests assertions~~
-- ~~add useful prints to unit tests~~
-- ~~move examples to examples folder~~
-  
- -->
+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.

oss-internship-2020/sapi_lodepng/examples/CMakeLists.txt

@@ -67,4 +67,3 @@ target_link_libraries(main_unit_test PRIVATE
   sapi::vars
 )
 gtest_discover_tests(main_unit_test)
-

oss-internship-2020/sapi_lodepng/examples/main_sandboxed.cc

@@ -23,7 +23,7 @@ void EncodeDecodeOneStep(SapiLodepngSandbox &sandbox, LodepngApi &api) {
   // Generate the values.
   std::vector<uint8_t> image(GenerateValues());
 
-  // Encode the image
+  // Encode the image.
   sapi::v::Array<uint8_t> sapi_image(image.data(), kImgLen);
   sapi::v::ConstCStr sapi_filename("/output/out_generated1.png");
 
@@ -51,13 +51,11 @@ void EncodeDecodeOneStep(SapiLodepngSandbox &sandbox, LodepngApi &api) {
   // The pixels have been allocated inside the sandboxed process
   // memory, so we need to transfer them to this process.
   // Transferring the memory has the following steps:
-  // 1) define a RemotePtr variable that holds the memory location from
-  // the sandboxed process
-  // 2) define an array with the required length
-  // 3) set the remote pointer for the array to specify where the memory
-  // that will be transferred is located
-  // 4) transfer the memory to this process (this step is why we need
-  // the pointer and the length)
+  // 1) define an array with the required length.
+  // 2) set the remote pointer for the array to specify where the memory
+  // that will be transferred is located.
+  // 3) transfer the memory to this process (this step is why we need
+  // the pointer and the length).
   sapi::v::Array<uint8_t> sapi_pixels(kImgLen);
   sapi_pixels.SetRemote(sapi_image_ptr.GetValue());