🚀 go-pugleaf

In article <4evp66$a58@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
Henderson) writes:

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

This would seem to be a difference.  In the C standard, there are never
any explicit words that say a program must/shall contain a function
main.  It does say that "the function called at program startup is named
main", but is rather silent about what happens if no such function
exists.  (Such silences are generally interpreted as undefined behavior.)

There are other differences as well: if it exists, the function main may
only have one of two forms.  Unlike in C++, there is no implication that
the implementation may permit other forms.

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

Correct.  I just checked the definition of an unhosted environment, and
it is far more restrictive than in C.  In fact, the only difference is
that in an unhosted environment, most of the libraries may be missing.

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

This is true for most compilers, I believe.  (Even for those claiming
compliance, the question arises: with which version of the draft.)

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

Well, normally, for me, means on a Sun:-).  In fact, however, g++ is
more compliant (in a hosted environment) than Sun CC, at least under Sun
OS 4.1.  They may use the local libc, but at least they fixed up
stdlib.h so that free takes a void*.  (It's obvious that Sun wants you
to upgrade to Solaris.  Rather pissed me off, though.  I'd told every
one at the customer site how great the Sun compiler was, and when they
finally bought it, we couldn't even compiler our overloaded operator
delete:-(.)

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

Agreed.

Although one might ask what version of the draft (if any) they are
trying to comply with.  My impression is that the intent is to be
unhosted; until only a short time ago, however, the draft standard
didn't even mention the word (and the wording implying the call to main
in the initialization of statics is also very recent).

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

The different start-up procedure is only required if you are using
Windows (I think).  To use Windows, they also require you use a lot of
other special functions, that you won't find on any other machine.

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

This is probably true.  IBM used to do the same thing.  I suspect that
a lot of other vendors would too, if they could get away with it.  (Will
using Java lock you into Sun?  If not, I'm willing to bet that it is
more because Sun's market would refuse to use it if this were the case,
rather than any generosity on the part of Sun.)

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

Hmmm...  I believe in fact that the GNU coding guidelines actually
encourages you to use GNU extensions in everything but the compiler
itself (since it has to be compiled with the native C compiler).  At any
rate, things like signatures and nested functions are turned on by
default.  You need special switches to be compliant.

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

Well, this was the case with the last Windows compiler I used (an early
Zortech).  The use of WinMain was for programs which managed Windows
themselves (and thus had a lot of calls to other proprietary routines).
The compiler would happily compile normal programs, and run them from a
shell within a window.  In practice, this is not much different from the
situation with Unix and X.  An X-Windows program may have a function
called main, but it has so many other things that aren't portable to
other systems, it really doesn't matter.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]