help w/ c/c++ problem

[Army1987]

Richard Bos wrote, On 11/07/07 15:21: [...]

Of course, it should by now be apparent that MAO is that both i=i++ and
void main() are illegal C, though each may be legal C-plus-extensions.

I agree with you here, and agree with what I think is your main point,
that void main() should simply be considered illegal and it left at that.

Well, 5.1.2.2.1 specifically states that, in addition to the two
defined prototypes of main:

int main(void)
and
int main(int argc, char *argv[])

you are allowed:

some other implementation-defined manner

So? An implementation might define whatever it wants, as long as
it doesn't break strictly conforming programs. For example,
fopen() with implementation-defined modes other than "r", "w", "b"
and version of these with '+' and/or 'b', implementation-defined
conversion specifiers with printf(), MS's behavior of
fflush(stdin)...
"Undefined behavior" doesn't imply "an implementation is forbidden
from defining and/or documenting a behavior". So the case of
void main() is not different from that of fopen(name, "rx"), and
neither from that of i = i++, even if I sorted them in decreasing
likelihood to be defined to something intentionally useful (but
that's OT in comp.lang.c, which only deals with standard C).

 

[Keith Thompson]

Why? Defining the behaviour as "the compiler will reject the program"
or "when executed, `i = i++` will terminate the program with an
'I TOLD YOU, i = i++ IS UNDEFINED!' message" sounds OK to me.

Sure, but how would it handle '*p = (*q)++;', where p and q may or may
not point to the same object? A large part of the reason for making
such things undefined is that the compiler can't always determine
whether a construct exhibits undefined behavior (and defining rules
for when the compiler must make this determination would make the
language too complex).

Compiler can and often do detect *some* instances of undefined
behavior, but they can't detect all of them. (I realize you didn't
claim otherwise; I'm not arguing with you.)

For that matter, the compiler can't legally reject a program
containing 'i = i++;' *unless* it can prove that that statement will
always be executed.

Another possibility is that a compiler might impose a strict order of
evaluation on all expressions, and in effect insert sequence points
before and after the evaluation of each operand. This would disable a
lot of optimizations, but it would make a program's execution more
predictable, which might be a good tradeoff for some applications.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Sure, but how would it handle '*p = (*q)++;', where p and q may or may
not point to the same object?

It would compare p and q, and if they are equal (or if their targets
overlap), abort the program, or if they are not equal (and there is no
overlap), it would behave as required. I don't know of any implementation
with an option for this, but I wish I did; it would be very useful for
debugging.

 

[Mark McIntyre]

Sure, but how would it handle '*p = (*q)++;', where p and q may or may
not point to the same object?

Is there a rule that the compiler has to emit the same diagnostic for
all manifestations of an error - could an implementation error trivial
cases, and warn on others? It'd be fairly handy in fact.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Is there a rule that the compiler has to emit the same diagnostic for
all manifestations of an error - could an implementation error trivial
cases, and warn on others? It'd be fairly handy in fact.

There's certainly no such rule. There's no requirement for a
diagnostic of any kind for undefined behavior, but an implementation
can issue any diagnostics it likes.

Compilers can and do issue warnings for instances of UB that they
happen to detect (which is why you often get more warnings if you
enable optimization which requires more analysis).

Note that the standard doesn't distinguish between warnings and error
messages.

 

[Army1987]

]
Well, pre-ANSI C had no 'void' keyword. For a function not intended to
return a result, it was common to declare it with no explicit return

But I think in C89 a main() with no return caused UB...

Not quite; it merely returns an undefined termination status to the
host environment.

Which will try to use it to call exit(), causing UB.

I don't think so. My draft (n869) says:

If the return type of the main function is a type compatible with
int, a return from the initial call to the main function is
equivalent to calling the exit function with the value returned by
the main function as its argument; reaching the } that terminates
the main function returns a value of 0. If the return type is not

That was added to C99 AFAIK. We were discussing about C89.

compatible with int, the termination status returned to the host
environment is unspecified.

so, as I read it,

int main(void) { return X; } equivalent to exit(X);

That's what they say, but they use "equivalent" with a strange
meaning, as the footnote (and my program elsethread) show.

 

[Ben Bacarisse]

On Fri, 06 Jul 2007 13:17:17 -0700, Keith Thompson wrote:

]
Well, pre-ANSI C had no 'void' keyword. For a function not intended to
return a result, it was common to declare it with no explicit return

But I think in C89 a main() with no return caused UB...

Not quite; it merely returns an undefined termination status to the
host environment.
Which will try to use it to call exit(), causing UB.

I don't think so. My draft (n869) says:

If the return type of the main function is a type compatible with
int, a return from the initial call to the main function is
equivalent to calling the exit function with the value returned by
the main function as its argument; reaching the } that terminates
the main function returns a value of 0. If the return type is not

That was added to C99 AFAIK. We were discussing about C89.

The wording in C99 is different but I don't have a copy of C89 handy.
I choose n869 as a close approximation. I thought it was a reliable
guide to what was in C89.

That's what they say, but they use "equivalent" with a strange
meaning, as the footnote (and my program elsethread) show.

Strange, yes, not I don't see how it relates to my point. You were
suggesting that in C89 a "main() with no return" is UB. You may well
be right -- what does the real C89 standard say about reaching the "}"
in main?

This is the case that pertains to your UB suggestion.

 

[¬a\\/b]

Sure, but how would it handle '*p = (*q)++;', where p and q may or may
not point to the same object? A large part of the reason for making
such things undefined is that the compiler can't always determine
whether a construct exhibits undefined behavior (and defining rules
for when the compiler must make this determination would make the
language too complex).

in how i see, the above is wrong:
it would not make the language too complex, but its implementation;
(the language if i remove the particular cases is easier)
but the problem remain: if someone write the laws; are they ok in the
reality? can someone do some test for see if one law is better than
another? what law is ok?
only who see all (nobody here) can write the laws

 

[Kenny McCormack]

Looks like local has already died when frob() is called. Yes, the
behaviour is undefined, but if I comment out the last line of the
body of frob() it correctly displays all the stuff before it.

Try a correct instruction to copy global to local. This needs
strcpy, and a suitable #include.[/QUOTE]

And thanks for playing: Completely Missing The Point!