------- Comment #5 from gin at mo dot msk dot ru 2008-01-17 17:45 ------- Subject: test case [Re: wrong code for dereferencing type-punned pointer]
No test case program hitting this wrong code will do something reliably: the code incorrectness is passing uninitialized value to the rest of program, so it can no longer `abort ()' or do something else depending on this value deterministically, reliably. One can only talk only about doing so with some reasonable probability. At least one such program already exist. Remember, the input was built after code in actual application. It was xemacs. More precisely, built recent stable version as taken from location in (mirror) list in <http://www.xemacs.org/Releases/index.html#Stable-Download>. Its `print.c' `std_handle_out_va' code for passing `extptr' to `std_handle_out_external' gets compiled wrong exactly as described, that is, passes uninitialized value that is generally invalid pointer, and most likely is other than what is passed as arg 1 to `memcpy' call earlier in `std_handle_out_va'. Exactly before `callq <[EMAIL PROTECTED]>' instruction the value is in `$rdi', exactly before `callq <std_handle_out_external>' it is in `$rdx'. They should be the same, but they are not. Had the wrong code executed as follows. Started it in debugger. Stopped exactly before `initial_command_loop' call in `main_1' in `emacs.c'. Called `stderr_out ("\n")' in debugger. (When actually debugging the program, it happens in course of `ldp' command defined by `.gdbinit' file created in build directory during build.) Program would receive `SIGSEGV' in backtrace: std_handle_out_external std_handle_out_va stderr_out Simpler program to link with preprocessed code initially posted, work in batch mode, clearly complain that the wrong code is hit in most cases when hits? Will write such - in my copious free time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803
