Smallest "C" Program !!

[Jordan Abel]

pemo said:


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

As it is in C89, since it doesn't return int.

Its absence means that the program is not a legal C99 program.
Furthermore, C99 eliminates implicit int. Here is the shortest legal
version of your program:

#include<stdlib.h>
int main(){exit(0);}

void exit();
int main(){exit(0);}

 

[MCheu]

Hello Folks,

I had faced this objective in one of my aptitude exams, that
"What could be the smallest "C" program?

And, as we know, smallest program means, it should execute
single statement, I wrote ";" (Semicolon), so, program output will
display blank screen.

But Friends, I am not sure, Does anyone has perfect solution?

Thanks..

Depends.

If the question is an English comprehension question, one
interpretation would be that we're talking about a program named "C"
(thus the quotes). The smallest "C" program would then be a program
named "C". So would the largest "C" program, for that matter. So the
answer is "C". This is kind of ridiculous, but they've put weirder
questions than that on aptitude/IQ tests.

If you're talking about a program written in the C programming
language, then see the rest of the comments.

 

[Richard Heathfield]

Jordan Abel said:

void exit();
int main(){exit(0);}

Um, quite so. Good call.

 

[Ben Pfaff]

pemo said:


In C99, a declaration is required for exit(). Its absence means that the
program is not a legal C99 program. Furthermore, C99 eliminates implicit
int. Here is the shortest legal version of your program:

#include<stdlib.h>
int main(){exit(0);}

We're talking C99 specifically? How about
int main(){}
To be C89 compliant also:
int main(){return 0;}

 

[Richard Heathfield]

Ben Pfaff said:

We're talking C99 specifically? How about
int main(){}
To be C89 compliant also:
int main(){return 0;}

....which avoids the need to declare exit, but then makes it a different
program to the one pemo posted, which specifically calls exit.

Incidentally, I find it very difficult to get out of the habit of writing in
the C90/C99 subset. I also find it quite difficult to use programming
"tricks" such as int main(){} - I simply don't think of them! Or rather, if
I do think of them, I think of them as Clarence Darrow thought of spinach.

 

[Peter Nilsson]

...
C99 requires main to be int [explicitly declared]

C89 requires main to explicitly return a value.

Where does it say that in C89? In the absense of an explicit returned
value from main
(or call to exit()), the status returned to the host is undefined. But
that is distinct from
saying the behaviour of the program is undefined!

Note that C99 still allows non void functions to fail to return a
value, so long as the
calling function doesn't attempt to use that value. Both C90 and C99
make explicit
statements about the behaviour when (the original call to) main fails
to return a value.

 

[Emmanuel Delahaye]

Dev a écrit :

I had faced this objective in one of my aptitude exams, that
"What could be the smallest "C" program?

And, as we know, smallest program means, it should execute
single statement, I wrote ";" (Semicolon), so, program output will
display blank screen.

But Friends, I am not sure, Does anyone has perfect solution?

[C90]
main(){return 0;}

[C99]
int main(){}

 

[Ben Pfaff]

Ben Pfaff said:


...which avoids the need to declare exit, but then makes it a different
program to the one pemo posted, which specifically calls exit.

Ah, now I understand the distinction you were making.

Incidentally, I find it very difficult to get out of the habit of writing in
the C90/C99 subset. I also find it quite difficult to use programming
"tricks" such as int main(){} - I simply don't think of them! Or rather, if
I do think of them, I think of them as Clarence Darrow thought of spinach.

When it is possible, I try to write code that is valid in both
C90 and C99. In the case of main(), and in most other cases, it
is so easy that there is no reason not to.

 

[Keith Thompson]

I had faced this objective in one of my aptitude exams, that
"What could be the smallest "C" program?

And, as we know, smallest program means, it should execute
single statement, I wrote ";" (Semicolon), so, program output will
display blank screen.

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().

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

m(){}

