Why does this C program compile?

http://stackoverflow.com/q/13950642/526535

by manojlds • 14 years ago

45 50 14 years ago

jbuzbee2• 14 years ago

Guess I grew up with old-school C. Looking at the question with example code made me think: "Am I missing something? Looks like pretty ordinary C to me. Why wouldn't it compile?"

gburt• 14 years ago

Yeah, I definitely expected code with missing braces/brackets or something. This is pretty clear why it compiles.

minimax2• 14 years ago

If you were a programmer in the days before C had prototypes then you are definitely from the old school. If you're working on code that still looks like this in 2012 then maybe it's time to brush up on modern C. ;-)

hnriot2• 14 years ago

He didn't say he still works on code like this, but like me, this program is obviously fine, there's no point in asking why it works because c is backward compatible and it's pretty clear to anyone who knows c that this will work. It doesn't mean we'd write code like that...

jbuzbee2• 14 years ago

Yeah :-) I didn't say I would -write- code like that. I only meant it looked like a lot of code I've run into over the years!

cube133• 14 years ago

It's been a while since I've done this(usually by accident), but I believe that GCC and Visual Studio both throw up a warning along the lines of "Type not defined, assuming int".

Ogre• 14 years ago

I see questions online all the time that make me wonder just how old the compiler being used is. Modern versions of GCC, Clang and Visual Studio all have warnings enabled by default for an awful lot of valid, but probably wrong, code. Apparently people learning to code are somehow winding up on old compilers much more often than those of us who have been writing C and C++ for a long time.

Or, I guess, the people having problems learning to code are the people who happen to be on ancient compilers. Maybe it's not so surprising after all.

rnadna• 14 years ago

Me too. And I didn't realize that made me old, until scanning this thread. I guess time flies.

kelnos7• 14 years ago

Hah, yeah. I looked at it and thought, "well, I'd kick someone for writing code like that nowadays, but looks perfectly valid to me."

(And I'm not even that old! I've only been writing C for 12 years or so!)

minimax2• 14 years ago

C++ programmers will be familiar with a related (and probably more commonplace) problem:

  struct Foo {int a;};

  int main(int argc, char **argv) {
      Foo foo();
      foo.a = 42;
      return 0;
  }

Looks ok, right? Wrong.

  error: request for member 'a' in 'foo', which is of non-class type 'Foo()'

hnriot2• 14 years ago

no, it doesn't look ok. You need to remove the () in your declaration. You need to take a look at how constructors work in c++

Dylan16807• 14 years ago

>you need to take a look

I think you missed the point of the post.

http://en.wikipedia.org/wiki/Most_vexing_parse

cube133• 14 years ago

foo()-with the parenthesis- is a function. foo-without the parenthesis-is a variable. That means that:

  Foo foo();

is a function pointer declaration within the scope of the main function. Since it's a function, which does not have member types, a is not within the scope of Foo().

Now, if there was a 0 argument constructor for struct Foo, this would be valid:

Foo foo = Foo();

kelnos7• 14 years ago

Function declaration, not function pointer declaration. The latter would be

    Foo (*foo)();

jfaucett• 14 years ago

this is pretty basic, I would hope no actual c programmers would ask this question. Compilers are fun aren't they, how bout this one:

  #include <stdio.h>
  #define yell(i,l,o,v,e,u) o##v##i##l
  #define billy_bob yell(i,n,m,a,t,e)

  billy_bob() 
  {
    printf("no main in da house!");
  }

ntumlin• 14 years ago

Would you please explain the code?

kevinnk• 14 years ago

>#include <stdio.h>

>#define yell(i,l,o,v,e,u) o##v##i##l

defines a macro called yell. The preprocessor operator ## concatenates it's operands together so something like ma##in gets transformed into main.

>#define billy_bob yell(i,n,m,a,t,e)

defines a macro called billy_bob that simply expands to the macro yell. When we call yell with the given arguments we get m##a##i##n (look at the order of the arguments for yell) which gets transformed into main.

>billy_bob()

Expanding the macro turns this line into main().

> printf("no main in da house!");

So now we've declared a main function that just prints "no main in da house!".

dubya• 14 years ago

