[gambit-list] Does anyone else have thoughts on Gambit's C compiler argument evaluation behavior? Re: Is this the recommended way to inline shellscripts in |compile-file|'s cc/ld-options: arguments?
Marc Feeley
feeley at iro.umontreal.ca
Wed Jul 13 09:45:02 EDT 2016
Yes that’s one argument (the avoidance of system exploits through some data that is passed to the shell).
There’s also a portability argument. Shell escaping varies between platforms (Unix/Windows), and also from one shell to another.
Moreover, manual shell escaping has always been a nightmare (how many backslashes to add?) that it is best to avoid it completely by letting the implementation do it automatically. I wouldn’t like a system where the user has to worry about the possibility of arguments containing “$” and “\” and double/single quotes.
So for your use-case I would suggest:
> (define (pkg-config-lib name)
(call-with-input-process
(list path: "pkg-config" arguments: (list "--libs" name))
read-line))
> (pkg-config-lib "zlib")
"-lz"
> (compile-file "test.scm" ld-options: (pkg-config-lib "libjpeg"))
Marc
> On Jul 13, 2016, at 3:09 AM, Adam <adam.mlmb at gmail.com> wrote:
>
> Hi Gambit community,
>
> If I understood Gambit's current behavior right, then there's no way to (compile-file "irrelevant.scm" cc-options: "$(SYSTEM EXPLOIT CODE HERE)") .
>
> So Gambit's approach for this argument is similar to a SQL injection attack safety.
>
> This is not a big deal as compile-file probably never is exported to any untrusted user.
>
> However, for symmetry, it makes sense - so spontaneously, while it was a small surprise to me that the conveniency feature of cc-options: \"$(pkg-config --libs libjpeg\")" wouldn't work, on second thought I think the fact that it does not work is rather a feature than a bug, so I'm positive about the current behavior.
>
>
> Does anyone have an opinion?
>
>
> Thanks.
>
>
> 2016-07-13 13:56 GMT+08:00 Adam <adam.mlmb at gmail.com>:
> Dear Marc,
>
> I'm in a nasty environment where I not can know what exact "-I" and "-l" arguments the C compiler and linker need.
>
> For this reason, I need the pkg-config shell tool to figure it out for me!
>
> It would have seemed logical to me that |compile-file|'s |cc-options:| and |ld-options:| would be evaluated by the system shell by the gambc-cc script, so that this would work:
>
> echo '(print "Hello world\n")' > test.scm
>
> GAMBC_CC_VERBOSE=yes gsc
>
> (compile-file "test.scm"
> cc-options: "$(pkg-config --cflags \"libjpeg\")"
> ld-options: "$(pkg-config --libs \"libjpeg\")"
> )
>
> However, it does not - but instead, the "$(p... strings are passed on verbatim to the C compiler, leading to this output:
>
> gcc [...] -o "test.o1" $(pkg-config --cflags "libjpeg") test.c $(pkg-config --libs "libjpeg")
> gcc: error: $(pkg-config: No such file or directory
> gcc: error: "libjpeg"): No such file or directory
> gcc: error: $(pkg-config: No such file or directory
> gcc: error: "libjpeg"): No such file or directory
> gcc: error: unrecognized command line option ‘--cflags’
> gcc: error: unrecognized command line option ‘--libs’
> *** ERROR IN (console)@2.1 -- C compilation or link failed while compiling "test.scm"
>
>
> I.e. GCC actually gets a "$(pkg-config" argument, a "--cflags" argument and a "\"libjpeg\"" argument, etc. .
>
> So this test is a total catastrophe.
>
> The question then comes, is this a bug or a feature?
>
>
> I can totally see that it is your intended design of gsc+gambc-cc that those arguments should be passed exactly verbatim all the way to the C compiler, it makes sense, for instance as a correctness and a security measure.
>
> So what I am asking here is if you have any thoughts about the convenience factor, or if you have any design thought here or this just design choice just was arbitrary.
>
>
> Anyhow in the absence of shell-evaluation of pkg-config anywhere else, I need to add it explicitly, meaning then that the compile-file command should be:
>
> (compile-file "test.scm"
> cc-options: (myshellrun "pkg-config --cflags \"libjpeg\"")
> ld-options: (myshellrun "pkg-config --libs \"libjpeg\"")
> )
>
> where myshellrun is a procedure that involves open-process and reads its output to a string.
>
> Please confirm that this indeed is the intended best practice for solving this problem.
>
> Thanks!
>
>
More information about the Gambit-list
mailing list