is a valid C program *if* the implementation documents "m" as the name
of the startup function. (As far as I know, there are no such
implementations. My unsupported hunch is that all existing compilers
that define an startup function other than "main" give it a name
that's at least 4 characters long.)

Then again, a conforming C implementation is allowed to provide
extensions as long as they don't alter the behavior of any strictly
conforming program (C99 4p6), and a "conforming program" is one that
is acceptable to a conforming implementation (C99 4p7). So *if* an
implementation provided an extension allowing an empty file to be
equivalent to, say, "int main(void){return 0;}", then an empty source
file would be a "conforming program". (The category of "conforming
program" really isn't particularly useful; it was included in the
standard for political reasons.)

If we wanted to get *really* silly about this, we could define a
mechanism for creating files with negative sizes. For example, a file
with size -100 would become an empty file if you append 100 bytes of
data to it. And as long as we allow this, we might as well implement
files with transfinite negative sizes (along with a C implementation
with an extension that supports such a file). Given these
assumptions, since there is no largest transfinite number, there is no
smallest C program (the same is true if we merely allow finite
negative sizes. And the entire question vanishes in a puff of logic.

 

[Richard Heathfield]

Ben Pfaff said:

When it is possible, I try to write code that is valid in both
C90 and C99.

Likewise - and it is always possible. ;-)

In the case of main(), and in most other cases, it
is so easy that there is no reason not to.

Right. And in any case, IMHO there's something icky about defining a
function to return int and then not returning an int therefrom.

 

[Keith Thompson]

Ben Pfaff said: [...]

In the case of main(), and in most other cases, it
is so easy that there is no reason not to.

Right. And in any case, IMHO there's something icky about defining a
function to return int and then not returning an int therefrom.

Right, but the challenge was to write the smallest C program, not to
write the smallest non-icky C program.

 

[Richard Heathfield]

Keith Thompson said:

Ben Pfaff said: [...]

In the case of main(), and in most other cases, it
is so easy that there is no reason not to.

Right. And in any case, IMHO there's something icky about defining a
function to return int and then not returning an int therefrom.

Right, but the challenge was to write the smallest C program, not to
write the smallest non-icky C program.

Agreed. I was (deliberately) topic-drifting into the sunset...

 

[Dik T. Winter]

>
> I think it is - this is roughly the K&R equivalent of a function
> returning void, as far as I can tell. And we all know void main is
> illegal.

No, it is not (even roughly) equivalent. The following snippet is
entirely correct in C89:

int f(int x) {
if(x == 0) return 1;
}

int main(void) {
f(1);
printf("%d\n", f(0));
}

Changing f to "void f(int x);" would make it incorrect according to the
standard. Also any use of f(1) would give it undefined behaviour
(probably including casting it to void).

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> My take would be that, in a hosted environment, as it is not possible
> to know what the environment would do with the return result, including
> actually using it, a value has to be returned as if it's known it's
> going to be used. Hence, you shouldn't omit the return value from main.

But that is outside the domain of what the language specifies. As far as
the language is concerned it is irrelevant whether something outside the
language uses it.

> For example, if you use the same program from the command line you may
> not need, or care, about the return value (e.g. a quick `cp` in *nix).
> OTH, a shell script may want to know the return value and alter it's
> flow accordingly (did `cp` succeed?).

That is clear. But what does it matter to the specification of C?

Falling off the end of main without returning a value, in C89 probably
returns a random value. What happens when you use it in the environment
is outside the language. Possibly if the random number happens to be
0, the system would indicate failure (VMS). On the other hand, falling
off a non-void function within the program and using it has definite
consquences, the result is undefined behaviour according to the standard.

 

[Jordan Abel]

No, it is not (even roughly) equivalent. The following snippet is
entirely correct in C89:

int f(int x) {
if(x == 0) return 1;
}

int main(void) {
f(1);
printf("%d\n", f(0));
}

Changing f to "void f(int x);" would make it incorrect according to the
standard.

"the standard" isn't relevant to what I said about K&R. Even in c89, we
all know that the value returned by the initial call to main is always
used.

 

[Vladimir S. Oka]

But that is outside the domain of what the language specifies. As far
as the language is concerned it is irrelevant whether something
outside the language uses it.

I was just giving possible justification for why I interpret the
debatable point of the Standard differently. That might not have been
clear from my language.

That is clear. But what does it matter to the specification of C?

Just a "real life" example of what I said above...

Falling off the end of main without returning a value, in C89 probably
returns a random value. What happens when you use it in the
environment is outside the language. Possibly if the random number
happens to be 0, the system would indicate failure (VMS). On the
other hand, falling off a non-void function within the program and
using it has definite consquences, the result is undefined behaviour
according to the standard.

Yes, that would be a good explanation of the behaviour in case I'm
wrong, and you're right.

As I said in my post (you rightly snipped that last sentence), I'm
prepared to be wrong on this one. However, I don't think
you've /proven/ me wrong. We just interpret a dubious (at least for us)
point differently.

Someone else wants a go?

 

[Hemant Mohan]

Wrong. As we know, the smallest program should at least have a main()
function.

int main(void){return 0;}

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

 

[Stuart]

Richard Heathfield <[email protected]> writes:

We're talking C99 specifically? How about
int main(){}

To be C89 compliant also:
int main(){return 0;}

I really do not know much about C, but could a C89 compliant version be:
int main(){main;}

This has different behaviour - but seems to be legal C!

Regards

 

[Richard Heathfield]

Stuart said:

I really do not know much about C, but could a C89 compliant version be:
int main(){main;}

This has different behaviour - but seems to be legal C!

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

int main(void)
{
char *p = NULL;
p;
return 0;
}

This is legal C (which doesn't, it must be said, do a great deal). The
pointer expression p is evaluated, and the result discarded.

Now consider this code:

int main(void)
{
int answer = 42;
answer;
return 0;
}

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

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

HTH. HAND.

 

[S.Tobias]

An empty file is a valid C source file,

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

but it's not a program unless
it includes a definition of main().

Well, I'd even hesitate to call an empty file "a source file".

....

So *if* an
implementation provided an extension allowing an empty file to be
equivalent to, say, "int main(void){return 0;}", then an empty source
file would be a "conforming program".

Interesting. It would have to give it weak linkage, and the linker
would have to be able to merge multiple such definitions into one.
Very close to C++ linker.