httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 17:41:21 GMT
> > I don't buy the no-op argument.  It is not cool for an app to use APR
> > functions which translate from one codepage to another and for the
> > program not to be able to find out that nothing really  happened.
> > Actually, it isn't cool for an app to use any APR functions and have
> > them silently fail.
> 
> 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.

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

  As for Apache, generally the code needs to really know (e.g., via
  ifdef CHARSET_EBCDIC) when translation is needed.  There is more to
  translation than calling iconv().  We don't want the extra work that
  is needed in Apache-for-EBCDIC to slow down Apache-for-ASCII.  Your
  no-op macros don't solve the problem.  ifdef CHARSET_EBCDIC or
  similar is still needed.  MBCS capability is going to deviate a
  little more from the ASCII-only path than what is there is 1.3.

Back to APR...

> > I'd prefer that if there is no real translation support then we do a
> > memcpy if the source codepage and the destination codepage are the
> > same but we fail the ap_codepage_open() otherwise.
> 
> 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.

> > Is this the desired logic?  (I wondered what you meant since
> > you didn't use the autoconf-style preprocessor symbol.)
> 
> That's because it didn't work anyway.  :-)
> 
> > 
> > #ifndef HAVE_ICONV 
> > 
> >   spit out the no-op declarations/macros
> > 
> > #else
> > 
> >   spit out the real declarations
> > 
> > #endif
> 
> Yes.

agreed :)

> 
> > > Neither.  Why are we overloading things?  The lib directory is
> > > specifically meant for code that was moved from 1.3, and really shouldn't
> > > have anything added to it.  The misc directory is meant for things that
> > > don't fit anyplace else.  I am just as guilty as anybody of overloading
> > > misc.  Iconv implementations should have their own directory.  
> > 
> > Does that mean "use lib/apr/iconv/foo/apr_iconv.c" where foo is the OS?
> 
> Yep.

agreed :)

> ap_cp_open()
> ap_cp_close()
> ap_cp_conv_buffer()
> ap_cp_conv_char()

agreed, code changed already

> > -#if !defined(ICONV_IMPLEMENT)
> > 
> > I gather that your desire is that they fail at runtime but that the
> > application shouldn't know that they failed.  I didn't even realize
> > that this was a possibility.
> 
> 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.

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message