Smallest "C" Program !!

[Keith Thompson]

It's a violation of syntax for `translation-unit'.

[...]

So it is; good catch. C99 6.9p1:

translation-unit:
external-declaration
translation-unit external-declaration

i.e., a translation-unit consists of a sequence of one or more (not
zero or more) external-declarations.

 

[Dik T. Winter]

>
> "the standard" isn't relevant to what I said about K&R.

In what way is the function f above roughly equivalent to a function
returning void? What about the following?
int f(int x) {
if(x == 0) return 1;
if(x == 1) return;
}

> Even in c89, we
> all know that the value returned by the initial call to main is always
> used.

Let me quote C89:
"If a return statement without an expression is executed, and the value
of the function call is used by the caller, the behavior is undefined.
Reaching the } that terminates a function is equivalent to executing
a return statement without an expression."
I now note however in the description of main:
"If the main function executes a return that specifies no value, the
termination status returned to the host environment is undefined."
So in this case *no* undefined behaviour.

 

[Thomas Maier-Komor]

The function may not necessarily be main. Many implementations
specially those used in embedded systems define their own startup
function.

we are talking about the programming language C here. So would you
please read ISO9899...

 

[Jordan Abel]

we are talking about the programming language C here. So would you
please read ISO9899...

Yes, specifically paragraph 5.1.2.1.1

 

[Jordan Abel]

I now note however in the description of main:
"If the main function executes a return that specifies no value, the
termination status returned to the host environment is undefined."
So in this case *no* undefined behaviour.

I don't see why that's not undefined behavior

suppose it happens to return a termination status that instructs the
operating system to set the computer on fire?

 

[Stuart]

Stuart said:

Bereft of its function call operator, the name of a function acts as a
pointer to that function. Consider the following code:

Same deal. The integer expression answer is evaluated, and the result
discarded.

Same deal with main; i.e. no big deal.

So I should (probably) have written:

int main(){main();}

Looking at the code generated by a compiler I have to hand, this seems to
create a continuous loop - this would seem to resolve any problems about
what main should return to the environment since it will not return at all.

In realising this program as a continuous loop the compiler looks to be
applying tail-recursion optimization. If this was not done, the compiler
might create a recursive call that would eventually exhaust available memory
on a 'real' computer. However, this would seem to be a 'problem' of the
physical constraints of the machine chosen to run the program - not the
program itself (which did not have any memory constraints in its
requirements).

 

[pete]

I don't see why that's not undefined behavior

C isn't concerned with what happens
after a C program has finished executing.

 

[Thomas Maier-Komor]

Yes, specifically paragraph 5.1.2.1.1

OK - sorry ;-)

 

[Dik T. Winter]

>
> I don't see why that's not undefined behavior

Undefined behaviour is with respect to the program. What happens when
the program is done is outside the realm of the language.

 

[Kevin Handy]

A lone semicolon is not a valid C program. It can be a null
statement, but only if it appears inside a function definition
(statements cannot appear outside functions). A lone semicolon is
*not* a null declaration (there's no such thing), though some
compilers may allow it.

An empty file is a valid C source file, but it's not a program unless
it includes a definition of main().

Some compilers have a main() hidden somewhere in the libraries.
iirc. one Obfuscated C winner was a blank file, which caused a
change in the rules.

A freestanding implementation may define a startup function other than
main. So this:

m(){}

If you don't mind that it probably (almost definitely) won't
run, and probably violates a lot of rules, you can define a
main program as

int main=0;

and using your name shortening for freestanding environment plus
assumed int, and not initializing the value, you get:

m;

for non-freestanding systems, you need the much longer

main;

It isn't going to run well on most machines, and will probably
give warnings (at a minimum) on modern compilers due to the
missing storage type, but should be able to create an executable.

 

[Keith Thompson]

Some compilers have a main() hidden somewhere in the libraries.
iirc. one Obfuscated C winner was a blank file, which caused a
change in the rules.

If you post a followup, please don't send a duplicate copy by e-mail.

I don't recall an IOCCC entry that was a blank file, or one that
assumed main() was defined in the library somewhere. I do remember
one that used
#include "/dev/tty"
and resulted in a rule change.

If you don't mind that it probably (almost definitely) won't
run, and probably violates a lot of rules, you can define a
main program as

int main=0;

and using your name shortening for freestanding environment plus
assumed int, and not initializing the value, you get:

m;

for non-freestanding systems, you need the much longer

main;

"main;" would likely be accepted by at least some pre-ANSI compilers
(an early IOCCC entry declared main as an array, initialized to code
that would run either on a PDP-11 or a VAX), but it's not legal under
any standard. If you don't mind violating a lot of rules, there's not
much point in the challenge.

 

[Dave Thompson]

pemo said:

In C99, a declaration is required for exit(). <snip>

Even in C89 it is technically UB to call a void func(int) using the
implicit declaration as int func(). Although as this function never
returns it's pretty unlikely to actually cause a problem.

- David.Thompson1 at worldnet.att.net

 

[Keith Thompson]

Even in C89 it is technically UB to call a void func(int) using the
implicit declaration as int func(). Although as this function never
returns it's pretty unlikely to actually cause a problem.

Agreed.

One way it *could* cause a problem is if a call to a function
returning int reserves space on the stack for the result, and a call
to a void function doesn't. If the caller thinks exit() returns int,
the entire stack frame could be skewed; for example, the function
might not be able to access its parameters. (It could also cause
problems with the return address, but that's not much of an issue for
exit().)

I think the reason this *doesn't* happen is that most calling
conventions were designed before the invention of void. It's one of
those problems that rarely happens in real life, but that you should
never assume can't happen.

 

[slebetman]

I don't recall an IOCCC entry that was a blank file

The 1994 winner for worst (best) abuse of rules: smr. The program
claims to be the smallest possible quine. The judges commented that
while a blank file is not strictly a valid C program it is not an
invalid C program either. This resulted in the following rule change:

In the future, the contest rules will specify a minimum
size that is one character larger than this entry, forever
eliminating this sort of program from contest. After all,
how many variations can one make on this entry?

Just in case some smart ass decided to submit the smallest possible
program for "true". As a side note, the program "true" on many systems
is indeed an empty file or a file filled with comments (I've seen a
file of only copyright notice).

 

[Guillaume]

The 1994 winner for worst (best) abuse of rules: smr. The program
claims to be the smallest possible quine. The judges commented that
while a blank file is not strictly a valid C program it is not an
invalid C program either.

Which is a nice story for programmers and actually makes a good case:
inadequate/insufficient requirements can lead to big disappointments
in the outcome of software projects.

 

[Keith Thompson]

Just in case some smart ass decided to submit the smallest possible
program for "true". As a side note, the program "true" on many systems
is indeed an empty file or a file filled with comments (I've seen a
file of only copyright notice).

Sure, but that's a shell script, not a C program.