It's also the shortest C program that you can link at all.
The Shortest Crashing C Program
11–20 of 94 posts
Re: The Shortest Crashing C Program
#12It depends on the definition. You can do better than this if you define a valid C program as anything that passes though the C compiler and generates an executable. Behold the zero length program: $ touch a.c $ gcc -c a.c $ ld a.o ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078 $ ./a.out Segmentation fault
That's a shame. At least in one point in history, that was the shortest-known quine:
Re: The Shortest Crashing C Program
#13The Shortest Crashing Wordpress Site
Re: The Shortest Crashing C Program
#14The first IOCCC winner declared main as a short[] of VAX machine code: http://www.ioccc.org/1984/mullender.c
You could probably do the same thing in x86 and it'd work on a modern compiler.
Re: The Shortest Crashing C Program
#15Seems to work really well: It even crashed the website.
But now we can't marvel at how short it is.
Re: The Shortest Crashing C Program
#16It depends on the definition. You can do better than this if you define a valid C program as anything that passes though the C compiler and generates an executable. Behold the zero length program: $ touch a.c $ gcc -c a.c $ ld a.o ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078 $ ./a.out Segmentation fault
That's a shame. At least in one point in history, that was the shortest-known quine: http://www.ioccc.org/years.html#1994_smr
It still is, provided you follow the build procedure prescribed by the author of that quine (check the Makefile from the contest):
$ rm -rf a
$ cp a.c a
$ chmod +x a
$ ./a
$
Re: The Shortest Crashing C Program
#17I'm not convinced this is a C89 program. It is only an "accident" that the linker doesn't know about types. I find it hard to believe that the C89 spec states that an integer called "main" is to be considered the main function, and suspect this is undefined behaviour (though I've not checked).
It compiles and runs with gcc -std=c89 and gcc -std=c99, so even if it's not a true C89 program, it's a compilable GNUC89 program.
$ gcc -std=c99 -pedantic /tmp/main.c -o /tmp/main
/tmp/main.c:1:1: warning: data definition has no type
or storage class [enabled by default]
/tmp/main.c:1:1: warning: type defaults to ‘int’ in
declaration of ‘main’ [enabled by default]
/tmp/main.c:1:1: warning: ‘main’ is usually a function
[-Wmain]
$ /tmp/main
Segmentation fault (core dumped)Re: The Shortest Crashing C Program
#18I'm not convinced this is a C89 program. It is only an "accident" that the linker doesn't know about types. I find it hard to believe that the C89 spec states that an integer called "main" is to be considered the main function, and suspect this is undefined behaviour (though I've not checked).
It can't be a valid C89 program. On many Harvard architecture based microprocessors data pointers and code pointers have differing size.
Different size maybe, but different busses^H^H^H^H^H^Haddress spaces definitely, and using an address on the wrong bus is a sure way to cause problems.
Re: The Shortest Crashing C Program
#19The site seems down, "Error establishing a database connection"
Re: The Shortest Crashing C Program
#20The 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 guaranteed. (uint32_t)0 is a valid sequence of instructions - it's ADD BYTE PTR [EAX],AL - and so if EAX contained a valid value then it would execute without a problem. Then, if the following byte were 0xC3 (RET) then the program would execute. OK, so that's all rather unlikely, but you have to bear these things in mind. So I think 0xCC (INT 3) would be a better choice.)