Hint: the 't' and 'e' in yell(i,n,m,a,t,e) are irrelevant.

cnvogel• 14 years ago

There's the "##" operator with which you can glue together identifiers with the preprocessor.

  #define yell(i,l,o,v,e,u) o##v##i##l
  yell(i,l,o,v,e,u) will turn into the identifier ovil.

And billy_bot just uses the yell-macro to produce a "main" identifier.

  #define billy_bob yell(i,n,m,a,t,e)

  yell(i,l,o,v,e,u) --> o ## v ## i ## l
  yell(i,n,m,a,t,e) --> m ## a ## i ## n

So billy_bop is main.

Why is this features useful at all? When you actually want to programmatically create function names, type names, struct names in preprocessor generated code.

     #define ENCAPS_STRUCT(type,name)  struct encaps_##type { type name; }
     ENCAPS_STRUCT(int,a);

will generate...

     $ cc -E test.c
     # 1 "test.c"
     # 1 "<built-in>"
     # 1 "<command-line>"
     # 1 "test.c"

     struct encaps_int { int a; };

habosa• 14 years ago

Ok what in the world does that do?

marssaxman• 14 years ago

It's just a fancy way of assembling the identifier "main" without writing it explicitly. Inside a preprocessor macro definition, the double hash mark is an operator which concatenates its left and right operands. This is a lexical operation. The "yell" macro takes six arguments and returns the concatenation of arguments 2, 3, 0, and 1, ignoring 4 and 5.

The billy_bob macro calls the yell macro, passing in some letters - if you look at which letters from "i,n,m,a,t,e" end up attached to which arguments in "yell", you'll see that "yell' rearranges 'i,n,m,a' to spell the word "main".

whatshisface• 14 years ago

I'm going to take a guess at this... the macros compile down to #define billy_bob main?

Let's see... yell() takes six 'bare' strings and appends four of them together in a certain order while ignoring the other two. This turns (i,n,m,a,t,e) into (m,a,i,n). The second define sets billy_bob as the output of yell.

I don't know C very well, is this correct?

jfb• 14 years ago

That's exactly right.

npsimons2• 14 years ago

See, this is why I like HN. The discussion here is more interesting than the OP (which is, indeed, a very basic question that a little bit of research into the history of C would answer). I thought I knew about preprocessor magic (including stringification and variadic macros), but I'm glad to have run across this post (and the ensuing discussion) as I've learned something very useful from it (eg, how to construct more dynamic code in C/C++).

BadDesign• 14 years ago

I think you mean preprocessors.

kelnos7• 14 years ago

To be pedantic, that's just preprocessor abuse... nothing really to do with the compiler proper.

bitwize• 14 years ago

An empty parameter list in a C prototype means "parameters are unspecified".

In C++ it means no parameters.

To declare a C function parameterless you need to say int func(void).

Also, C will assume int if you leave off param or return types.

...I'm surprised I know that.

bjoe_lewis• 14 years ago

Is it a bad code, or otherwise?

johnbellone• 14 years ago

I would say that it is ambiguous code.

The first C project that I worked on used this a lot. Its definitely not the easiest to understand when coming from a C++ background (because no parameter declaration means no parameters) or from other descendant languages.

kelnos7• 14 years ago

It's actually not ambiguous code at all. It's perfectly well-formed and unambiguous with respect to the C standard.

What it is, however, is hard-to-read and -maintain code.

debacle• 14 years ago

It's an older code, but it checks out.

klibertp• 14 years ago

It is a bad code.

It was quite ok.

This is another proof that as programmers we need to learn and improve constantly :)

jussij• 14 years ago

I think it's a case of not having the compiler warning level set to it's highest level (which it should be) or the bad habit of some programmer's ignoring warning messages.

Yoni1• 14 years ago

This is kind of an encouraging question. To me it screams "people don't know C anymore, capitalize on your skill while you still can".

spudlyo• 14 years ago

    /* Pentium killer */
    long main = 0xc8c70ff0;

TeMPOraL• 14 years ago

That's why I always tell people that gcc is mostly useless without --ansi --pedantic -Wall.

Why does this C program compile?

Related Stories