apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]
Date Fri, 19 Oct 2001 15:27:17 GMT
From: "Jeff Trawick" <trawick@attglobal.net>
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?


View raw message