61–70 of 94 posts
Earlier quoted context omitted.
Originally I thought I'd skip mentioning compiling empty files because doing so without linking separately `gcc` will refuse to link it. I updated the article with a reference to your comment.
Actually you don't have to link it separately if you don't link against stdlib. See my comment here: https://news.ycombinator.com/item?id=5762578
main(){}
??
Earlier quoted context omitted.
I find it interesting that displays the error from exec, but not bash: zsh: exec format error: ./a
Why? The file is marked as executable, so the shell very reasonably tries to execute it by calling some well-chosen member of the exec() family ( http://linux.die.net/man/3/exec ). The exec() function then needs to open and parse the file according to the formats it supports, which of course fails since the file is empty. Do you simply mean that you expected the shell to validate this, and not try to execute empty fi…
In Seventh Edition UNIX, /bin/true is an empty file; it is a shell script that succeeds at does nothing.
Some later commercial UNIXes are noted to have /bin/true contain nothing but comments containing a copyright notice for that nothing.
And interesting question, what would be the shortest not crashing C program? main(){} ??
The explanation is not quite correct - execution starts at &main rather than the address given by the value of main. On VC++, at least - well, on my PC anyway - the process halts because the data segment doesn't have the execute bit set. It isn't trying to run code at address 0. (If execution of bytes in the data segment were possible, which I'm sure it used to be, then you'd still likely get a crash, but it's not gu…
No, a ret instruction would probably segfault, depending on the content of the stack. To terminate a program you have to use the corresponding system call. On linux : mov $1, %eax int $0x80
The explanation is not quite correct - execution starts at &main rather than the address given by the value of main. On VC++, at least - well, on my PC anyway - the process halts because the data segment doesn't have the execute bit set. It isn't trying to run code at address 0. (If execution of bytes in the data segment were possible, which I'm sure it used to be, then you'd still likely get a crash, but it's not gu…
No, a ret instruction would probably segfault, depending on the content of the stack. To terminate a program you have to use the corresponding system call. On linux : mov $1, %eax int $0x80
If you've got VS2012, you can see this code in the file at something like "c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\crt0.c" (it should be easy to find for other versions - it's been in pretty much in that place, with that name, probably with those contents, since VC5 I think).
For glibc, see http://sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-sta....
My post was a bit x86/VC++-specific but the principles have been common to all the C environments I've used. I don't think I've ever used one that by default called your startup function directly, bypassing C runtime initialisation. (Though it's very easy to set this up with Visual Studio.)
Interesting. We tried to do the same for Haskell. The shortest we could come up with: import Unsafe.Coerce;main=unsafeCoerce()1
main=undefinedEarlier quoted context omitted.
I find it interesting that displays the error from exec, but not bash: zsh: exec format error: ./a
Why? The file is marked as executable, so the shell very reasonably tries to execute it by calling some well-chosen member of the exec() family ( http://linux.die.net/man/3/exec ). The exec() function then needs to open and parse the file according to the formats it supports, which of course fails since the file is empty. Do you simply mean that you expected the shell to validate this, and not try to execute empty fi…
I understand what happens here and why there is an error message in zsh, but I'm surprised by the fact that bash does not signal the error (exec returns -1, after all).
Bash includes logic to parse ELF[1], so I guess that after exec fails it tries to parse the file and has a special case for empty files.
[1]: http://utcc.utoronto.ca/~cks/space/blog/unix/BashSuperintelligentExecThe explanation is not quite correct - execution starts at &main rather than the address given by the value of main. On VC++, at least - well, on my PC anyway - the process halts because the data segment doesn't have the execute bit set. It isn't trying to run code at address 0. (If execution of bytes in the data segment were possible, which I'm sure it used to be, then you'd still likely get a crash, but it's not gu…
(gdb) print &main
$1 = (int *) 0x600864
(gdb) run
Starting program: /tmp/s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000600864 in main ()
(gdb) print &main
$1 = (int *) 0x600864
(gdb) run
Starting program: /tmp/s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000601000 in ?? ()
(gdb) x/i &main
0x600860 : retq
(gdb) run
Starting program: /tmp/s_ret
[Inferior 1 (process 10588) exited with code 0140]