apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: rc and errno in apr api
Date Mon, 17 May 2004 17:41:21 GMT
Joe Orton wrote:
> On Sun, May 16, 2004 at 08:17:41PM -0700, Stas Bekman wrote:
>>What I'm after is having APR API specify which apr functions have errno 
>>set, so one can rely on that and not do guessing which can change in the 
> Do you mean, such that errno is guaranteed to be equal to the
> apr_status_t returned?  I don't think APR does/could/should give that
> guarantee anywhere.
> Yes, errno may be changed by any APR function as a side-effect, but not
> in a predictable manner.  Even with the Unix apr_file_read() you may get
> an apr_status_t returned which is different from errno if the mutex
> unlock call fails, for example...

OK, I understood - one can't rely on errno to be set and it just so happens 
that it gets set for certain calls on certain platforms under certain 
circumstances. Thank you.


The reason I've asked is this. Perl has its error variable $! tied to errno. 
So when you do:

   open $fh, "foo" or die "$!"

if open fails (e.g. "file not found", "perms denied"), the error will end up 
in $!. $! is a dual variable. In a numerical context it contains errno, in a 
string context it contains strerror(errno).

So since I've implemented Perl IO interface using APR (needed for those cases 
when an APR function returns apr_file_t which one may want to manipulate in 
perl, using the familiar perl API, I need to be able to propogate errors to 
the user. If I can't rely on errno being set, I can't give users $! as they 
are used to - I can't write idiomatic API and I need to provide an alternative 
way to give users the errors.

So when I've used open() in my tests I was getting $! working automatically, 
since apr_file_open() happened to use system calls that set errno, w/o apr 
doing that. So I hoped that it could be true for all other apr IO calls and 
I'll be able to give users a transparent experience. But as you suggest this 
is not the case. Oh, well, we will deal with that.

Thanks again!

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message