New Code! (let’s make gcc less whiny! edition)
Postoffice has been pushed up to version 1.4.5 to fix a minor bug and make gcc -Wall produce less terrifying output.
Bob Dunlop reported the bug, which was that spam=bounce wasn't setting spam=bounce, but was instead comparing the current spam setting to bounce and not doing anything with the result.
The code scrub was also suggested by Mr. Dunlop, who is trying to build postoffice on an ARM-based system; I decided that I'd do a sweep across the code myself to see what I could clean out. It was pretty easy to make gcc 2.7.2 stfu;
- Some simple housekeeping made gcc stop whining about variables being clobbered after longjmp() (I added a configure check for the volatile keyword, then plastered volatile prefixes on everything that gcc complained about; on systems that don't support volatile it #defines that keyword to an empty comment,)
- some minor code rework (forcing an assignment to a variable that wouldn't be set if a loop failed; previously I was failing the condition when loop counter==max,) and
- adding a test to configure to have it append -Wno-parentheses to CFLAGS if you're trying to build with the FSF compiler.(I combine assignments and tests by doing if ( var = setter() ), but the FSF style manual disapproves of this. So -Wall means that the silly compiler whines bitterly about this unless I add -Wno-parentheses to CFLAGS.
Newer versions of gcc, like the one that Apple uses on MacOS 10, have many more things they get hysterical about (the flux of const vs. non-const in headers is annoying enough, but newer perversions of C freak out about signedness as well. Sigh.)
But it's still New Code!, and it's New Code! where gcc -Wall is a little less chattery about things that don't fit the FSF programming stylebook.