Sunday, June 6, 2010

An interesting finding about compilers

In our binary world of software, a set of consistent in-volatile variables has one and only one path it can take through a static codebase. Bugs exist because variables are never consistent or in-volatile; except during unit testing. Unit testing should use a large enough data set to test all possible variable combination sets, but it is nearly impossible to thoroughly unit test certain codebases (eg codebase for a user experience), thus bugs exist.

However, what do you do when your set of variables passing through a static codebase is the same, with two exceptions.
1) user input timing
2) compiler optimization options

Case: "Backwards Find in Windows & TDM of Mingw"
I cannot be entirely scientific with this. Heck this is a blog post and I've found a workaround for my problem. I highly encourge you "the reader" to investigate this more thoroughly and tell me I've overlooked some stupid thing

Problem Desc: When using the backwards find in Codeassistor, backwards find does not wrap around to the bottom of the sourcefile and search upwards for the search term if the search term cannot be found from the current point of the cursor to the beginning of the sourcefile. Unless the codebase is compiled using the -O0 optimization option.

Steps to reproduce
1) grab the codeassistor source and the mullinpatches branch of scintilla.
2) compile the code via "make -f -j5"
3) after the test application has popped up, press CTRL+F for find and type "ei" (no quotes) then ENTER.
4) Alt+Tab from the find popup to the editor window
5) press F3 for backwards search multiple times

Expected Result:
The editor will jump to the bottom and find the last occurrence of the string "ei"

Actual Results:
The editor will highlight the second character of the sourcefile (in this case a "*")

6) Quit Codeassitor; type "make -f clean" ENTER
7) Edit and change -Os to -O0
8) repeat steps 2-5

Results (expected and actual):
The editor will jump to the bottom and find the last occurrence of the string "ei"

It seems like the -Os (for that matter all -O optimization except O0) performs the test one way, and the -O0 performs another way.

-Os drops my final executable IN HALF! from 250KB to 124KB. I am not supremely concerned about this because 250 is acceptably small... but what happens if my executable grows to be 10MB ? I would much prefer a 5MB exe to a 10MB one.

Note: the bug might be in the codeassistor, however the code is acting differently to a non-volitle (except user timing) dataset depending on compiler option.

No comments: