Re: Bug in libiconv?

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Jan 25 10:04, Charles Wilson wrote:
> On 1/25/2011 6:15 AM, Corinna Vinschen wrote:
> > - Why on earth is libiconv on Cygwin using Windows functions in some
> >   places?
> > 
> >   - libcharset/lib/relocatable.c
> >   - srclib/progreloc.c
> >   - srclib/relocatable.c
> >   - lib/relocatable.c
> 
> whoo boy. That's...a long story. It's all part of Bruno's magic
> relocatability machinery.  However, on cygwin it should be using unixish
> mechanisms (at least for exe's -- looking at /proc/$pid/exe.  For
> DLLs...I think it needs to keep using the DllMain approach).

Really?  Why can't you use the same mechanism as on Linux?  The
find_shared_library_fullname() function examines /proc/self/maps, which
is also available on Cygwin.  This was already available on 1.5!

> > - libcharset/lib/relocatable.c and srclib/relocatable.c define their own
> >   DllMain and use Windows functions.  And the old
> >   cygwin_conv_to_posix_path function as well.
> 
> Well, yes.  It's how DLLs determine their installation path, so they can
> then automatically deduce the relative path to <whatever>.  And since
> that requires using a win32 function (GetModuleFileName) it needs to
> convert to cygwin format.

See above.

> > - Same file, function locale_charset() contains old Cygwin-specific
> >   code which is outdated.  AFAICS it shouldn't hurt, though, since
> >   Cygwin no longer returns "US-ASCII".
> > 
> > - lib/iconv_open1.h and lib/iconv.c exclude Cygwin from the usage of the
> >   ei_ucs2internal encoding table.  I'm not sure if that's right or
> >   wrong, but it looks worrying.
> 
> Well, remember (A) upstream libiconv itself hasn't been updated since
> 30-Jun-2009, which predated cygwin 1.7.1 (23 Dec 2009), and (B) even our
> most recent version (1.13.1-1) was released almost simultaneously (23
> Dec 2009) -- and there was a LOT of shakeup in all that stuff from 1.7.1
> thru 1.7.5.

I wasn't trying to blame you.  I was just trying to point out potential
problems which deserve a more POSIXy handling on Cygwin.

> > Please note that I defined
> > __STDC_ISO_10646__ for Cygwin 1.7.8 yesterday.  This define is
> > missing since 1.7.2.
> 
> Hmmm...maybe I should (re)build libiconv against a snapshot?

I think that should be safe.  There's most likely no new API which would
accidentally be pulled in by libiconv(*).


Corinna


(*) Famous last words...

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple