apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: apr-iconv 1.0
Date Wed, 30 Mar 2005 06:36:30 GMT

On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:

> At 10:09 PM 3/29/2005, Curt Arnold wrote:
>> I'm unclear on the proposed resolution.  Does it include a mechanism 
>> to distinguish apriconv-1 encoding modules from apriconv-0 modules 
>> either by changing the module signature or name?
> I believe we should do that, too.  But it seems that some want
> us to use an 'external' iconv implementation, at least, as of
> the next major release of apr-util.  With the files residing
> in /apriconv-1/*.so I'm less concerned with the signature.

Are you expecting the apriconv-1 directory to be on the PATH or 
LD_LIBRARY_PATH or relative to a directory on the PATH or 
LD_LIBRARY_PATH?  If it is on the PATH or LD_LIBRARY_PATH, then this is 
the continued possibility of collision with modules from other iconv 
implementations, if it is relative to an directory on the path, then I 
would expect that you would need add a decent amount of complexity to 
accomplish that.  I would think it may be simpler to have modules named 
apriconv-1-ENCODING.so or .dll and have dlopen or LoadLibrary find them 
with their existing library search mechanisms, but I could understand 
if that was undesirable for other reasons.

>> Without some mechanism to distinguish encoding modules, it really 
>> doesn't matter what order the paths are evaluated?  If there is a 
>> mechanism, it shouldn't hurt to evaluate APR_ICONV_PATH first?
> Of course it would, because we would still have to iterate
> multiple .so files to find the correct one.  This is a huge
> performance hit.
> So let me inquire - have you authored a custom (charset).so file,
> or intend to do so?

No, I have no intention to do that.  At this point, the resolution to 
the issue does not effect log4cxx since it will continue to hack 
apriconv to embed the encodings into log4cxx.dll and liblog4cxx.so.  
You need to do what is right for httpd and/or Subversion.

> Again, the consensus on list was that apr-iconv
> was an implementation-internal detail of apr-util.  With the next
> release, implementors/users are expected to install the directory
> apriconv-1 in parallel to apriconv-1.so [.dll].  APR_ICONV_PATH
> would be searched last, to pick up those exceptions/custom charset
> modules.  We wouldn't hit iconv/ at all (unless the user asks us
> to through APR_ICONV_PATH.

Since Subversion sets APR_ICONV_PATH, there is still the possibility of 
finding an apriconv-0 encoding module if the installation is damaged 
(or the developer decides not to distribute some obscure encoding) or a 
new encoding gets added to Subversion and/or apriconv-0.

> So I'm confused if this solution doesn't resolve the issues of all
> users.  Please explain further.
> On your point of avoiding conflicts by changing the signature, yes
> I would be -happy- to entertain a patch, if you want to post one in
> the next day.  I'll be putting together my changes tomorrow eve,
> and would be easily able to integrate your suggestion if you care
> to offer the patch.  I don't see it as a substitute for searching
> for the right file, but I see it as added security against loading
> the wrong module.

By changing the signature, I meant changing the value of ICMOD_UC_CCS 
and ICMOD_UC_CES (currently 0x100 and 0x101).  I don't know if this 
method of module identification is used elsewhere and if so, what other 
values are currently in use.  If the encoding modules can't be 
distinguished by name, I think it is essential that they have a 
different magic value.  Otherwise, you are just reducing the chances of 
a catastrophic failure by checking APR_ICONV_PATH last, not eliminating 

Putting myself in the position of the developer of some hypothetical 
app (and I couldn't have an iconv2 based solution), I would prefer that 
apriconv-1 encoding modules be named something like 
"apriconv-1-utf-8.dll" or "libapriconv-1-utf-8.so" and located using 
the established library search algorithms in dlopen or LoadLibrary.  In 
deployment, these would likely be placed in the same directory as 
aprutil-1.dll or libaprutil-1.so or the executable if linked against a 
static aprutil-1.  APR_ICONV_PATH could be ignored.  If the user really 
wanted a new encoding, they could either place it in an already 
searched directory or add the directory to PATH or LD_LIBRARY_PATH.

However, it would be good if we could get some comment from a 
Subversion developer.

View raw message