Topic: main [was: Enforcing virtual destructors]


Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1997/04/17
Raw View
Michael Hudson <sorry.no.email@nowhere.com> writes:

|>  Fergus Henderson wrote:
|>  > James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>  > >One question: does the "shall" mean that the implementation is
|>  > >required to give a diagnostic if I write "void main()", or that the
|>  > >results of writing "void main()" or undefined behavior (which the
|>  > >implementation is free to define)?
|>  >
|>  > Since this is a requirement on the form of the program, not on its
|>  > behaviour, the implementation is required to give a diagnostic.

Really.  The restriction forbidding double underscores is also a
requirement on the form of the program, and last time I looked (many
drafts ago, I'll admit), it was undefined behavior.

|>  But that's very silly.
|>  On some (many?) systems, including the MacOS where I do my coding, the
|>  return value from main is of no significance, so I type
|>  void main() { ... }

The problem is that the return value *does* have a significance, at
least within the C++ implementation.  The semantics of returning from
main are those of calling exit; returning from a "void main" would thus
be the same as calling exit with an undefined (uninitialized) value.

This signification is, of course, limited to the C++ implementation;
what exit does with this value, and what the OS does with it if exit
passes it on, is completely implementation dependant.

|>  If this generated a warning, I'd get into the habit of not reading the
|>  warnings my compiler prooduces, which is not a good habit.
|>  What I'm saying is, to hell with sticking to the absolute letter of the
|>  standard, common sense has to kick in somewhere.

What, may I ask, is the problem with declaring it to return an int, and
returning 0?  Or even returning EXIT_SUCCESS or EXIT_FAILURE, according
to circomstances.

Most of the programs I work on run "forever;" they contain an infinite
loop (with a socket read in the loop).  So one could argue that having
to declare a return value for a function wich never returns (main) is a
bit silly.  All I can say is that it has never bothered me.  (Since the
end of main is protected by an abort(), I don't generally even worry
about providing a return value.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/04/18
Raw View

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>|>  Fergus Henderson wrote:
>|>  > James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
>|>  > >One question: does the "shall" mean that the implementation is
>|>  > >required to give a diagnostic if I write "void main()", or that the
>|>  > >results of writing "void main()" or undefined behavior (which the
>|>  > >implementation is free to define)?
>|>  >
>|>  > Since this is a requirement on the form of the program, not on its
>|>  > behaviour, the implementation is required to give a diagnostic.
>
>Really.

Yes, really! ;-)

>The restriction forbidding double underscores is also a
>requirement on the form of the program, and last time I looked (many
>drafts ago, I'll admit), it was undefined behavior.

Yes, but only because it is explicitly stated as undefined behaviour.

If a requirement is stated, but the consequences of violating that
requirement are not explicitly stated, then the consequence is implicitly
given by 1.3[intro.compliance]/5, which says that if such requirements
are on the form of the program, then violation must elicit a diagnostic,
but if such requirements are on the execution of the program, then
violation results in undefined behaviour.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: Michael Hudson <sorry.no.email@nowhere.com>
Date: 1997/04/15
Raw View
Fergus Henderson wrote:
> James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
> >One question: does the "shall" mean that the implementation is
> >required to give a diagnostic if I write "void main()", or that the
> >results of writing "void main()" or undefined behavior (which the
> >implementation is free to define)?
>
> Since this is a requirement on the form of the program, not on its
> behaviour, the implementation is required to give a diagnostic.
>

But that's very silly.
On some (many?) systems, including the MacOS where I do my coding, the
return value from main is of no significance, so I type
void main() { ... }
If this generated a warning, I'd get into the habit of not reading the
warnings my compiler prooduces, which is not a good habit.
What I'm saying is, to hell with sticking to the absolute letter of the
standard, common sense has to kick in somewhere.

--
Regards,
    Michael Hudson

Please don't email this address - it's not mine.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Stephen.Clamage@eng.sun.com (Steve Clamage)
Date: 1997/04/02
Raw View
In article dab18ee3669b3fc9896ac@news.leitch.com, jim.hyslop@leitch.com (Jim Hyslop) writes:
>- may break existing code (but not as badly as forcing only two valid
>signatures for main()!) ...

Where did you get that idea? The rule in C++ is essentially the same
as in standard C. Two signatures are required to be recognized by all
conforming implementations, but any implemenation may choose to recognize
other signatures as well.

Section 3.6.1 "Main function" spells this out in detail.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: jim.hyslop@leitch.com (Jim Hyslop)
Date: 1997/04/04
Raw View
In article <199704022036.MAA15282@taumet.eng.sun.com>,
Stephen.Clamage@eng.sun.com says...
> In article dab18ee3669b3fc9896ac@news.leitch.com, jim.hyslop@leitch.com (Jim Hyslop) writes:
> >- may break existing code (but not as badly as forcing only two valid
> >signatures for main()!) ...
>
> Where did you get that idea?


Author: d96-mst@nada.kth.se (Mikael Steldal)
Date: 1997/04/07
Raw View
In article <MPG.dad90fea5778a59896ba@news.leitch.com>,
jim.hyslop@leitch.com (Jim Hyslop) wrote:

>From various threads here and in comp.lang.c++.moderated; one
>"evangelist" in particular (and I mean that in the nicest way) will
>always post a correction to sample code that doesn't use int
>main(void) or int main(int, char **).

Isn't
int main(int)
allowed too?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1997/04/08
Raw View
Stephen.Clamage@eng.sun.com (Steve Clamage) writes:

|>  In article dab18ee3669b3fc9896ac@news.leitch.com, jim.hyslop@leitch.com (Jim Hyslop) writes:
|>  >- may break existing code (but not as badly as forcing only two valid
|>  >signatures for main()!) ...
|>
|>  Where did you get that idea? The rule in C++ is essentially the same
|>  as in standard C. Two signatures are required to be recognized by all
|>  conforming implementations, but any implemenation may choose to recognize
|>  other signatures as well.

There is a slight difference.  From 3.6.1/2: "It [the function main]
shall have a return type of type int, but otherwise its type is
implementation-defined."

I think that this was the intent in the C standard as well, but the
requirement is NOT explicitly stated.  (Some claim that it is implicitly
there, due to the fact that the semantics of returning from main are
described in terms of calling "exit", and calling "exit" without an
initialized int argument results in undefined behavior.)

One question: does the "shall" mean that the implementation is required
to give a diagnostic if I write "void main()", or that the results of
writing "void main()" or undefined behavior (which the implementation is
free to define)?

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/04/09
Raw View
James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>  From 3.6.1/2: "It [the function main]
>  shall have a return type of type int, but otherwise its type is
>  implementation-defined."
...
>One question: does the "shall" mean that the implementation is required
>to give a diagnostic if I write "void main()", or that the results of
>writing "void main()" or undefined behavior (which the implementation is
>free to define)?

Since this is a requirement on the form of the program, not on its
behaviour, the implementation is required to give a diagnostic.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]