Keith Thompson said:
I stated my reasons several months ago.
Okay, let's review those. Here are all the relevant excerpts
I could find from all of your messages in this thread:
My own preference would have been to make defining "main"
incorrectly a constraint violation, not undefined behavior.
Obviously just a statement of personal opinion.
Programs using "void main(void)" (as well as books that claim
it's valid), would have been weeded out over the years as they
failed to compile.
That is a benefit (and granting FTSOD that the part about books
is also true, which I'm not as sure about, but no matter). I've
already agreed that some benefits exist, just have a different
opinion than yours as to their value.
But the fact remains that the language is defined the way it is,
and conforming to that definition shouldn't be at all difficult.
It isn't clear whether this is talking about the current standard
or the hypothetical revised one (where non-working forms of main()
have mandatory diagnostics), but in any case all that's being offered
is opinion.
Failing to do so can *sometimes* indicate a lack of attention to
detail that can and should reduce the reader's trust in the rest
of the code (Schildt's books are a classic example).
That's a true statement (not counting the 'should' part, which is
a judgment call), but it isn't by itself an argument that such
cases of main() should be made constraint violations.
Yes, I'm assuming that a given compiler knows what forms of main
are supported by that compiler. That's not *necessarily* true;
the same compiler could be used both for a target that supports
"double main(char*)" and for one that doesn't. In effect, the
same compiler would be part of two distinct implementations.
But in such a case, it shouldn't be at all difficult to
parameterize the compiler so that it *does* know what forms of
main are supported.
Opinion.
There's no reason a single compiler can't
produce different diagnostics when invoked for different targets.
Obviously it can, but forcing that approach also has costs,
as I have already mentioned.
I also want diagnostics for syntax errors, missing headers,
undeclared identifiers, and so forth. These diagnostics are
required by the language, and I presume you don't object to that.
I fail to see how using a definition of main *that is not
supported by the compiler I'm using* should be any different.
This is a point of argument, but a weak one. I've already
responded to this statement, pointing out some differences.
But if you don't want such a warning, you could always filter
it out or invoke the compiler in some non-conforming mode.
I would call this a rhetorical argument: it's the sort of
argument that often works in debate-like settings but on closer
examination doesn't have much substance; my response earlier
explains this more specifically.
It would be helpful if you could cite a specific implementation
where this [knowing what forms of main() won't produce bad
behavior] would be at all difficult. I've never encountered one.
The last sentence does make a point of sorts, but a weak one. I've
never seen a Higgs boson either, but that doesn't mean they don't
exist (and in fact they probably do even though no one has yet seen
any definite evidence for them). The posting from Philip Lantz
describes a particular multi-targeted implementation that's related
to this point.
Besides the statements of opinion, all I see are non-arguments
or weak arguments, all of which I've already responded to.
Continuing back at the last message...
This isn't important enough for me to spend any more time arguing
about it.
My point was that you aren't really offering much in way
of argument but just repeated statements of opinion. Every
point you've presented that counts even as a weak argument
I've already responded to. Conversely however, I have presented
several arguments to the contrary, and you have responded only
to some of them.
Your claim, that it can be difficult for a compiler to determine
what forms of main() it should support, is an interesting one.
As I said, I've never encountered such a situation. I was hoping
both to learn something and to advance this discussion.
I understand that it's theoretically possible that a compiler might
have difficulty determining what forms of main() are supported on the
target system for which it's generating code. I do not believe that
there is any such difficulty in practice.
Have you ever tried doing it? Not just finding out what the
possibilities are, but writing the code that diagnoses them?
And, after that, tried maintaining those implementations as
the operating system(s) that they support evolve and accommodate
or disaccommodate various forms of main() that work (needless to
say, without bothering to notify all the compiler developers
in the world)? The statement would be a lot more convincing
if it were backed up by some experience actually doing it,
rather than just a gedanken experiment.
I'll just leave it at that.
(What I *really* would have preferred would be for any definition of
main() other than the two standard ones to be a constraint violation.
Compilers could still support other forms as an extension and/or in
some non-conforming mode. That *might* have prevented the endless
arguments over "void main()", with no great cost that I can see.
I know about the third "envp" parameter; as I said, that could still
be implemented, but with a diagnostic or in non-conforming mode.
To be clear, I'm talking about a hypothetical change that *could*
have been made by ANSI in 1989, and that would apply only to hosted
implementations.)
So you were only kidding when you said "I'll just leave it
at that."?
