You aren't stripping slashes.

I tried `#include </dev/urandom>` and it eventually crashes the container failing to allocate memory (looks like they have a 4GB limit?)

Haha, that's clever. Yes, it's a 4GB limit. Guess I'll try to fix that again. EDIT: fixed

Still some workarounds to the slash-stripping:

  #include "\
  /etc/passwd"

  program221/code.cpp:1:11: warning: backslash-newline at end of file
      1 | #include "\
        |            
  In file included from program221/code.cpp:2:
  /etc/passwd:1:5: error: found ':' in nested-name-specifier, expected '::'
      1 | root:x:0:0:root:/root:/bin/bash
        |     ^
        |     ::
  /etc/passwd:1:1: error: 'root' does not name a type
      1 | root:x:0:0:root:/root:/bin/bash
        | ^~~~

Is it possible to restrict the compiler's access to only files in "/usr/include" instead? Seems like it'd be hard to cover every case with just pattern matching.

It would be awesome if you could place restrictions on the compiler, but I don't know of any such features atm. Still, the compilation happens in the container (which is just a default Ubuntu image with a cross compiler in it). I don't know how much information there is to disclose. Not taking it lightly though, I guess I will have to find a way to really handle the preprocessor stuff, but I still want people to be able to include system headers.

> Is it possible to restrict the compiler's access to only files in "/usr/include" instead? Seems like it'd be hard to cover every case with just pattern matching.

chroot into a build environment

You can LD_PRELOAD an .so that overrides `open` and family of functions, and drop opens based on a whitelist/blacklist.

`#include </etc/lsb-release>` gave some interesting errors. Looks like it's running Ubuntu.

Yeah, that's definitely a big "Here, hack me" post you just put up there.