Binfmtc – binfmt_misc C scripting interface

The use of $@ doesn't look right to me.

In the trivial case exposed here where there are no additional arguments to pass to the .c program, the shell executes

  gcc "print.c" -o .out && exec ./.out

and it works "by chance".

In a more complex scenario where print.c expects some parameters, it won't work. For example,

  ./print.c a b c

will result in the shell trying to invoke

  gcc "print.c" -o "a" "b" "c".out && exec ./"a" "b" "c".out

which makes no sense.

Are you sure you didn't intend $0 instead of $@ ?

Oh this is neat. Took me a bit.

The shell treats the first line as a comment. It executes the second line, which eventually exec's the binary so the rest of the file do not matter to the shell.

And the compiler treats the first line as a preprocessor directive, so it ignores the second line.

I initially misread/mistook the first line for a shebang.

Compiler errors won’t cause as many funny consequences with

  gcc "$0" -o "$@".out && exec ./"$@".out || exit $?   # I'd use ${0%.c} not $@

Love this trick too, but the difference, as far as I understand, is that it only works with a Bourne(-compatible) shell, whereas shebangs or binfmt_misc also work with exec().

You can also #embed the compiler binary, and execve it to much the same effect as binfmtc. I explored that trick for an IOCC entry that was never submitted because it ended up far too readable.

It's still valid C source code? Is the #! sequence valid C?

This is a neat hack, but the whole file is not a valid C program.

I like that too, but the problem is that C doesn't keep its end of the deal. No hand holding, but make what you are doing transparent. It used to be the case back in the 80s, but not anymore. Not with our optimizing compilers and oodles of UB and spec subtleties and implicit actions.