Why this works???

[Kenny McCormack]

#include <stdio.h>
int main(void) { printf("hello, world\n"); }

I compile it with all warning turned on and it still works fine.

 

[Tomás Ó hÉilidhe]

(e-mail address removed) (Kenny McCormack) wrote in @news.xmission.com:

#include <stdio.h>
int main(void) { printf("hello, world\n"); }

I compile it with all warning turned on and it still works fine.

Forgetting for the moment that you're a troll -- a troll who's actually
not half-bad at C programming, albeit, it's a shame you don't contribute
your expertise -- we both already know why the C standard permits that
program to do whatever it likes.

I've plenty of friends that get a kick out of winding people up... but
to be honest they've got better, more entertaining ways than posting to a
newsgroup. Which is why I'm led to believe that you actually do have more
than a passing interest in C.

I think you'll find that if you were to start posting something other
than tripe, that the regulars would welcome you with open arms. And no,
that's not an invitation to start a debate. In fact, as a precaution, I'm
going to killfile this thread right now.

Best of luck to you in life though, nobody can deny that you're
creative and inventive, even if it's misplaced.

 

[Harald van Dijk]

(e-mail address removed) (Kenny McCormack) wrote in


we both already know why the C standard permits that
program to do whatever it likes.

I don't. I don't see anything wrong with Kenny's program, and I suspect
there was nothing meant to be wrong with it.

And your message headers are still broken.

 

[Walter Roberson]

I don't. I don't see anything wrong with Kenny's program, and I suspect
there was nothing meant to be wrong with it.

In C89, there would be the failure to return a value from main.

 

[Harald van Dijk]

In C89, there would be the failure to return a value from main.

In C89, this causes an undefined exit status to be returned to the host
environment, but it no more an error than printing the result of rand().

 

[Kenny McCormack]

In C89, this causes an undefined exit status to be returned to the host
environment, but it no more an error than printing the result of rand().

Actually, every time I post this sort of thing (which is my stock sort
of response to idiotic "Why this works?" type posts), I forget about the
need for a "return 0;" at the end (actually testing my code with gcc
with all warnings turned on would have shown this up).

Still, I have to ask this: The C standard of course says that once UB
happens, all bets are off. And, let's assume for the sake of argument
that the above program does cause UB. But the point is, it doesn't
cause the UB until the function returns. I.e., the statement above is
"... once UB happens". But it is not the case that future UB can cause
current operations to fail. So, the above program would (under all the
usual CLC rules) work, as far as printing "hello, world", even though it
might start global thermonuclear war thereafter.

P.S. Of course, I lied in the original post, since if I had compiled it
with all warning turned on, I would have noticed the lack of "return 0;".

Oh well...

 

[Harald van Dijk]

Actually, every time I post this sort of thing (which is my stock sort
of response to idiotic "Why this works?" type posts), I forget about the
need for a "return 0;" at the end (actually testing my code with gcc
with all warnings turned on would have shown this up).

True, gcc can be convinced to warn about it in its default mode and in
its C90 mode. It won't warn about it in its C99 mode, though.

Still, I have to ask this: The C standard of course says that once UB
happens, all bets are off. And, let's assume for the sake of argument
that the above program does cause UB. But the point is, it doesn't
cause the UB until the function returns. I.e., the statement above is
"... once UB happens". But it is not the case that future UB can cause
current operations to fail. So, the above program would (under all the
usual CLC rules) work, as far as printing "hello, world", even though it
might start global thermonuclear war thereafter.

Indeed. I've asked a similar question in the past. If the compiler can
prove that at a given point, there is absolutely no way to finish running
the program without it invoking undefined behaviour, there are already
effectively no requirements on the implementation. The implementation
would be allowed to print "hello, world", and then immediately do
everything in its power to undo it. It would also be allowed to optimise
that and simply do nothing, even if stdout is redirected to a printer (or
any other device where removing output is physically impossible).

 

[user923005]

True, gcc can be convinced to warn about it in its default mode and in
its C90 mode. It won't warn about it in its C99 mode, though.


