httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 19:11:49 GMT
On Tue, 18 Apr 2000 wrote:
> > > 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.

In defense of Jeff... Ryan: you were totally unclear on this. You said
make them a no-op. Not return APR_ENOTIMPL.

Jeff was entirely right when he said that they cannot be no-ops.

> 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
> version.

Bogus argument. Jeff has the time and inclincation to do this work. You
cannot tell him "don't do that" or that the time is wasted. He doesn't
feel the same.

Ryan: you initially put those functions in on the fly, without much
thought towards them. I don't see how you can now say "they've been in
there for three months, so you can't change the function names" or that
they should remain in their "quick solution" state.

Jeff is fixing/improving a documented API. I see nothing wrong with that.

> > > 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.  :-)

Not at first. From my standpoint, you were saying something entirely
different. And bogus: a routine like this cannot a no-op.

btw, +1 on Jeff's changes.


Greg Stein,

View raw message