Question regarding UB

I have a somewhat flippant question regarding undefined behaviour. Does
an operation which invokes undefined behaviour affect the whole program,
or are earlier statements guaranteed to execute correctly?

For example:

#include <stdio.h>

int main(void) {
int i;
printf("Hello, world!\n");
fflush(stdout);
i = i++; /* or some other undefined behaviour */
return 0;
}

Is the printf() statement guaranteed to execute? Is "Hello, world!\n"
guaranteed to be sent to stdout? Or could a conforming implementation
refuse to compile this program, or accept it and let loose nasal demons
without even greeting the world first?

re: Question regarding UB

Philip Potter wrote:
I *think* a conforming implementation may do anything it wants with a
program that invokes undefined behaviour, including refusing to
translate it. If the latter, then a diagnostic is required. During
runtime, no constraint on program behaviour is imposed.

Having said that of course, one would be hard pressed to point to actual
implementations where invoking undefined behaviour affects behaviour of
the preceding program statements.

re: Question regarding UB

santosh wrote:FWIW, I can't find a normative reference to that effect (just notes,
footnotes).

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

re: Question regarding UB

Philip Potter wrote:Hard to say. Note that fflush() delivers any buffered
output "to the host environment," which may not be the same
thing as "to its final destination" -- which might, for
example, be on the far end of a TCP/IP connection currently
undergoing a network storm. fflush() will probably deliver
the data to the network stack and not wait for acknowledgment
from the other end, and then when the U.B. strikes and takes
the local machine down in flames, the remote side's socket
may just time out and give up. No greeting is received.

Also, there are undefined behaviors that are less strongly
tied to a particular execution path. For example,

/* main.c */
#include <stdio.h>
int answer = 42;
int function(void);
int main(void) {
printf ("%d\n", answer == 0 ? function() : answer);
return 0;
}

/* function.c */
extern double answer;
int function(void) { return answer; }

.... produces undefined behavior because the two declarations of
`answer' are in conflict (6.2.7p2). It's U.B. even though function()
is not called -- maybe the linker catches the mismatch and refuses
to produce an executable program, maybe the linker succeeds but
the program's frammis mapping is whirligigged, ...

--
Eric Sosman
esosman@ieee-dot-org.invalid

re: Question regarding UB

On Feb 26, 2:07*am, Philip Potter <p...@doc.ic.ac.ukwrote:Consider:
int main(void) {
int i;
printf("Hello, world!\n");
memset(&i, 0, 1000000000);
fflush(stdout);
return 0;
}

The previous printf() call completes successfully.
Then the memset() function call causes some horrible crash and we
never see the output.
That would be an example of subsequent undefined behavior affecting
previously correct code.
I do not think it is safe even after the fflush() call because :

"2 Ifstream points to an output stream or an update stream in which
the most recent
operation was not input, the fflush function causes any unwritten data
for that stream
to be delivered to the host environment to be written to the file;
otherwise, the behavior is
undefined."

So the data has been delivered to the operating system, but I do not
think it is a guarantee that it is written (indeed, for some operating
systems you must have a successful fsync() call or some such thing to
really guarantee delivery to the output stream).

So it is clear that we cannot depend on earlier code that is correct
to produce expected output after the introduction of undefined
behavior later in the program.

re: Question regarding UB

Philip Potter wrote:Yes.
No.
No.
No.
Yes.

UB is only what the standard says that it is.

What the standard guarantees, and how a program is likely to run,
are two different things.

The C standard comittee doesn't care about
what any program which contains any undefined behavior, does.

All that is required for a kind of code to be undefined,
is a lack of interest in that kind of code by the standard comittee.

--
pete