格式化 c++ 代码时汇编程序和十六进制转储更改

Question

A C++ project I work on does not have consistent indentation. The lead developer told me it might not be safe to reformat the code. I thought it might not matter to the compiled code. As a test I tried reformatting one file using a Formatter based on the Eclipse "GNU [built-in]" Profile. When I recompiled the file the md5sum changed. I did a hexdump of the file and it showed one byte changed. I disassembled the object file. I also compiled with debugging and I got the source code line. I used diff to get the assembly instruction that changed.

The source was this line

        logErr
        << xmlutils.GetErrorMessage() << endl;

Below is the diff output showing the changed assembly

     23be:  89 04 24                mov    %eax,(%esp)
     23c1:  e8 fc ff ff ff          call   23c2 <_ZN12RerouteAdapt11WriteToFileERKSs+0x64>
     23c6:  e8 fc ff ff ff          call   23c7 <_ZN12RerouteAdapt11WriteToFileERKSs+0x69>
-    23cb:  c7 44 24 04 79 01 00    movl   $0x179,0x4(%esp)
+    23cb:  c7 44 24 04 84 01 00    movl   $0x184,0x4(%esp)
     23d2:  00 
     23d3:  89 04 24                mov    %eax,(%esp)
     23d6:  e8 fc ff ff ff          call   23d7 <_ZN12RerouteAdapt11WriteToFileERKSs+0x79>

The ordering of the headers was not changed by the reformat.

I know some C/C++, but very little about assembly. I was wondering if there was a simple explanation for why the object file would change. I thought the C++ compiler (GCC 4.8.2 on RHEL 7) was indifferent to formatting and white space. There were no differences besides this in the assembly.

Answer 1

Thomas and Tim were correct. The value that changed corresponds to the line number before and after formatting. I assumed "logErr" was just a stream. Turns out it is a macro that uses the __LINE__ macro. So the line number is hard-coded in the assembly.

#define logErr theTracer().SetFuncName(__func__); theTracer().SetFile(__FILE__); theTracer().SetLine(__LINE__); theTracer().SetError(); theTracer()

Thank you for your help.