V
vippstar
It's also allowed to charge you with $700 billion dollars.
You might be lucky, but serious programmers don't depend on luck.
It's also allowed to charge you with $700 billion dollars.
You might be lucky, but serious programmers don't depend on luck.
K
Kenny McCormack
False. If my implementation documents the behavior of void main(void),
then it is required to behave as documented. I believe even KT would
agree on this point.
R
Richard Tobin
Kenny McCormack said:
And then:
So now you're doing what "CLC regs do best". Taking a ludicrous but
legal scenario as the basis for an argument, In fact, Keith was taking
the very reasonable position that you might as well follow the
standard when there's no advantage to not doing so. Surely that is
just the pragmatism that we need more of in this group?
-- Richard
V
vippstar
False, it's not required to.
Whoever that KT person is, if he agreed with you he'd also be wrong.
But regardless, here's quotes from the standard for you (ISO 9899:1999
TC 3)
3.4.3 undefined behavior
Here's the NOTE that might've confused you:
Now, where do you see the standard mentioning that an implementation
that documents UB is required to follow what's documented?
S
s0suk3
Neither does it imply that int main(void) is correct, because, as you
said before, the standard doesn't define "correct". But back to *our*
opinions: if you don't consider 'struct { double d; struct tm t; }
main(double *d, long (*f)(void *, double))' correct, why do you
consider the program where I assign 33000 to an int to be correct?
(You said that it looked fine to you.) The only difference between
that example and struct { double d; struct tm t; } main(double *d,
long (*f)(void *, double)) is that the example shown provides a check
so that it will never fail. But other than that, they're the same:
both rely on implementation-defined behavior, and are therefore non-
strictly-conforming.
If defining a word that isn't defined by the standard to describe a C
feature is making up new meanings for words, then yes, I'm making up a
new meaning for "correct". But so are you, making up a new meaning for
"crock".
I usually do, but the point is whether void main(void) is correct.
I do, too, but the point is whether a program that relies on bit-
fields ordering is correct. Here's an example:
// Assumes right to left bit-field ordering
//
struct IEEEFloat
{
unsigned int fraction : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
}
union FloatMix
{
float native;
struct IEEEFloat ieee;
}
#include <stdio.h>
int main(void)
{
// will print -2.0 if 'float' is stored according
// to the IEEE floating point standard
printf("%f\n", (union FloatMix) {.ieee = {.sign = 1, .exponent =
128, .fraction = 0}}.native);
}
Do you consider this program "correct"? If yes, why do you not
consider void main(void) correct?
You haven't shown any valid arguments about why it isn't correct.
Sebastian
S
s0suk3
It's different in the sense that one is a mandate, the other is a
permission. But they're both referring to the same subject. Moreover,
in C99, it is an *explicit* permission.
In a sense, yes, but I know a lot of people that think of C99 as
"allowing void main(void)" and of C89 as "*not* allowing void
main(void)". Now, I know this is just common sense, and it doesn't
really apply in CLC Pedants Club(tm), but I think it's worth taking it
in into account.
Yes, but I was referring to providing a check in the code, as I did
with the #if directive.
At this point it *is* pretty much about the meaning of the word
"correct". Is it word games? Well, in a post at the beginning of this
thread you yourself said "And no, I'm not playing word games; it
really does depend on what you mean by "correct"."
I don't think void main(void) is better than int main(void), of
course, but, aside from the issue of portability, I don't think
there's any reason not to use it (provided that you're using a
compiler that supports it). And I'm puzzled about the fact that you
don't consider it to be correct, even in C99.
Sebastian
D
Dik T. Winter
But remember that C99 also allows: "double main(double)"...
J
James Kuyper
Richard said:
C99 implementations are pretty rare, and therefore don't provide a good
sample size. I've heard that many popular C90 compilers permit void
int(void); do none of them document the fact that they permit it?
I can, unfortunately, confirm that this is the case for the only
compiler whose documentation I could quickly locate. gcc allows void
main(void), but "info gcc" section 4 "C implementation-defined behavior"
fails to mention void main(void), even though it says "A conforming
implementation of ISO C is required to document its choice of behavior
in each of the areas that are designated "implementation defined". The
following lists all such areas, ...".
void main(void) is permitted by the version of gcc installed on my home
machine (4.1.2 20070626 (Red Hat 4.1.2-13). This is true even when
compiling in either -std=c89 or -std=c99, even with all of my other
favorite options ( -pedantic -Wall -Wpointer-arith -Wcast-align
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes) turned on. It
produces a warning message, but it also generates an executable that
works as intended.
V
vippstar
All that you say is fine and I'd agree if void main(void) was
"implementation defined behavior".
The reason I disagreed with Kenny and perhaps with you is that I think
void main(void) is UB in C99. (I don't know about C90, I don't have
that standard)
Here's why
5.1.2.2.1 Program startup p 1
Emphasis added by me.
Then, 4. Conformance p 1
What this undoubtedly means is that the program is required to be
defined with a return type of int.
If not, it's UB. Do we agree on this interprentation?
If we do, can you claim the same you claimed about implementation
documentation for undefined behavior?
If you agree with me about void main(void), I think you can also agree
that the standard doesn't require an implementation to document UB. If
the implementation chooses so, it's outside of the scope of the C
stardard; whether the documentation lies or not is not C's concern.
K
Keith Thompson
[I've fixed the "fi" ligature above.]
Um, no. I agree that C99 5.1.2.2.1p1 could be reasonably read that
way, and the wording should probably be cleaned up a bit, but I'm
almost certain that the *intent* is that main shall be defined:
as int main(void)
*OR*
as int main(int argc, char *argv[])
*OR*
in some other implementation-defined manner. I don't believe the
phrase "with a return type of int" was intended to cover the "some
other implementation-defined manner" case.
I note that the interpretation that it does calls for a somewhat
strained interpretation of the wording. The phrase "or in some other
implementation-defined manner" clearly (at least it's clear to me)
logically follows "It shall be defined". Compare my interpretation:
It shall be defined ... in some other implementation-defined
manner.
to yours:
It shall be defined with a return type of int ... in some other
implementation-defined manner.
As a matter of common sense (yes, I know that's a dangerous thing to
apply to the standard), I can't think of any good *reason* why an
implementation should be allowed to vary the parameters but not the
return type.
The problem with the current wording is that the phrase "with a return
type of int" appears only once, but is meant to apply to two of the
following three clauses. I think that's just a consequence of the
fact that C90 just has the first two clauses, and the third was tacked
on in C99.
But even if we accept your interpretation, that 5.1.2.2.1 doesn't
permit void main(void), 4p6 does (which is why I've long said that the
added permission in 5.1.2.2.1 is redundant):
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
and 4p8:
An implementation shall be accompanied by a document that defines
all implementation-defined and locale-specific characteristics and
all extensions.
Ignoring the added phrase in 5.1.2.2.1, "void main(void)" is a valid
extension. As such, an implementation that supports it is required to
document it. The documentation requirement is meaningless if an
implementation is allowed to lie in its own documentation.
In the absence of such documentation, the behavior of void main(void)
is undefined. And if an implementation does support void main(void),
it needn't behave in the obvious manner. A conforming implementation
could, as a documented extension, say that this program:
void main(void) { }
prints "main returns int, you fool!" on stderr.
If an implementation defines behavior that is not defined by the
standard in the document required by C99 4p8, then it must do so
accurately.
K
Keith Thompson
You seem to be implying that the difference between a mandate and a
permission is not very significant. I'm just going to give up on
trying to figure out what point you're trying to make here.
But C90 provides the same permission in section 4, where it permits
extensions (supporting "void main(void)" is a valid extension).
People who think that C99 allows "void main(void)" and C89 doesn't (if
there are any such people) are mistaken. Both versions of the
standard explicitly allow extensions that don't affect the behavior of
strictly conforming code.
[...]
At this point it *is* pretty much about the meaning of the word
"correct". Is it word games? Well, in a post at the beginning of this
thread you yourself said "And no, I'm not playing word games; it
really does depend on what you mean by "correct"."
And your apparent meaning of "correct" is one that I find absurd.
I agree that "void main(void)" is correct for an implementation that
supports it. But suppose I'm using a conforming compiler that rejects
any program that declared "void main(void)". If I write a program
that declares "void main(void)" and submit it to that compiler, I'm
out of luck. And this is what you call "correct" -- not just for a
particular implementation, but without qualification.
I'm puzzled by your puzzlement. And I'm equally puzzled as to why you
would consider using "void main(void)" even with a compiler that
supports it. It gains you nothing over "int main(void)".
K
Kenny McCormack
Keith Thompson said:
My point (with the silly $700B example) was that it might.
My implementation (particularly if it is, an in my example, an embedded
[non-hosted] environment) might give extra functionality (as an
extension) if I write void main(void).
As you say, extensions are permitted, and, most importantly, the
standard says nothing about what void main(void) [*] can or can't do.
[*] Hereinafter, let's abbreviate this as vmv, since I predict we will
be discussing this for years to come.
L
lawrence.jones
Richard Heathfield said:
What's different in C99 that makes you say that?
L
lawrence.jones
James Kuyper said:
As far as I know, almost all of the implementations that "permit" it
only do so accidentially, not as a deliberate extension. That is, they
don't do anything to specifically allow it, but they don't bother to
forbid it, either, which is a perfectly acceptable course of action for
undefined behavior. If the resulting (undefined) behavior is innocuous,
as it usually is, it *appears* that the implementation supports it when
it really doesn't. That's one of the reasons that the "or in some other
implementation-defined manner" wording was added to C99: to emphasize
that appearing to work is not sufficient, the implementation must also
document it or it's just an accident, not intentional support.
S
s0suk3
Exactly. It also allows void main(void) and struct { double d; struct
tm t; } main(double *d, long (*f)(void *, double)). That's the point.
And yet, Keith Thompson and Richard Heathfield insist it isn't
"correct", when it's even mentioned in the standard.
Sebastian
S
s0suk3
Well, it doesn't mention the word "correct" itself. But the way you
said that the standard didn't imply that /void/ main(void) is
"correct" made it sound as if it did imply that /int/ main(void) is
correct.
Exactly, and here I'm talking strictly in regard to the standard,
because I know that, in regard to implementations, void main(void) may
or may not be correct. In regard to the standard, however, vmv is
correct (yes, by the dictionary definition of "correct").
Yes, it's not much of a fair comparison, and that's why I provided the
other example who's output is dependent on the bit-fields ordering,
but you didn't answer whether you consider it to be correct.
<snip>
Sebastian
S
s0suk3
In C90, and in regard to implementations, vmv may or may not be an
extension (if it isn't, it's simply UB). In regard to the standard,
it's simply UB.
In C99, and in regard to implementations, it's similar as for C90:
whether it supports vmv or not is implementation-defined (and if it
isn't supported, it's simply UB). In regard to the *standard*,
however, vmv is allowed, and therefore (by the dictionary definition
of "correct") it's correct.
I'm not qualifying it with any particular implementation, but I am
qualifying it with the standard (i.e., by its wording).
I don't usually use void main(void), but I do think it's still
correct.
Sebastian
J
James Kuyper
Richard said:
Aiiiy! I'm getting old; the frequency with which my typos survive
multiple proofreading passes is getting pretty depressing. You should
see what my first drafts look like!
R
Richard Bos
Not true. Or at least, not reliably true, and therefore not true within
the meaning of the act, yer'onner.
Only correct where _explicitly_ allowed. Not correct everywhere.
Therefore, not correct when used in a general context (which, evidence
to the contrary lacking, any c.l.c post must be assumed to be).
But this is not my main point. That's this:
Suppose the OP had not written void main(void), but
union return_tuple main(struct env, char* __cmd_line__, bool intactv)
and Keith had responded to that with the same correction he wrote above,
would you even have considered bothering to respond? My money's on "no".
The contingent of M$-and-Ganoo-lovers who defend void main() almost
always are willing to defend _only_ void main(), and not any other
implementation-defined, non-standard form of main().
So why this discrimination? It can't be that you seriously believe that
void main() is correct, and other non-standard main()s are not. That
would be too dumb even for a Ganoohead.
Richard
S
s0suk3
OK, this time I'm only including the code:
// Assumes right to left bit-field ordering
//
struct IEEEFloat
{
unsigned int fraction : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
};
union FloatMix
{
float native;
struct IEEEFloat ieee;
};
#include <stdio.h>
int main(void)
{
// will print -2.0 if 'float' is stored according
// to the IEEE floating point standard
printf("%f\n", (union FloatMix) {.ieee = {.sign = 1, .exponent =
128, .fraction = 0}}.native);
}
The code is not strictly conforming. But is it correct? If yes, why
isn't void main(void) correct?
Sebastian