6 ms·

http://www.avabodh.com/cin/programstructure.html http://www.avabodh.com/cin/programstructure.html ... void main() ... That's where I stopped readi

by _kst_ 6y ago

http://www.avabodh.com/cin/programstructure.html http://www.avabodh.com/cin/programstructure.html ... void main() ... That's where I stopped reading. Since this comment is getting downvotes, I'll explain. The "void" keyword was introduced in the 1989 ANSI C standard. That same standard specified that the valid definitions for the main functions are: int main(void) { /* ... */ } and int main(int argc, char *argv[]) { /* ... */ } or equivalent (or implementations can support other forms). There has never been a version of C in which "void main()" is a valid way to define the main function. It's a small detail, and yes, many compilers will let you get away with it (the language doesn't require a diagnostic), but anyone writing about C should be aware of this, and should set a good example by writing correct code. Maybe the site is OK other than that, but it doesn't inspire confidence.

DoingIsLearning 6y ago
Just for some context, the standard specifies an int return type for the purpose of returning a meaningful value back to a hosting operating system. However, in the specific context of stand-alone or freestanding programs, the "void main()" definition would be absolutely nonconsequential, since there is no host to return a value to.
- tom_mellior 6y ago
  > However, in the specific context of stand-alone or freestanding programs, the "void main()" definition would be absolutely nonconsequential One possible consequence I can think of: If your program is safety-critical (or even otherwise) you might be interested in running static analysis or verification tools on it. These tools implement the C standard, so they would emit a diagnostic on the use of void main. Other than that, sure, the language police will not come and break down your door. If your compiler's docs say that it accepts this construct with the meaning you want, it is indeed an inconsequential, though also completely unnecessary, deviation from the standard.
- _kst_ 6y ago
  For a freestanding implementation, the program entry point is entirely implementation-defined. It may or may not be called "main". In that kind of environment, "void main()" (or, better, "void main(void)") might be correct. You need to read the implementation's documentation. For hosted implementations, "void main()" might be valid, but "int main(void)" is always valid. A tutorial should not suggest "void main()" without mentioning any of this. Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf sections 5.1.2.1 (freestanding environments) and 5.1.2.2.1 (hosted environments).
Y_Y 6y ago
It's legal to declare main as returning an int, And then not return any value, but it's not legal to declare it as not returning any value? I agree that in many contexts it's useful and important to have a good return value, but to be honest, I almost never end up doing it in my own programs.
- fanf2 6y ago
  The declared return type affects the calling convention, and if you get it wrong weird things can happen even if the function does not return.
  - Y_Y 6y ago
    It would be cool if someone could give an example of this behaviour.
    - fanf2 6y ago
      Consider a hypothetical flavour of the Deathstation 9000 architecture in which the ABI uses call-by-reference for return values, and for void functions there is no return value argument. If you get the declaration wrong, the arguments will be placed in the wrong registers. These kinds of problems might not happen with common ABIs, but if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption.
      - badsectoracula 6y ago
        > if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption. Which is really a bug that everyone has decided to look the other way around because it wins compiler benchmarks despite coming against what C originally was meant for. Specifically (from the C89 rationale[0], that i'm certain most people who think those benchmarks are good haven't read): > C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§1.7). Also in the same rationale it mentions how "the spirit of C" is to do operations in the way the machine would do it instead of forcing some abstract rule - yet that exactly is what happens later when everyone goes all language lawyer about C's abstract machine and how you should not rely on what you think the target machine would do. [0] http://www.lysator.liu.se/c/rat/a.html#1-1 http://www.lysator.liu.se/c/rat/a.html#1-1
boblivion 6y ago
Which is funny because the void keyword specifies that the function receives no arguments. Otherwise you could call it with any amount of arguments you want. However, the linker doesn't care about type-signatures, so in the end this main function still gets called with argc, argv, envp.
- _kst_ 6y ago
  The "any amount of arguments you want" applies to C function call. The mechanism for invoking your "main" function might use a different mechanism. The C standard specifies (for hosted implementations) two ways to define "main", and allows implementations to document and support more. "int main(void)" is one of them. "int main()" is not. So, strictly speaking, using "int main()" makes your program's behavior undefined. On the other hand, as far as I know every implementation actually allows "int main()" with no problem. This was necessary to support pre-ANSI C code, which couldn't use the "void" keyword. It's still better to be explicit and use "int main(void)" rather than "int main()". (It can also affect recursive calls to main, which are legal but almost certainly a bad idea.)
- pjmlp 6y ago
  Which is why C++ makes use of name mangling, to achieve link time safety like in Mesa / Modula-2 derived languages, while relying on primitive UNIX linkers built for C semantics.
