From: "Jeff Trawick" <[EMAIL PROTECTED]> Sent: Friday, October 19, 2001 9:45 AM > > > I am very much against changing the API of an APR function temporarily. > > Returning the native exit code is not the correct solution to this > > problem, > > because that code can't really be used in a portable app. If the idea > > is to > > go to three variables in the function, and then move back to two, then > > just > > go straight to two. If the idea is to stick with three forever, then > > -1. > > no, the idea wasn't to go from 3 to 2; I think all three pieces of > information are necessary, but if you want to provide one of the > pieces of information via a different mechanism, then by all means > show us what you mean
Jeff... what if we return the two bits, APRized. Then offer an apr_os_foo result through an accessor? This will help identify non-portable applications (such as stacktrack/coredump uses) while avoiding the 'temptation' to write broken code in apr? Bill