> > Unfortunately the lines that follow: > > > >> either sanitized by an external program to allow only trusted, > >> safe compilation and execution in the context of the application, > > > > again make a reference to a purely theoretical "external program" that > > is not going to exist in reality, and I made a fuss about that in another > > subthread (sorry Siddhesh). We shouldn't speak as if this solution is > > actually available to users. > > > > I know this is not the main point of your email, but we came up with > > a better wording for the compiler driver, and it would be good to align > > this text with that. > > How about: > > The libgccjit library can, despite the name, be used both for > ahead-of-time compilation and for just-in-compilation. In both > cases it can be used to translate input representations (such as > source code) in the application context; in the latter case the > generated code is also run in the application context. > > Limitations that apply to the compiler driver, apply here too in > terms of sanitizing inputs and it is recommended that both the
I'd prefer 'trusting inputs' instead of 'sanitizing inputs' above. > compilation *and* execution context of the code are appropriately > sandboxed to contain the effects of any bugs in libgccjit, the > application code using it, or its generated code to the sandboxed > environment. *thumbs up* Thanks. Alexander