fanf2 6y ago
The void keyword predates ANSI C by several years. It was introduced in pcc in the early 1980s during the effort to improve the portability of Unix, which included improving the type safety of C. Steve Johnson, author of pcc and lint, recently wrote about the origin of void - https://minnie.tuhs.org/pipermail/tuhs/2020-May/021034.html https://minnie.tuhs.org/pipermail/tuhs/2020-May/021034.html
- _kst_ 6y ago
  Good point. "void" does not appear in K&R1 (1978), and there was no definitive manual for the language between that and the ANSI standard, but it did start appearing in implementations. Still, I'm not aware of any implementation that explicitly supported void as the return type of main. (Many compilers would accept just about any return type without complaint.) Somehow some authors got the idea that "void main()" was a good idea. I find it to be a good way to detect authors who don't know the language very well.
MaxBarraclough 6y ago
According to [0], it's legal to use a void return type, but the value returned to the host environment is unspecified. Whereas if you use an int return type and allow control to reach the closing brace of the main function, it's as if you put return 0; (as of C99) It seems like a bad idea to use void return type (presumably you want the program to always return 0), but the standard permits it. edit Wikipedia seems less convinced that it's ok [1] [0] https://en.cppreference.com/w/c/language/main_function https://en.cppreference.com/w/c/language/main_function [1] https://en.wikipedia.org/wiki/Entry_point#C_and_C++ https://en.wikipedia.org/wiki/Entry_point#C_and_C++
- scatters 6y ago
  It's legal if implementation-specified. The clause you're looking at says how implementations that add extra signatures for main are required to map the return value (if any) to an exit status. You can't just make up extra signatures for main and expect your compiler to deal with them. Of course, if your compiler vendor says that a particular non-standard signature is available, you're free to use it.
  - throwaway894345 6y ago
    Man, I don't miss the amount of spec lawyering that exists in C. All of these pedantic details that don't contribute a single lick to writing software...
    - _kst_ 6y ago
      All those "pedantic details" let you know how you can write code that a future version of your compiler won't quietly break.
      - throwaway894345 6y ago
        You missed the obvious point: other languages don’t allow you to write code that will break in future versions (obviously provided that the spec doesn’t change in a breaking way, but this is the same for C). The compiler is your lawyer.
ken 6y ago
This sounds like pointless nitpicking. Has there ever been any real C compiler on any OS (not the DeathStation 9000) where this distinction has caused any issue? FWIW, I learned "ANSI C" from a book older than 1989. I've written C programs that ran on 8-bit to 64-bit machines, big- and little-endian, on a dozen OSs (most of which no longer exist), and even no OS. I've never even heard of this being a problem.
commandlinefan 6y ago
You got further than me - I gave up after “for writing softwares” and then “which can directly be run by CPU”.
doomjunky 6y ago
Where did the author commit to a certain standard? Maybe the author knows all of this but isn't -Wpedantic. Please don't jump to conclusions and assume worst.

by _kst_ 6y ago

DoingIsLearning 6y ago

Just for some context, the standard specifies an int return type for the purpose of returning a meaningful value back to a hosting operating system. However, in the specific context of stand-alone or freestanding programs, the "void main()" definition would be absolutely nonconsequential, since there is no host to return a value to.

tom_mellior 6y ago
> However, in the specific context of stand-alone or freestanding programs, the "void main()" definition would be absolutely nonconsequential One possible consequence I can think of: If your program is safety-critical (or even otherwise) you might be interested in running static analysis or verification tools on it. These tools implement the C standard, so they would emit a diagnostic on the use of void main. Other than that, sure, the language police will not come and break down your door. If your compiler's docs say that it accepts this construct with the meaning you want, it is indeed an inconsequential, though also completely unnecessary, deviation from the standard.
_kst_ 6y ago
For a freestanding implementation, the program entry point is entirely implementation-defined. It may or may not be called "main". In that kind of environment, "void main()" (or, better, "void main(void)") might be correct. You need to read the implementation's documentation. For hosted implementations, "void main()" might be valid, but "int main(void)" is always valid. A tutorial should not suggest "void main()" without mentioning any of this. Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf sections 5.1.2.1 (freestanding environments) and 5.1.2.2.1 (hosted environments).

Y_Y 6y ago

It's legal to declare main as returning an int, And then not return any value, but it's not legal to declare it as not returning any value? I agree that in many contexts it's useful and important to have a good return value, but to be honest, I almost never end up doing it in my own programs.

