Re: print "foo" without using ;


In article <430fc460$0$82713$892e0abb@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Thad Smith <ThadSmith@xxxxxxx> writes:
> Fao, Sean wrote:
>
> > Mostly off-topic, but perhaps surprising is the fact that Microsoft
> > actually accepts void as a valid return type.
>
> 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.

It's not a matter for the OS, but one for the implementation. An
implementation which runs on top of an OS might disallow "void main"
as an alternative, non-standard form because of some issue with that
OS, but there are certainly other possibilities. For example, an
implementation might disallow it because its authors wish to enforce
explicitly returning a valid status.

I'm curious to know how you determined that "calling convention"
(which is not covered by the standard) is the "main reason" for
disallowing alternative forms of main.

> 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.

In what sense? The standard certainly makes calling a function
incorrectly - ie, with an incorrect prototype in scope, or without
a prototype in scope if the function is not declared in a manner
compatible with a non-prototyped function - an error, which sounds
like "incompatible" to me.

> Of course, such calling compatibility isn't guaranteed,

If the standard doesn't guarantee compatibility, then it makes it
incompatible. There is no middle. "Happens to work" is a possible
result of undefined behavior; it doesn't demonstrate anything about
either the intentions or requirements of the standard.

> What
> implementations are you familiar with in which the calling convention
> for a void function and an int function are different?

EPM C for the AS/400, for one.

> I am not aware of any.

Anecdotal evidence, as always, demonstrates nothing about the C
language.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

When [Columbus] landed on America it was more like an evasion than a
discovery. -- Matt Walsh
.

Relevant Pages

  • 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)
  • Re: print "foo" without using ;
    ... 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. ...
    (comp.lang.c)
  • Re: return codes for void main() blocks
    ... used in a monadic form? ... SetCurrentDirectoryin the finally block to restore the original calling ... void main ... int DoMain(char argc, char *argv) ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Inconsistent Program Results
    ... including one of them might trivially slow down compilation, ... I wrote the above (starting with "The standard headers"). ... return void, but there's no advantage in using that. ... You're cheating yourself by ignoring warning messages. ...
    (comp.lang.c)