There are some very experienced folks on Stack Overflow who always talk about the C standard. People seem to not like non-portable solutions, even if they work for me. Ok, I understand that the standard needs to be followed, but doesn't it put shackles on programmer's creativity?
What are the concrete benefits that come from following a standard? Especially since compilers may implement the standard slightly differently.
There are a few reasons why sticking to the standard is a good thing.
Being locked into a compiler sucks hard. You're completely at the mercy of a group of developers with their own agenda. They're obviously not out to get you or anything, but if your compiler starts lagging on optimizations, new features, security fixes etc, too bad; You're stuck. In extreme cases some companies have to start patching whatever tool they have made themselves dependent on. This is a huge waste of money and time when there are other working tools out there.
Being locked into a platform sucks harder. If you're pushing software on Linux and and want to switch to Windows because you realize your market is really there, you're gonna have a heck of a time changing every non-portable hack you've got in your code to play nice with both GCC and MSVC. If you've got several pieces of your core design based around something like that, good luck!
Backward incompatible changes sucks the hardest. The standard will never break your code (Ignore python). Some random compiler writer though might decide that really this implementation specific add-on is not worth the trouble and drop it. If you happen to rely on it, then you're stuck on whatever old outdated version it was last in.
So the overriding message here, sticking to the standard makes you more flexible. You have a more limited language sure, but you have more
It's a delicate balance, but completely ignoring the standard is definitely a mistake. I tend to organize my C code to rely on abstractions that might be implemented in a non-portable way, but that I can transparently port without changing everything that depends on the abstraction.
The standard is a sort of "contract" between you and your compiler that defines the meaning of your programs. As programmers, we often have a certain mental model of how the language works, and this mental model is often at odds with the standard. (For example, C programmers often think of a pointer as roughly "an integer that denotes a memory address", and therefore assume that it's safe to perform any arithmetic/conversions/manipulations on pointers that one might perform with an integer that denotes a memory address. This assumption does not agree with the standard; it actually imposes very strict restrictions on what you can do with pointers.)
So, what's the advantage of following the standard, rather than your own mental model?
Simply put, it's that the standard is correct, and your own mental model is wrong. Your mental model is typically a simplified view of how things work on your own system, in common cases, with all compiler optimizations disabled; compiler vendors do not generally make an effort to conform to it, especially when it comes to optimizations. (If you don't hold up your end of the contract, you can't expect any specific behavior from the compiler: garbage in, garbage out.)
People seem to not like non-portable solutions, even if they work for me.
It might be better to say, "even if they seem to work for me". Unless your compiler specifically documents that a given behavior will work (that is: unless you're using an enriched standard, consisting of the standard proper plus compiler documentation), you don't know that it really works, or that it's really reliable. For example, signed integer overflow typically results in wrapping on many systems (so, INT_MAX+1 is typically INT_MIN) — except that compilers "know" that signed integer arithmetic never overflows in a (correct) C program, and often perform very surprising optimizations based on this "knowledge".
I understand that the standard needs to be followed , but doesn't it put shackles on programmer's creativity? there are still some differences in the way different compilers follow the standards. I can for example write a code which works, very good in performance and speed i.e, all that matters, but still that may not necessarily strictly follow the standards.
No. The standard tells what is allowed to do. If it is not specified, you are in undefined behaviour territory, and then all bets are off - the program is free to do anything.
Since you mentioned specific example of void main() vs int main(), I can improve my answer.
void main() is not a standard declaration of the main function. It may work on some compilers through extensions, but it rely on the implementation. Even if it works, you have to check if it does what you want. The problem is, compiler developers may decide to remove void main() with next compiler release, breaking your application.
On the other hand, the standard clearly defines the signature of main as int main() and it tells what it should do.
On the other hand, there are things not defined in the standard. Then, another standard may apply (like for example, POSIX). The best example may be with threads implementation in c++03, since c++03 standard programs were 1-threaded. In that case, you are forced to use platform dependent library, or something like boost.
Don't follow rules IF your project is about special projects, for example a gov project or army one, but you need to follow rules IF you are talking about an open source or large project with a distributed team.
