c - Can undefined behavior which would follow a getc() alter program behavior if the getc() exits via SIGINT -

under modern interpretations of "undefined behavior", compiler entitled assume no chain of events cause undefined behavior "inevitable" occur, , can eliminate code applicable in cases code going perform undefined behavior; may cause effects of undefined behavior work backwards in time , nullify behaviors otherwise have been observable. on other hand, in cases undefined behavior inevitable unless program terminates, program , terminate prior invoking undefined behavior, behavior of program remain defined.

in making determination, causes of termination compiler required consider? couple of examples:

on many platforms, call function "getc" return (at least eventually), under cases outside control of compiler not. if 1 had program like:

int main(int argc, char *argv[]) {   if (argc != 3)   {     printf("foo\n");     return 0;   }   else   {     int ch;     printf("you'd better type control-c!\n");     int ch = getc();     if (ch < 65)       return (ch-33) / (argc-3);            else       return int_max + ch;   } } 

would behavior defined in case program called argc equal three, sigint prevented getc() call returning @ all? if there value getc() return result in defined behavior, no undefined behavior occur until compiler such input not received. in event there no value getc() return avoid undefined behavior, however, overall program remain defined if getc() prevented ever returning value? existence of causal relationship between return value of getc() , actions invoking undefined behavior affect things (in example above, compiler not know particular form of undefined behavior occur without knowing character input, possible input trigger form).

likewise, if on platform there existed addresses which, if read, specified cause program terminate, compiler's specified volatile reads trigger hardware read requests, , external library on platform specified return pointer such address, factors imply behavior of bar in separate example:

int foo(int x) {   char volatile * p = get_instant_quit_address();   if (x)     { printf("hey"); fflush(stdout); }   return *p / x; // cause ub if *p yields value , x 0 } int bar(void) {   return foo(0); } 

would defined (as terminating without having printed anything) if attempting read *p in fact immediate terminate program execution without yielding value? division cannot proceed until value returned; thus, if no value returned, there no divide zero.

by means c compiler allowed determine whether given action might cause program execution terminate in ways doesn't know about, , in cases allowed reschedule undefined behavior ahead of such actions?

this described in c++ under [intro.execution]:

5 - conforming implementation executing well-formed program shall produce same observable behavior 1 of possible executions of corresponding instance of abstract machine same program , same input. however, if such execution contains undefined operation, international standard places no requirement on implementation executing program input (not regard operations preceding first undefined operation).

it accepted c has same characteristics, , c compiler can perform "time travel" in presence of undefined behavior.

importantly, note question whether there exists instance of abstract machine exhibiting undefined behavior; doesn't matter can arrange prevent undefined behavior on machine terminating program execution first.

you can prevent undefined behavior (and resulting time travel) if cause program terminate in fully-defined way abstract machine cannot wriggle out of. example, in second example if replace access *p (exit(0), 0) undefined behavior cannot occur there no possible execution of abstract machine exit returns caller. whatever characteristics of platform, abstract machine not have terminate program on access insta-kill address (indeed, abstract machine not have insta-kill addresses).