driver.exe -I -S default_driver.xml
This translates to "interactive" (-I), "simulated" (-S) and then the xml config file to use. Well today all of a sudden this command line was getting a slew of odd "unexpected argument" errors. We have been using the same argument parsing library http://graphics.stanford.edu/~drussel/Argument_helper/ for a few years so it was quite unbelievable that the library was at fault. We tried it on our machines and worked fine for us, but sure enough on his machine we could replicate the error. We figured it must be a memory corruption bug and pored through the code looking for anywhere where we could be borking the memory but couldn't find anything. Out of frustration we reordered the arguments and it started working as expected. Then we went back to the original order and it worked!
We puzzled over this for a while then we realized that we had told the engineer to copy the command line from the testing document. Turns out word had helpfully replaced one of the argument flag dashes with a dash doppelganger. It looks exactly like a dash but didn't have the ascii value for a flag, which is what our command line argument parsing library was looking for. What made this all the more frustrating was that copying and pasting this value into nearly anything else got the expected dash character. This included using the echo command to print copy/pasted command to a file. This crazy dash character doesn't even copy/paste consitently in word, if we select that character, hit control-F and search, it silently replaces it with a regular dash in the find box so that char doesnt even show up in the search of the file.
We have added a check to the command line parsing to make sure that all chars are in the standard ascii set (between ' ' and '~') so we don't get bit again.