How to compare 2 execution files

[Hannibal2010]

Dear all,

Now I have a C programming.

I want to delete some redundancy code from this existing code. (this code is between #ifdef and #endif, and does not be compiled, so I can remove them)

But, how can I sure that, the program is not affected.

I think, because Compiler ignore code between directives, so the execution file after compile are the same.

I checked it, but they are different.

Anyone can help me, give me an idea to test the new code after delete some unused code?

[whiteflags]

The simplest example of conditional compiling I can think of is this:

#if 0
printf("Hello, World!\n");
#endif

With this, there is no condition under which the printf will be executed, so the preprocessor (the step in the build cycle that occurs before the compiling) will always remove it. In the real world the condition is probably not zero, but the result is the same, no matter what the code actually is, whenever the condition is false.

With part of the code simply redacted, the executable is smaller naturally.

[Hannibal2010]

Dear whiteflags,

I understand your idea.

I mean, I know that the conditional (for example, #ifdef SOMETHING) always wrong, and I can remove the code between without fear.

But, I need to prove my modification does not affect to the program. I know that, but I have to prove to other members.

How can I prove this?

[grumpy]

Google "propositional logic" or "propositional calculus".

Note that testing (for example, comparing executables produced before and after removal of a particular section of code) does not constitute a proof.

[Hannibal2010]

Dear,

So, how can I test now? Note that the test cases set is very large, so I don't want to test again.

[Salem]

> I checked it, but they are different.
How did you check it?

If you did some kind of binary comparison, then there are several things which could hinder a simple "compare".

- the compiler / assembler / linker may insert a "build time" string into the executable.
- the linker may re-order objects in memory.

The short answer would be to compile the SAME code twice, then compare just to learn what kind of "differences" are present between successive builds.

> But, I need to prove my modification does not affect to the program. I know that, but I have to prove to other members.
You can't.
You're basically asserting that the C pre-processor is "bug free" by saying that there is no difference in the executable.

It really depends on how rigorous you want to be about your compiling and test.

But if you take the example where the linker has re-ordered things, then perhaps what was a benign buffer overrun before hand, it suddenly turns into some random crash. You then add some code to try and trace the problem and it goes away again.

[tabstop]

This seems really irrelevant, for if the #ifdef is, in fact, always false, then the code will never appear in your program since it will never even be passed to the compiler. If you are seeing something different, then....

[dwks]

You could generate the assembly for the two versions of the program (e.g. "gcc -S file.c"), and compare those. You're more likely to be able to tell what constitutes an actual source change and what is just the compiler inserting different strings.

[brewbuck]

The compiler may generate different output from run to run even on the same source.

Step 1: Prove the code is dead. If it's literally inside an "#if 0" then the code is dead. The only way it could be included is if there is a bug in the compiler. You can test it by placing some kind of syntax error inside the ifdef'd section. If it's getting parsed the compiler will throw an error. No error means the code isn't being compiled.

Step 2: Remove the dead code.

Step 3: Re-run all the relevant tests. The results should be identical.

That's enough for any reasonable people I've ever worked with. If the compiler inherently reorders stuff based on the time of day, the presence of dead code, etc, you'll never be able to factor that out completely. You should be relying on your test set to find bugs, not speculating on the color of the sky.

[quzah]

Step 1: Prove the code is dead. If it's literally inside an "#if 0" then the code is dead. The only way it could be included is if there is a bug in the compiler. You can test it by placing some kind of syntax error inside the ifdef'd section. If it's getting parsed the compiler will throw an error. No error means the code isn't being compiled.

And that is absolutely easy to prove to anyone who has ever compiled anything:

#if 0
AJG:#@J:GJ@#(:GJP @#G# (GJ:#@(G #@:G
@#TGK(@#G@#GK@#{PG
@G)@#JG(P@{#GJ 
LOOK MA IT COMPILES STILL!
FJ(#FJWFJ)W(#F)WFJ
WFJW)(F#WJFW
#endif

That's enough for any reasonable people I've ever worked with.

To add to what Brewbuck has said, if they don't have that basic level of the preprocessor, then they shouldn't be the one telling you what to do.


Quzah.

[grumpy]

That's enough for any reasonable people I've ever worked with.

Clearly you have not worked with high criticality systems (for example, situations where a code malfunction may kill people).

In the high criticality arena, it is also necessary to offer highly convincing arguments (or proofs) that;

1) Requirements of the system are captured correctly.

2) Every feature of the design is derived unambiguously and correctly from a set of requirements [this means the design cannot introduce features that do not satisfy requirements].

3) Every requirement is satisfied unambiguously and correctly by some set of design features.

4) Every section of code unambiguously and correctly implements a non-empty set of design features and requirements.

5) The output of each development tool (such as the compiler) is an unambiguous and correct translation of the input code (and therefore also of the design and the original requirements).

6) The output of each development tool does not introduce new features that are not reflected in the design or requirements.

7) Every feature of the executable is a consequence of the code, the design, AND the requirements.

If tests are being used to provide evidence of the above, then it is necessary to justify a claim that the tests are both necessary and sufficient for the purpose they are being used.

[brewbuck]

Clearly you have not worked with high criticality systems (for example, situations where a code malfunction may kill people).

I have not, but I am aware of all that. I assumed that somebody working on such a system would not be asking for advice in this particular forum.

[tabstop]

Clearly you have not worked with high criticality systems (for example, situations where a code malfunction may kill people).

Obviously we don't have the actual situation, but (if we assume OP is correct) changing the comments cannot affect the performance of the code.

[_Mike]

Step 1: Prove the code is dead. If it's literally inside an "#if 0" then the code is dead. The only way it could be included is if there is a bug in the compiler. You can test it by placing some kind of syntax error inside the ifdef'd section. If it's getting parsed the compiler will throw an error. No error means the code isn't being compiled.

And that is absolutely easy to prove to anyone who has ever compiled anything:

#if 0
AJG:#@J:GJ@#(:GJP @#G# (GJ:#@(G #@:G
@#TGK(@#G@#GK@#{PG
@G)@#JG(P@{#GJ 
LOOK MA IT COMPILES STILL!
FJ(#FJWFJ)W(#F)WFJ
WFJW)(F#WJFW
#endif

To add to what Brewbuck has said, if they don't have that basic level of the preprocessor, then they shouldn't be the one telling you what to do.

While I agree with the general method I think a more elegant solution would be to use #error with some descriptive text.
Since they are multiple people working on the same code base and on the off-chance that this piece of code happens to get processed because of some other team member using a different set of compiler switches it would probably seem very strange to them if the compiler fails because someone randomly bashed the keyboard, whereas a simple

#error "Obsolete code.. If you see this error please update your compiler switches / makefile"

would be much more understandable

[quzah]

While I agree with the general method I think a more elegant solution would be to use #error with some descriptive text.
Since they are multiple people working on the same code base and on the off-chance that this piece of code happens to get processed because of some other team member using a different set of compiler switches

I am unaware of any such compiler switch that will translate#if 0 into #if !0. My point wasn't to be more elegant, but to easily prove to anyone with half a brain that #if 0 guarantees unreachable code.


Quzah.