Indeed. I've asked a similar question in the past. If the compiler can
prove that at a given point, there is absolutely no way to finish running
the program without it invoking undefined behaviour, there are already
effectively no requirements on the implementation. The implementation
would be allowed to print "hello, world", and then immediately do
everything in its power to undo it. It would also be allowed to optimise
that and simply do nothing, even if stdout is redirected to a printer (or
any other device where removing output is physically impossible).

/*
OK, What am I missing? I do not see how undefined behavior comes into
play here.

I see nothing wrong with the program:
*/
#include <stdio.h>
int main(void) { printf("hello, world\n"); }

/*
5.1.2.2.3 Program termination
1 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;10) reaching the } that terminates the main
function returns a value of 0. If the return type is not compatible
with int, the termination status returned to the host environment is
unspecified.
Forward references: definition of terms (7.1.1), the exit function
(7.20.4.3).
*/

 

[Mark McIntyre]

printf() sends data to the stream, and the \n instructs the stream to
flush.

Neither of these forces the output to definitively appear - so
(certainly in a multitasking multithreaded world) the OS has a chance to
say "oops, UB, replace contents of print buffer with the words 'your
mother is a big hippo', rewind the mouse cable, connect 240V mains to
the ESC key and wind DRA1: 65535 ells backwards from the start mark'.

Indeed. I've asked a similar question in the past. If the compiler can
prove that at a given point, there is absolutely no way to finish running
the program without it invoking undefined behaviour, there are already
effectively no requirements on the implementation.

UB is an aspect of /runtime/ not compile-time behaviour.

 

[user923005]

printf() sends data to the stream, and the \n instructs the stream to
flush.

Neither of these forces the output to definitively appear - so
(certainly in a multitasking multithreaded world) the OS has a chance to
say "oops, UB, replace contents of print buffer with the words 'your
mother is a big hippo', rewind the mouse cable, connect 240V mains to
the ESC key and wind DRA1: 65535 ells backwards from the start mark'.


UB is an aspect of /runtime/ not compile-time behaviour.

Under 7.19.3:
"4 A file may be disassociated from a controlling stream by closing
the file. Output streams are flushed (any unwritten buffer contents
are transmitted to the host environment) before the stream is
disassociated from the file. the value of a pointer to a FILE object
is indeterminate after the associated file is closed (including the
standard text streams). Whether a file of zero length (on which no
characters have been written by an output stream) actually exists is
implementation-defined.
5 The file may be subsequently reopened, by the same or another
program execution, and its contents reclaimed or modified (if it can
be repositioned at its start). If the main function returns to its
original caller, or if the exit function is called, all open files are
closed (hence all output streams are flushed) before program
termination. Other paths to program termination, such as calling the
abort function, need not close all files properly."

The standard output stream stdout must be flushed when the program
exits.

 

[Harald van Dijk]

printf() sends data to the stream, and the \n instructs the stream to
flush.

Neither of these forces the output to definitively appear [...]

Good point.

UB is an aspect of /runtime/ not compile-time behaviour.

If you mean that compiling a program that has UB should not reformat your
hard drive if you don't actually try to run the program, then sure. If
you mean that UB (as opposed to syntax errors or constraint violations)
means a program must still be compiled by any conforming implementation,
then that is not entirely correct, because compilers are allowed to
reject programs when they can prove every execution path of the entire
program will invoke UB. But if you meant either of those, then it's not
relevant to my message, and if you meant something else, I didn't get it.

 

[Harald van Dijk]

[...] And, let's assume for the sake of
argument that the above program does cause UB. [...]

