On Thu, 2013-01-10 at 23:16 +0100, Tom Hendrikx wrote: > Yes, that is why I was discussing the different options available. > Adding another 17 switches for different scenarios is ugly, the existing > 6(!) already look disappointingly overcomplicated to me. So I'd be happy > to contribute a patch that contains an elegant solution, but not another > kludge that fixes only my stupid little issue but makes matters worse in > the long run. As said, creating a kludge in the surrounding code is just > as ugly, but much faster. > I don't think its as bad as you think. The major problem is that, not only is the set of the set of exit codes to be used configurable, but there is also a mandatory link to to some of the processing options. To me that's icky. However, I can't see why the processing options can't be entirely separated from the exit code set selection. Apart from making the code cleaner, it should also add flexibility.
The set of processing options with hard wired exit code linkages are --check -d and --learntype There only two sets of exit codes, which are directly controlled by --exitcode and --no-safe-fallback. I can see a good reason for keeping these, but having two options seems unnecessary. Besides, --exitcode is a horrible option name since it tells us very little. You could make the set controlled by --exitcode the default, remove the option and retain --no-safe-fallback to select fine-grained exit codes. I haven't looked at the spamc code since 3.2.25, but IIRC it was pretty straight-forward. I don't recall any show-stopping reasons why the hard-wired exit code linkages shouldn't be broken. Martin
