🚀 go-pugleaf

In article <9602010236.26117@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

|> >I have just realized that something is grossly overlooked in C++ standard.

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

|> >It requires every program to have the main() function (which implementation
|> >is not allowed to supply) with parameters (void) or (int argc, int*argv[]).

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

|> >However, Windows programs have another convention: prrogram must contain
|> >the function
|> >  int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)

I believe that the simple answer is that Windows programs operate in a
unhosted environment.  In an unhosted evironment, the language is
defined, but which libraries are present, how the program is started,
etc., etc., are implementation defined.

By definition, a program written for an unhosted environment is not
portable outside that environment.  And in fact, a program written for
Windows will probably not work on my Unix box:-).

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.  It just so happens that the implementation
defined rules are *very* close to what the standard requires of a
hosted environment.  (The machine I'm typing this on runs Sun OS 4.1.
I have two compilers available, g++ and Sun CC.  On this machine, at
least, the unhosted g++ is closer to the standard than the supposedly
hosted environment of Sun CC:-).  As I understand it, the reason g++
is unhosted is that they don't provide the libraries themselves, and
thus cannot make any guarantees about them.)

|> A compiler is allowed to accept the program

|> 	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
|> 		int cmdShow)
|> 	{
|> 		return 0;
|> 	}

|> so long as it issues at least one diagnostic, e.g.
|> "warning: standard C++ requires a definition of main()".

In conformant mode, I would expect to see something along the lines of
`_main undefined' when linking, although I am far from sure that the
standard requires it.

I feel fairly sure that Microsoft does provide a conformant mode, and
that when compiling in this mode, you will get such an error message.
Of course, when compiling in this mode, you probably cannot use
Windows.  But the standard does not require the capability to use
Windows, so this is not a problem.

|> But if a compiler does not accept

|> 	int main() { return 0; }

|> as a complete program, then that compiler is not a conforming C or C++
|> implementation.

Most compilers have non-conformant modes, with extensions.  I'm not
familiar with the newer Microsoft products (my MS C compiler is
version 1.2), but I rather suspect that if you don't request Windows
support (which is not really needed in the above program), the
compiler and linker will accept it.

Windows support is an extension, and the compiler is entitled to make
any requirements it wishes on programs using the extension.  A program
using the extension is not a C program, or in this case, since the
extension really involves the environment, and not the language
itself, it is not a C program for a hosted environment.

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.

|> >Some of this is of course quirks or even outright ignored in Win32
|> >(prevInst), but the full non-parsed command line could be useful sometimes,
|> >and not all implementations provide the function retrieving it.

|> In many operating systems, the command-line parsing is done by the
|> shell, not the OS.  Such operating systems cannot provide the non-parsed
|> command line.

|> >And anyway this is definitely not a main() from the specs.
|> >Maybe the requirements on the main() should be relaxed somehow?

|> Are you suggesting relaxing the requirements on implementations,
|> or the requirements on programs?

|> I presume you are referring to 3.6.1[basic.start.main]/1:

|> |	A program shall contain a global function called main, which is the
|> |	designated start of the program.

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

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.  And the non-conformity is
actually simply an unhosted environment (where it is conformant).

|> However, that means only that a compiler is required to issue
|> a diagnostic; it does not mean that the compiler must reject the
|> program.

|> Obviously a program that does not define main() is not going to be
|> portable, so I don't think that requirement on programs should be
|> relaxed.

|> Windows compilers which wish to conform to the C and C++ standards
|> should include code similar to

|> 	HINSTANCE __curInst;
|> 	HINSTANCE __prevInst;
|> 	LPSTR __cmdline;
|> 	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
|> 		int cmdShow)
|> 	{
|> 		int argc;
|> 		char **argv;

|> 		__curInst = curInst;
|> 		__prevInst = prevInst;
|> 		__cmdLind = cmdLine;
|> 		__parse_command_line(cmdline, &argc, &argv);
|> 		return main(argc, argv);
|> 	}

|> 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?  If you are writing Windows code, your program is, by
definition, unportable, and I wouldn't worry about not having a main.
If you are writing code which just happens to run in a shell under
Windows, but is not a Windows program itself, then don't request
Windows support of the compiler, but use the compatible (hosted) mode.
(If the Microsoft compiler doesn't have such a mode, which I seriously
doubt, other Windows compilers do.  Or at least, my old Zortech
compiler did.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité 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
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]