Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <40A88633.7070000@algroup.co.uk>
Date: Mon, 17 May 2004 10:30:27 +0100
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: Stas Bekman <stas@stason.org>
Cc: APR Development <dev@apr.apache.org>
Subject: Re: rc and errno in apr api
References: <40A82ED5.5000901@stason.org>
In-Reply-To: <40A82ED5.5000901@stason.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:

> I have noticed that besides apr_status_t many of the apr api functions 
> get errno set on error, since they perform system calls internally, 
> which set errno. e.g. apr_file_read.
> 
> While writing interfaces for other systems, that talk to libapr, and use 
> errno for the errors handling, it's not possible to simply set errno to 
> apr_status_t returned by some apr calls, since in several cases that 
> code/errstr is specific to apr and there will be no equivalent in the 
> errno posix land. So there is no 1:1 mapping between apr_status_t and 
> errno. When there is a mismatch some alternative solution is out to be 
> found.
> 
> 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 
> future. For example it seems that apr_file_read will always have errno 
> set on failure. But I have no idea about other functions, especially 
> since there are several platform specific implementations of each.

This doesn't make sense to me:

a) It would be impossible to fulfill the guarantee sensibly (we'd 
potentially have to fudge errno if we changed the implementation).

b) It would almost certainly vary according to platform.

c) The errors we return are apr_status_t - if you can't represent them 
as errno, then don't use errno!

If you are really forced to use errno, then just pick some value that's 
as close as you can get for apr_status_t you can't represent.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff