Re: print "foo" without using ;

Thad Smith wrote: 
Fao, Sean wrote:

Mostly off-topic, but perhaps surprising is the fact that Microsoft actually accepts void as a valid return type.

http://msdn.microsoft.com./library/default.asp?url=/library/en-us/vclang98/HTML/_pluslang_program_startup.3a_.the_main_function.asp



Not surprising here. The main reason that an OS (or other calling environment) wouldn't accept a void function, rather than an function returning int is that the calling convention is incompatible. Since C evolved from K&R, which didn't have void types, and therefore used default int type functions. When ANSI C was being developed and a void type added, implementors wisely did not make calling void functions incompatible with calling an int function. Of course, such calling compatibility isn't guaranteed, but happens most of the time. What implementations are you familiar with in which the calling convention for a void function and an int function are different? I am not aware of any.

Thad

Utter nonsense. How can you possibly offer such trash in the group where you know the masters live.

1. There is no term 'calling environment' in common parlance.
2. The term 'calling convention' is commonly used but you obviously don't know what it means (look it up).
3. As of C89 we are allowed to declare and define generic functions of type void. Nothing to do with calling convention.

The function main() is NOT a generic. It is the real name of your C program. It is called by the command shell and has a 'value' of type int. Not void, int! This was decided among Ken Thompson and Dennis Ritchie circa 1972, three years before Bill, 19 years old in 1975 started Microsoft.

K&R (1978), C89 and C99 all define main() with type int.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---
.

Relevant Pages

  • Re: print "foo" without using ;
    ... >>> actually accepts void as a valid return type. ... The main reason that an OS (or other calling ... and therefore used default int type functions. ... Of course, such calling compatibility isn't guaranteed, ...
    (comp.lang.c)
  • Re: Stack prob. Setting callback in native dll.
    ... static void dllSetCallFp(void (*aFp)); ... The problem is I can debug into the calling of MFun but when I return I ... with a different calling convention. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Stack prob. Setting callback in native dll.
    ... delegate(i.e., modopt) using ildasm ... static void dllSetCallFp(void (*aFp)); ... The problem is I can debug into the calling of MFun but when I return I ... with a different calling convention. ...
    (microsoft.public.dotnet.framework.interop)
  • calling a function in c++
    ... Meaning, In a class, A function X calling onto a function Y, and function ... void sec_to_hours; ... {int seconds1, seconds2, hours, minutes, seconds; ... cin>> seconds; ...
    (alt.comp.lang.learn.c-cpp)
  • calling a function in cpp
    ... Meaning, In a class, A function X calling onto a function Y, and function ... void sec_to_hours; ... {int seconds1, seconds2, hours, minutes, seconds; ... cin>> seconds; ...
    (comp.lang.cpp)