Re: Alternate declarations for main

On Jul 13, 8:06 pm, kuyper <kuy...@xxxxxxxxxx> wrote:
Rajesh S R wrote:
On Jul 12, 11:08 pm, Keith Thompson <ks...@xxxxxxx> wrote:
Rajesh S R <SRRajesh1...@xxxxxxxxx> writes:
...
In particular, over in comp.lang.c, the existence of the phrase "or in some other implementation-defined
manner" has made it more difficult for us to tell newbies to stop
using 'void main(void)'. We can't just tell them it's illegal,
because it isn't.

But that can't be called a "confusion". You need to tell them
(newbies) that the codes that use void main(void) is not documented by
the standards and so it isn't portable. ...

The confusion stems from the fact that the standard actually mentions
this kind of extension, implicitly seeming to endorse it, which was
precisely the goal of the political pressure that was exerted to make
this compromise.

Ok ,this is a "consequence". But what is the "confusion" here?


... And I think that newbies won't
ask you, why his code needs to be portable. Because the reasons are
obvious!

There are, unfortunately, a great many people who do not find those
reasons obvious.

Things would be much simpler if any declaration for main other than
the two standard ones were a constraint violation.

I don't like this proposal. What do you say for implementations, that
document int main(int argc, char **argv, char **env);?
Your proposal will oblige an implementation to produce a diagnostic
even if that declaration is documentd by the compiler! That will be
very ugly.

Use of a non-standard interface should be ugly.

No, It should not be, because that will confine a language to very
limited applications.
The purpose of standardisation is to have portable codes not to
discourage writing non-portable useful code.


...

I don't see any reason to make void main(void) deprecated or rendering
it a constraint violation.
Is there anything bad with the void main(void), if it is documented by
the implementation?

Yes. People might use it, incorrectly thinking it's a reasonable thing
to do, despite the fact the documentation would probably have a
footnote or something indicating that it's non-portable. Other people
will copy their code without even seeing that footnote.


Well, that is ignorance. I don't see any reason for explicitly
removing void main(void) just because some people are not aware that
these are non-portable.


...

... And any person
who uses an extension is already aware that his code is non-portable.

That's a pretty optimistic assumption.

All your statements in favor of removing void main(void) applies to
all the extensions supported by an implementation. You can't develop a
real-time application, in most cases, without using these extensions.
Therefore will you say that all "extension usage" by a code should be
a constraint violation, requiring diagnostic?



.

Relevant Pages

  • Re: help w/ c/c++ problem
    ... I'll admit to it when the persons who spent several hundred posts ... standard explicitly allows ... 'void main', then a program that uses 'void main' is valid ... reasons not to, ...
    (comp.lang.c)
  • Re: help w/ c/c++ problem
    ... I'll admit to it when the persons who spent several hundred posts ... standard explicitly allows ... 'void main', then a program that uses 'void main' is valid ... reasons not to, ...
    (comp.lang.c)
  • Re: C Program [ Turbo-C ] , to extract only-Printable-characters from a file ( any type
    ... So C99 formalises the idea that aform of mainis valid on an ... > implementation documents it as an extension. ... OK I see an argument that the bit from C99 above legitimises ... > void mainand in my book that makes void mainan invalid ...
    (comp.lang.c)
  • simple isapi extension : memory leak detected
    ... extension was coming from, so I built a super simple MFC isapi with the ... unloaded (there's always 4 reported leaks). ... void CtestIsapiExtension::emptyTest(CHttpServerContext* pCtxt) ...
    (microsoft.public.inetserver.iis)
  • Re: Question about void pointers
    ... got to switch to char * so that it can be incremented properly. ... You have two options, do it portably, or do it with an extension, with ... perhaps the OP doesn't need portability (or at least not this ... void * seems more natural for this kind ...
    (comp.lang.c)