/*
OK, What am I missing? I do not see how undefined behavior comes into
play here.

There was no undefined behaviour, just a "what if" question.

 

[lovecreatesbea...]

On Jan 12, 9:06 am, (e-mail address removed) (Kenny McCormack)
wrote:
[...]

[...]

Actually, every time I post this sort of thing (which is my stock sort
of response to idiotic "Why this works?" type posts), I forget about the
need for a "return 0;" at the end (actually testing my code with gcc
with all warnings turned on would have shown this up).

I might say it isn't idiotic.

P.S.  Of course, I lied in the original post, since if I had compiled it
with all warning turned on, I would have noticed the lack of "return 0;".

The lack of a return statement means /*return (void) expr;*/; and the
function main() itself is type of non-void. The undefined behavior
definitively happens then. The whole program contains UB and may
cause demon fly out of your nose.

 

[CBFalconer]

Tomás Ó hÉilidhe wrote:
.... snip ...


I don't. I don't see anything wrong with Kenny's program, and I
suspect there was nothing meant to be wrong with it.

And your message headers are still broken.

How? I see nothing wrong, except (possibly) the char set for the
senders name.

 

[Walter Roberson]

/*
OK, What am I missing? I do not see how undefined behavior comes into
play here.

I see nothing wrong with the program:
*/
#include <stdio.h>
int main(void) { printf("hello, world\n"); }

/*
5.1.2.2.3 Program termination
1 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;10) reaching the } that terminates the main
function returns a value of 0.
*/

That's the case for C99, but not for C89. This subthread proceeded
from my pointing out the lack of return value being an issue for C89.

 

[Keith Thompson]

UB is an aspect of /runtime/ not compile-time behaviour.

Not entirely. C99 3.4.3p2:

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

 

[Keith Thompson]

The lack of a return statement means /*return (void) expr;*/;

If you mean that a missing return statement is equivalent to a
comment, you're right. If you mean that it's equivalent to
return (void) expr;
then you're mistaken.

and the
function main() itself is type of non-void. The undefined behavior
definitively happens then. The whole program contains UB and may
cause demon fly out of your nose.

In C99, falling off the end of main is perfectly legal, and equivalent
to ``return 0;''. In C90, "the termination status returned to the
host environment is undefined". This is not undefined behavior; if
demons fly out of your nose, it was caused by the host environment,
not by the program.

 

[Harald van Dijk]

How? I see nothing wrong, except (possibly) the char set for the
senders name.

That's exactly it. Message headers must not contain any non-ASCII
characters. If his name contains non-ASCII characters, it should be
encoded. Even if it weren't invalid, there is no sane way for a
newsreader to interpret his name when no encoding is specified. Tomás has
been told this before.

 

[Tomás Ó hÉilidhe]

That's exactly it. Message headers must not contain any non-ASCII
characters. If his name contains non-ASCII characters, it should be
encoded. Even if it weren't invalid, there is no sane way for a
newsreader to interpret his name when no encoding is specified. Tomás
has been told this before.

Harald, how do you write your own name for Usenet? It comes up as the
following on my newsreader:

=?UTF-8?q?Harald_van_D=C4=B3k?=

It's not that I'm too lazy to sort the problem out, it's just that I don't
know how to get my newsreader to use UTF-8 properly.

 

[Richard]

(e-mail address removed) (Kenny McCormack) wrote in @news.xmission.com:



Forgetting for the moment that you're a troll -- a troll who's actually
not half-bad at C programming, albeit, it's a shame you don't contribute
your expertise -- we both already know why the C standard permits that
program to do whatever it likes.

I've plenty of friends that get a kick out of winding people up... but
to be honest they've got better, more entertaining ways than posting to a
newsgroup. Which is why I'm led to believe that you actually do have more
than a passing interest in C.

I think you'll find that if you were to start posting something other
than tripe, that the regulars would welcome you with open arms. And no,
that's not an invitation to start a debate. In fact, as a precaution, I'm
going to killfile this thread right now.

Best of luck to you in life though, nobody can deny that you're
creative and inventive, even if it's misplaced.

Laughing at the blown up ego maniacs and lunchtime C experts in this NG
is not a waste of time. It helps to remind newcomers that not every one
here is here for their own publicity and to prance around acting like
the big I am. I enjoy Kenny's posts. The likes of Heathfield and CBF
need a Kenny to laugh at their pompous posturings.