And utility called 'dd' can overwrite your hard disk with nulls. But should it?
The key word above is "usually". There's no good reason to make source files executable. And also, there's no much sense in compiling any source file individually instead of relying on a proper build system.
This is probably meant for tiny script-like programs rather than multiple dependent source files. E.g., I've seen standalone C programs with `#!/usr/bin/tcc -run` shebangs before.
Script files are typically executable. The whole point here is to make a script using a language that requires compilation. So yeah, mark it as executable, it's a script now.
> The whole point here is to make a script using a language that requires compilation.
Then it's a bit of non-orthodox approach here, if not more. As defined in wiki [0] (and on par with what we all are used to):
> Scripting languages are usually interpreted at runtime rather than compiled.
I would not be much happy if script would do some heqvy lifting and output some binary in the current or tmp folder. Which hash needs to be checked each run (against what?) and would require lots of other security-related protections, in real world. In ideal world - not much, but that's not what we are talking about, right?
The key word above is "usually". There's no good reason to make source files executable. And also, there's no much sense in compiling any source file individually instead of relying on a proper build system.