CODEWITHSUNDEEP
c++cundefined-behavior
machine_1
machine_1

Reputation: 4454

If a part of the program exhibits undefined behavior, would it affect the remainder of the program?

Suppose that a programmer forgot to initialize one of his automatic variables, and that he used its value, thereby invoking undefined behavior.

...
int i = 0, j;
...
printf("value of 'j': %d\n", j);
...
...
char buf[256];
fputs("Enter query:", stdout);
fgets(buf, sizeof(buf), stdin);
... //process input
... perform other tasks

The programmer noticed gibberish characters on the screen, and realized that his program is erroneous, but it did not crash and went on anyway.

Supposing after this point, the program prompts the user for input and is expected to process it, display results, and perform other tasks all of which are independent from the uninitialized variable, is the programmer encouraged to discontinue the use of the program, fix the error, recompile, and run? Will the remainder of the program be inconsistent?

Upvotes: 6

Views: 480

Answers (4)

supercat
supercat

Reputation: 81217

The Standard presumes that programs run on an "abstract machine" which might arbitrarily behave in the most vexatious way possible, including time-travel, in any case where the Standard imposes no requirements. Many real-world implementations to target real machines whose behavior is defined and documented in many cases where the C Standard imposes no requirements. Unfortunately, some compiler writers are sloppy about making clear when their compiler will or will not behave in a fashion consistent with executing all of the steps of a program in sequence, and when it will or will not expose characteristic behaviors of the environment in cases where the Standard would allow but not require it to do so.

If a compiler specifies how it stores automatic objects of type int, and such types have no trap representations, such specification may also imply how code like the above will behave if the implementation's generated code is always consistent with that spec. The problem is that many implementations define how they store various objects, but don't indicate whether they store them in such fashion consistently or only in cases where the Standard would require it.

Upvotes: 0

Lundin
Lundin

Reputation: 214300

Undefined behavior is merely the programming language's lack of guarantees. But of course there could be other things dictating the program behavior and even in deterministic ways, such as documented compiler extensions or OS and CPU behavior.

Therefore you cannot reason about undefined behavior from the programming language's point of view. The language will simply say that all bets are off and no behavior of the program is guaranteed.

With a specific system in mind, you can reason about what will happen though. If this is a meaningful thing to do is another story.

In your specific example, the typical system will probably just print some garbage indeed, and it is quite unlikely that the rest of the program will be affected. This isn't always the case of UB though.

Upvotes: 2

haccks
haccks

Reputation: 106092

Once there is UB then nothing good can be expected. Standard says about it.

n1570-3.4.3 (P2):

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).

This behaviour holds for the entire program.

Upvotes: 1

Bathsheba
Bathsheba

Reputation: 234785

Once a statement with undefined behaviour is reached, then the behaviour of the entire program is undefined.

Paradoxically, the behaviour of statements that have ran prior to that are undefined too.

Upvotes: 16

Related Questions