fanf2 6y ago
The declared return type affects the calling convention, and if you get it wrong weird things can happen even if the function does not return.
- Y_Y 6y ago
  It would be cool if someone could give an example of this behaviour.
  - fanf2 6y ago
    Consider a hypothetical flavour of the Deathstation 9000 architecture in which the ABI uses call-by-reference for return values, and for void functions there is no return value argument. If you get the declaration wrong, the arguments will be placed in the wrong registers. These kinds of problems might not happen with common ABIs, but if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption.
    - badsectoracula 6y ago
      > if you try to write C on the assumption that it will be compiled in a reasonable way based on your knowledge of how the plaform works, then modern compilers will punish you for your presumption. Which is really a bug that everyone has decided to look the other way around because it wins compiler benchmarks despite coming against what C originally was meant for. Specifically (from the C89 rationale[0], that i'm certain most people who think those benchmarks are good haven't read): > C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§1.7). Also in the same rationale it mentions how "the spirit of C" is to do operations in the way the machine would do it instead of forcing some abstract rule - yet that exactly is what happens later when everyone goes all language lawyer about C's abstract machine and how you should not rely on what you think the target machine would do. [0] http://www.lysator.liu.se/c/rat/a.html#1-1 http://www.lysator.liu.se/c/rat/a.html#1-1

boblivion 6y ago

Which is funny because the void keyword specifies that the function receives no arguments. Otherwise you could call it with any amount of arguments you want. However, the linker doesn't care about type-signatures, so in the end this main function still gets called with argc, argv, envp.

_kst_ 6y ago
The "any amount of arguments you want" applies to C function call. The mechanism for invoking your "main" function might use a different mechanism. The C standard specifies (for hosted implementations) two ways to define "main", and allows implementations to document and support more. "int main(void)" is one of them. "int main()" is not. So, strictly speaking, using "int main()" makes your program's behavior undefined. On the other hand, as far as I know every implementation actually allows "int main()" with no problem. This was necessary to support pre-ANSI C code, which couldn't use the "void" keyword. It's still better to be explicit and use "int main(void)" rather than "int main()". (It can also affect recursive calls to main, which are legal but almost certainly a bad idea.)
pjmlp 6y ago
Which is why C++ makes use of name mangling, to achieve link time safety like in Mesa / Modula-2 derived languages, while relying on primitive UNIX linkers built for C semantics.

fanf2 6y ago

The void keyword predates ANSI C by several years. It was introduced in pcc in the early 1980s during the effort to improve the portability of Unix, which included improving the type safety of C. Steve Johnson, author of pcc and lint, recently wrote about the origin of void - https://minnie.tuhs.org/pipermail/tuhs/2020-May/021034.html https://minnie.tuhs.org/pipermail/tuhs/2020-May/021034.html

_kst_ 6y ago
Good point. "void" does not appear in K&R1 (1978), and there was no definitive manual for the language between that and the ANSI standard, but it did start appearing in implementations. Still, I'm not aware of any implementation that explicitly supported void as the return type of main. (Many compilers would accept just about any return type without complaint.) Somehow some authors got the idea that "void main()" was a good idea. I find it to be a good way to detect authors who don't know the language very well.

MaxBarraclough 6y ago

According to [0], it's legal to use a void return type, but the value returned to the host environment is unspecified. Whereas if you use an int return type and allow control to reach the closing brace of the main function, it's as if you put return 0; (as of C99) It seems like a bad idea to use void return type (presumably you want the program to always return 0), but the standard permits it. edit Wikipedia seems less convinced that it's ok [1] [0] https://en.cppreference.com/w/c/language/main_function https://en.cppreference.com/w/c/language/main_function [1] https://en.wikipedia.org/wiki/Entry_point#C_and_C++ https://en.wikipedia.org/wiki/Entry_point#C_and_C++

scatters 6y ago
It's legal if implementation-specified. The clause you're looking at says how implementations that add extra signatures for main are required to map the return value (if any) to an exit status. You can't just make up extra signatures for main and expect your compiler to deal with them. Of course, if your compiler vendor says that a particular non-standard signature is available, you're free to use it.
- throwaway894345 6y ago
  Man, I don't miss the amount of spec lawyering that exists in C. All of these pedantic details that don't contribute a single lick to writing software...
  - _kst_ 6y ago
    All those "pedantic details" let you know how you can write code that a future version of your compiler won't quietly break.
    - throwaway894345 6y ago
      You missed the obvious point: other languages don’t allow you to write code that will break in future versions (obviously provided that the spec doesn’t change in a breaking way, but this is the same for C). The compiler is your lawyer.

ken 6y ago

This sounds like pointless nitpicking. Has there ever been any real C compiler on any OS (not the DeathStation 9000) where this distinction has caused any issue? FWIW, I learned "ANSI C" from a book older than 1989. I've written C programs that ran on 8-bit to 64-bit machines, big- and little-endian, on a dozen OSs (most of which no longer exist), and even no OS. I've never even heard of this being a problem.

commandlinefan 6y ago

You got further than me - I gave up after “for writing softwares” and then “which can directly be run by CPU”.

doomjunky 6y ago

Where did the author commit to a certain standard? Maybe the author knows all of this but isn't -Wpedantic. Please don't jump to conclusions and assume worst.