httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] APR wrapper for iconv
Date Tue, 18 Apr 2000 14:00:49 GMT

> >                                                      I can't live with the
> > second change.  MOST Unix platforms will want a no-op for the ICONV
> > stuff.  That is just a fact of life currently.  That preprocessor symbol
> > is what provides us with the information to determine whether iconv should
> > be a no-op or not.
> 
> 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.

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.

This cuts the problem space to a manage-able size IMHO.

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

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

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

> Somebody else can perhaps discuss code sharing further.  I just want
> to know explicitly where you want the code.

This has been discussed to death on this list.  Check the archives, check
the actual code.  If you need an example of how APR shares code, beos
files are using the Unix code.

> I am not sure what you mean by this.  Is this justification for
> duplicating iconv() usage among lib/apr/iconv/foo directories since
> different platforms/RTLs may have things called iconv() that don't
> work exactly the same way?

Yep.

> > What do you mean more consistent with iconv() or more consistent among
> > themselves?  Please specify where these aren't consistent with iconv.  I
> > have just checked the Single Unix specification, and iconv has:
> > 
> > iconv_open()
> > iconv_close()
> > iconv()
> 
> Here is the pattern I see in the iconv() functions...
> 
>   X_open()
>   X_close()
>   X()
> 
> What about your names?  The only consistent pattern I see is "ap_".
>                                          
> ap_codepage_open()                       A_Y_open()
> ap_translate_codepage()                  A_Z_Y()
> ap_translate_char()                      A_Z_char()
> ap_codepage_close()                      A_Y_close()

fine, valid point.  How about:

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

> +    
> +/* TODO: determine whether or not we always have these routines
> + * in APR and perhaps what to do if they aren't supported on
> + * some platforms (fail at compile time?  fail at link time?
> + * fail at run time?) */
> +   
> +#if defined(ICONV_IMPLEMENT_NYET)
>  
> -#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.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message