On 2016-02-29, Vincent Lefevre <vinc...@vinc17.net> wrote: > When I cross-compile for Windows and run "make check" without > LOG_COMPILER=wine (by mistake), strange files appear. [...] > ./tadd.exe: 1: ./tadd.exe: MZ ��¸@€º´: not found > ./tadd.exe: 2: ./tadd.exe: : not found > ./tadd.exe: 1: ./tadd.exe: @.bss €: not found > ./tadd.exe: 1: ./tadd.exe: .textd*,: not found > ./tadd.exe: 3: ./tadd.exe: JPL2@�.idata: not found [...] > So, it appears that tadd.exe (which is a binary[*]) was executed > by a shell! [...] > 10517 execve("./tadd.exe", ["./tadd.exe"], [/* 116 vars */]) = -1 ENOEXEC > (Exec format error) > 10517 execve("/bin/sh", ["/bin/sh", "./tadd.exe"], [/* 116 vars */]) = 0
Later on 2016-02-29, Vincent Lefevre <vinc...@vinc17.net> wrote: > Sorry, forget this bug report. After wondering where the problem came > from exactly, I've eventually found that this is some incredible bug > in dash! This crazy behaviour is actually permitted by POSIX, and to a certain extent is even mandatory. When executing a command whose name contains a slash: "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell. If the executable file is not a text file, the shell may bypass this command execution." (The text for commands without a slash is similar). In POSIX text files are permitted to contain bytes with any value other than 0 (NUL), so all sorts of line noise counts and is required to be executed as a shell script. But since the check is optional dash might just not bother doing it, or maybe does not look at the entire file. Cheers, Nick