🚀 go-pugleaf

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>
>|> The implementation is allowed to make the program work even if main() is
>|> not defined, so long as it issues a diagnostic.
>
>By a curious coincidence, this point has just been discussed in
>comp.std.c.  The concensus of the experts there was that the absense
>of main (or a non-conformant main) is simply undefined behavior: no
>diagnostic required.

If the comp.std.c experts are right, then I think that is a difference
between C++ and C, because the September 95 draft C++ standard makes it
pretty clear that a diagnostic is required.

| 3.6.1[basic.start.main]/1:
|	A program shall contain a global function called main, which is the
|	designated start of the program.

Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
a diagnostic is required:

|   1.7  Processor compliance                           [intro.compliance]
| 
| 1 Every conforming C++ processor  shall,  within  its  resource  limits,
|   accept and correctly execute well-formed C++ programs, and shall issue
|   at least one diagnostic message when  presented  with  any  ill-formed
|   program  that contains a violation of any diagnosable semantic rule or
|   of any syntax rule, except as noted herein.
[...]
| 3 The set of "diagnosable semantic rules" consists of all semantic rules
|   in  this  International  Standard except for those rules containing an
|   explicit notation that "no diagnostic is required."

James Kanze continues:

>I believe that the simple answer is that Windows programs operate in a
>unhosted environment.

That's a possible answer with regard to C conformance, but C++ is different:
C++ programs must contain main() even in an unhosted environment, according
to the September 95 draft C++ standard.  (The reason for this is because
the definition of the order of execution of constructors for global variables
is defined with reference to when main() gets invoked.)

I'm not sure whether Windows C/C++ compilers claim conformance to the
relevant C/C++ standards.  One would need to consult the documentation
for the compiler in question to see whether they claimed conformance,
and if so, whether they claimed conformance as a hosted or unhosted
environment.  Even if they do claim conformance, they will usually have
some conforming and some non-conforming modes of operation; you need to
be sure that the compiler is being invoked in the correct mode.

>Another interesting point that was made in the discussion on
>comp.std.c was that g++ normally operates in an unhosted environment,
>at least according FSF.

That depends on what you mean by "normally".  If you have installed g++
together with the GNU C and C++ libraries, then I believe that the FSF
would claim conformance (modulo the odd bug here and there) as a hosted
environment, not just as an unhosted environment.  This is normally the
case on Linux, for example, although I agree that it is probably not
normally the case on most other systems.

>|> You are correct to infer that this means that all Windows programs
>|> which do not define main() are ill-formed.
>
>No, he's not.  They are simply programs for non-hosted environments.

No, I beg to differ -- as explained above, C++ requires main() even
for non-hosted environemnts.

>Whether requiring a different start-up procedure than calling main is
>a good idea for this extension can be discussed under quality of
>implementation; it is not a standards question, however.

Actually, I think it is, albeit not a direct one. Remember that the
purpose of the C++ standard is amoung other things to promote
portability of C++ programs.  Extensions should be done in a way that
makes it easy for customers to make selective use of them with
conditional compilation, so that they can easily write portable
programs that are nevertheless customized to take advantage of the
features of particular platforms.  Requiring a different start-up
procedure makes doing this more difficult than it need be.

>I personally think that the Microsoft environment stinks, but I still
>get the feeling that there is a double standard at work here. If
>someone complains that g++ doesn't issue a diagnostic when I define a
>nested function, dozens of people (including you, Fergus?) will
>quickly point out that all I have to do is add the flags -ansi
>-pedantic, and it will; without these flags, the compiler is operating
>in a non-conformant mode, and this fact is in the compiler
>documentation.  Unless things have changed in the last 4 years, you
>need to give a special flag to the compiler to get Windows support.
>The default mode was the conformant mode.

I don't think I am applying a double standard.

I did not claim that any or all Windows compilers were not conforming.
I simply pointed out what they were required to do in order to conform.

I did say that

| I think the problem is due to Microsoft overlooking the C and C++
| standards, not vice versa.

but the problem I was referring to was not that Microsoft's compilers
don't conform to the standard (most likely they do) but rather that
Microsoft encourages people to write non-portable, non-standard-conforming
code which is then subject to the usual problems of vendor lock-in.

Now GNU's compilers also have their own extensions, and the problem of
vendor lock-in can also arise for programs that use GNU extensions, but
I do think GNU aims to minimize the difficulty of writing portable
programs that selectively take advantage of those additional features.
For example, the syntax of GNU's __attribute__ feature is designed to
make it easy to use a conditionally defined macro to enable/disable the
use of that feature.

>|> Windows compilers which wish to conform to the C and C++ standards
>|> should include code [...for WinMain()...]
>|> in their libraries, so that they can accept programs which define main()
>|> but not WinMain().
>
>And what will they do with all of the other Windows requests in the
>code?

They can do whatever they like.  I was reiterating the need
for Windows compilers to accept strictly conforming programs, and
showing how that could easily be implemented, in a way which made the
selective use of Windows features possible without the programmer
having to define WinMain(), even if the OS required a program to define
WinMain() rather than main().

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]