httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 14:49:56 GMT

> > What silently fail?  They are no-op's.  They don't DO anything, they
> > can't fail.
> Here is what I am calling a silent failure:
>   My program calls a library function and tells it to transform data in a
>   certain manner (e.g., convert from ISO8859-1 to UTS-16) but the
>   library function doesn't perform the transformation and doesn't tell
>   my program that it was unable/unwilling to do so.
> Practically always (i.e., I can't think of an exception), if I ask a
> library routine to do something (e.g., change the name of a file) and
> it can't/won't do it, then the library routine won't pretend that it
> really did it but instead will tell me about it.  Whether or not that
> is fatal to the operation in progress is for the caller of APR to be
> able to decide.

return APR_ENOTIMPL.  That is how we return that this is not implemented
in APR.

> > Look, there are two cases for codepage translation.
> > 
> > 1)  EBCDIC -> ASCII.  -- most platforms don't need this.  On platforms
> > that do, we execute a bit of code, on platforms that don't, it's a no-op.
> > 
> > 2)  charset encoding (any to any) -- we don't do this in 1.3.  Punt it for
> > 2.0.  It requires a change to the core code that IMO is too big for
> 2.0.
> You're talking Apache.  I'm talking that other beast -- APR.  I'll try
> to talk Apache briefly, though:

No, I'm talking APR through Apache.  There is a difference.  APR v1.0 is
being implemented for Apache.  We'll add more once 1.0 is out the door.  I
stated that having APR's iconv do EBCDIC->ASCII for 1.0 is "the right
thing", but anymore than that is wasted time/effort.  In later versions of
APR we can finish the work.  The fact is, not all Unix's have iconv.  This
is a problem.  However, we can easily re-implement this for all platforms,
but I suggest not trying to do this for v1.0.  Punt it to the next

> > This is an awful expensive operation for no gain at all.  I don't have a
> > better solution, but I dislike this one.
> I'm not sure what the gain is either.  I was sort-kinda looking for a
> way for it to make sense that the conversion functions return
> APR_SUCCESS when we don't have translation support, but that is an
> elusive (and to me misguided) goal.

Then return APR_ENOTIMPL, which is the correct code anyway.

> > There is no reason for this to be considered a failure.  The functions
> > shouldn't DO anything, so they can't fail.
> Let's agree to disagree on this one.  To me, if I tell a library
> routine to do something and it doesn't do it, that is a failure.  If
> the library routine lies about it and pretends that it really did what
> I told it to do, that is even worse.

And I gave you the solution.  :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message