int main = 0, is compiled but crashed

Part of the explanation for changes between compilers is that the constraints on main have changed between C++ standards.

C++98 (section 3.6 para 3) says

The function main shall not be used (3.2) within a program. The linkage (3.5) of main is implementation-defined. A program that declares main to be inline or static is ill-formed. The name main is not otherwise reserved.

C++11 says essentially the same thing - except it removes the reference to Section 3.2 and also disallows main being constexpr (consistent with the fact that C++11 introduced constexpr).

From this, I would suggest that - before C++11 - compiler implementers had plenty of freedom about what to do if code defined a variable at file scope named main. Practically, I'm inclined to further suggest they may not have thought about that particular case at all but - if queried on a program compiling and crashing - they could probably make a claim of undefined behaviour. One type of undefined behaviour occurs when the standard simply doesn't constrain what happens.

C++17, moves the discussion of the main function to Section 6.6.1. In para 3 of that section it says (bold highlighting mine, of text that was not in an earlier standard)

The function main shall not be used within a program. The linkage (6.5) of main is implementation-defined. A program that defines main as deleted or that declares main to be inline, static, or constexpr is ill-formed. The main function shall not be declared with a linkage-specification (10.5). A program that declares a variable main at global scope or that declares the name main with C language linkage (in any namespace) is ill-formed. The name main is not otherwise reserved.

From C++17, defining a variable at file scope named main at file scope therefore makes a program ill-formed - which then means an implementation may diagnose an error.

For C, using main as a variable is undefined and can be caught through syntax, so all compilers should diagnose this. C17 says

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters: ... etc

and then come the two possible prototypes for main as a function.

The shall here is important, it makes it explicitly undefined to use the identifier main differently.

There are two slightly different questions here:

1. Why is int main = 0; wrong?

2. If int main = 0; is wrong, why do different compilers treat it differently?

Before answering either question, it's worth making an oft-repeated analogy: A Programming Standard (like that for C or C++) is a lot like a contract between you, the programmer, and the programmers who wrote the compiler you're using. If you follow all the rules in the contract when you write your program, and if the compiler writers followed all the rules when they wrote your compiler, everything should work fine. But if any rules get broken on either side, things go wrong.

Now, most of the rules in a programming language contract are sort of conditional: If you want to add two numbers, the operator you use is +. You don't get to decide you want to use the keyword add; the language says you use the symbol +, and that's that.

Some of the rules in a programming language contract are absolute, and negative, in that they tell you what you must not do. You must not add a pointer and a floating-point value.

But there are a very few rules — I can really only think of one — that are absolute and positive, in that they tell you what you must do, whether you want to or not. The one rule I can think of concerns the entry point of your program. You must have an entry point function, its main must be main, its return value must be int, and it must accept either zero parameters, or two: one of type int and one of type char **. (You do get to pick your own names for those parameters, although it's conventional to name them argc and argv.)

So when you wrote

int main = 0; 

you broke that rule, albeit in an unusual way: you did have something named main, but it was an integer, not a function.

If this is still perplexing to you, consider this example. Suppose you write a file main.c containing:

#include <stdio.h> extern int f(); int main() { printf("About to call function f() ...\n"); f(); printf("back from function f().\n"); } 

You've got a very simple main function, calling a function f which is presumably defined in a separate source file. And suppose you do create that separate source file, f.c, containing

char f[] = "Hello, world!"; 

Obviously there's a pretty gross mismatch here between how you externally declared f in main.c, and how you actually defined it in f.c.

But if you compile main.c and f.c using a C compiler, and link the resulting object files together with a conventional linker, it's likely to give no errors. (I tried it just now, and got none.) But it crashes when it runs, for the obvious reason.

The question of whether a compiler might actually complain about the "gross mismatch" depends on a number of things. Traditionally, C compilers were very generic about the code they compiled, meaning that no names were special. If you declared something named main that's improperly an array instead of a function, typically the compiler wouldn't notice. And by the time you're linking together separately-compiled object files, all the linker knows about (again, based on traditional object file formats) is that there's something at an address identified by the identifier main; the linker has no way of knowing the stuff at main isn't properly-compiled machine language code corresponding to a callable function.

More recently, compilers have begun making use of the guarantees afforded them by the Standard, and "learning" abut Standard-imposed identifiers, including main. And indeed two different modern compilers I tried complained "variable named 'main' with external linkage has undefined behavior".

And when it comes to C++, things get more complicated still. Typically, the linker does not just know that "there's something at an address identified by an identifier", typically there's extra information (if only via "mangled names") by which the linker can tell the difference between an identifier identifying a blob of memory containing some data, versus an identifier identifying a blob of memory containing some compiled machine instructions.