public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: Bug in libiconv?
@ 2011-01-26 13:39 simrw
  2011-01-26 13:50 ` Corinna Vinschen
  0 siblings, 1 reply; 32+ messages in thread
From: simrw @ 2011-01-26 13:39 UTC (permalink / raw)
  To: cygwin

> Here's what happens on Cygwin:
>
> $ gcc -g -o ic ic.c -liconv
> $ ./ic
> iconv: 138 <Invalid or incomplete multibyte or wide character>
> in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7,
outbytesleft = 492
>   iconv: 138 <Invalid or incomplete multibyte or wide character>
>   in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7,
outbytesleft = 492
>   iconv: 138 <Invalid or incomplete multibyte or wide character>
>   in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7,
outbytesleft = 492
>   in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 480
>
> So, AFAICS, there are two problems:
>
>   - Even though iconv_open has been opened explicitely with "UTF-8" as
>     input string, the conversion still depends on the current application
>     codeset.  That dsoesn't make sense.
>
>   - Even though the last parameter to iconv is defined in bytes, the
>     value of outbytesleft after the conversion is the number of remaining
>     wchar"t's, not the number of remaining bytes.  That's contrary to
> what POSIX defines, see
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html

IMHO, the count is correct.
On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes.
So the buffer is 512 bytes.
In the first 3 cases, 10 input bytes were consumed so that there remains
in the buffer (512 - 20) = 492 bytes.
In the last case all 16 bytes are consumed so there remains in
the buffer (512 - 32) = 480 bytes.

Roger


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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Bug in libiconv?
@ 2011-02-02 18:58 Bruno Haible
  2011-02-02 21:20 ` Corinna Vinschen
  0 siblings, 1 reply; 32+ messages in thread
From: Bruno Haible @ 2011-02-02 18:58 UTC (permalink / raw)
  To: cygwin

[resent to the cygwin list; please add bug-gnu-libiconv to your replies]

Hi Corinna,

Thanks for your reply <http://cygwin.com/ml/cygwin/2011-01/msg00410.html>

> > Please CC the bug-gnu-libiconv mailing list when discussing possible
> > bugs in GNU libiconv.
>
> Ok

Thanks for giving it a try. But although you CCed bug-gnu-libiconv, your message
did not reach the list (but Charles' one and Eric's one did). I guess this is
because the cygwin.com mail server refuses to deliver to corinna-cygwin,
therefore the spam detection at gnu.org recognized your sending address as a
spammer's one. This makes it hard for me to detect that you replied to me,
since I'm not reading the cygwin mailing list on a regular basis.

> > I don't think defining __STDC_ISO_10646__
> > is compliant with ISO C 99 in this situation.
> > ...
> I don't read that from your above quote.  The core is that the *type*
> wchar_t is a *coded* *representation* of the characters defined in
> 10646.

OK.

> > What is the Cygwin wchar_t[] encoding? Is it UTF-16, like on Win32?
> Yes.
> ...
> yes, for the forseeable future, Cygwin will define wchar_t == UTF-16.

Thanks for confirming it. I've started thinking about how gnulib can
cope with it, now.

> I've put a lot of effort in 2009 and early 2010 to make the wchar_t
> representation in Cygwin and newlib as much Unicode 5.2 compatible as
> possible.  Even the wcrtomb and mbrtowc functions in newlib are capable
> of dealing with UTF-16 surrogates.

I appreciate your effort on internationalization of Cygwin. You went as
far as you could get with the given choice of wchar_t. It's just a fact
that the <wctype.h> functions and wcwidth() cannot work right when wchar_t[]
is UTF-16. And these functions are the only reasons why gnulib and coreutils
code uses wide characters strings at all.

I'm not criticizing the Cygwin choice. Even if Cygwin had chosen to define
'wchar_t' to a 32-bit type, the same problem would have remained for mingw
programs running in UTF-8 or GB18030 locales. (I understand that such
locales exist in Windows 7.)

> I don't quite grok the code at this point:
> 
>   #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__
>       if (sizeof(wchar_t) == 4) {
>         index = ei_ucs4internal;
>         break;
>       }
>       if (sizeof(wchar_t) == 2) {
>         index = ei_ucs2internal;
>         break;
>       }
>       if (sizeof(wchar_t) == 1) {
>         index = ei_iso8859_1;
>         break;
>       }
>   #endif
> ...
> I *don't* understand that you do the same for Win32.  Old
> Windows versions are using the basic UCS-2 character plane, but newer
> versions, at least since Windows XP are using UTF-16.

Thank you for this remark. I have corrected this in libiconv, and also
added support for Cygwin >= 1.7 at the same place.

> > > the application tests to convert a UTF-8 to WCHAR_T string in four
> > >   combinations of the current locale, in this order:
> > > 
> > >   - iconv_open "C",       iconv "C"
> > >   - iconv_open "C",       iconv "C.UTF-8"
> > >   - iconv_open "C.UTF-8", iconv "C"
> > >   - iconv_open "C.UTF-8", iconv "C.UTF-8"
> ...
> My testcase is a result of trying
> to build a real-life application, gencat from glibc.  For some reason
> gencat thinks it has to set the locale back to "C" in a hardcoded manner.
> 
> This works fine for glibc systems, but the invisible and, IMHO,
> intransparent behaviour of libiconv on other systems makes it pretty
> hard to understand the behaviour of an application when porting it.

I don't see this as a particular "intransparent behaviour of libiconv".
When taking code that was tested only in a single environment (glibc in this
case), you always have to make some effort to make it portable.

> > Is cygwin_conv_to_posix_path deprecated? Does it introduce limitations of
> > some kind?
>
> Like the underlying Windows functions, Cygwin 1.7 now supports paths of
> up to 32K chars.  The old cygwin_conv_to_posix_path function and it's
> friends are written with the Windows ANSI API in mind, so they only
> support paths of up to MAX_PATH == 260 chars.

Thanks for explaining. I'll try to avoid this function.

> > > The usage of a fixed table instaed of the charset.alias file in
> > > libcharset/lib/localcharset.c, function get_charset_aliases() is
> > > not good, not good at all.
> > 
> > The alternative is to have this table stored in a file charset.alias;
> > but then every package that includes the module 'localcharset' from
> > gnulib (that is, libiconv, gettext, coreutils, and many others) will
> > want to modify this file during "make install". And this causes a lot of
> > headaches to packaging systems. Therefore, on platforms which have
> > widely used packaging systems (Linux, MacOS X, Cygwin), it's better to
> > avoid the need for this file.
> 
> Now I'm puzzled.  If that's the case, why does libiconv request the
> charset.alias file on *any* other system than DARWIN7, VMS, and Windows?
> Especially on Linux?

I "optimized" only the MacOS X, VMS, and Windows OSes. It would have been
more work to optimize all versions of Solaris, FreeBSD, AIX, etc. in the
same way.

charset.alias is requested on Linux, even though it normally does not exist,
so that packagers and users have a chance to modify the behaviour.

> Additionally, the fixed, Windows-centric table in libiconv removes the
> ability of a system to define their own set of aliases.  Also,
> Cygwin/newlib already handles the Windows codepages by itself.

There are a couple of places in gnulib, coreutils, gettext, that do some
decisions based on encoding of the current locale. In these places, I want
to use a single name for each encoding and not have to list all possible
aliases that any system on the world can use for it.

If a system adds new aliases, such as e.g. Solaris uses "PCK" when it means
"Shift_JIS", this needs to be handled in localcharset.c. There is no
system defined API for resolving these aliases.

Even if Cygwin/newlib handles Windows codepage aliases in all places where
it matters for Cygwin, there are still places where it matters for gnulib,
coreutils, gettext.

> > Neither libiconv nor gettext defines or undefines _WIN32 or __WIN32__.
> > But they are prepared to either setting.
>
> Isn't that just covering a PEBKAC?  I mean, there's no good reason to
> define -mwin32 on the command line and the libiconv configure certainly
> doesn't add it.  Whoever squeezed a -mwin32 onto the GCC command line,
> or even defined -D__WIN32__ manually, deserves the result.

But such a user will then write a mail to a mailing list, and it will take
time for me (or someone else) to investigate and answer it. By writing
  #if (defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__
I avoid this potential problem.

Thanks again for your reply and for the hint to the bug in libiconv's code.

Bruno
-- 
In memoriam Carl Friedrich Goerdeler <http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler>

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Bug in libiconv?
@ 2011-01-29  2:15 Bruno Haible
  2011-01-29 12:34 ` Charles Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Bruno Haible @ 2011-01-29  2:15 UTC (permalink / raw)
  To: cygwin, Corinna Vinschen, Charles Wilson, bug-gnu-libiconv

Hi Corinna and Chuck,

Please CC the bug-gnu-libiconv mailing list when discussing possible
bugs in GNU libiconv.


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00292.html>:

> the application tests to convert a UTF-8 to WCHAR_T string in four
>   combinations of the current locale, in this order:
> 
>   - iconv_open "C",       iconv "C"
>   - iconv_open "C",       iconv "C.UTF-8"
>   - iconv_open "C.UTF-8", iconv "C"
>   - iconv_open "C.UTF-8", iconv "C.UTF-8"
> 
> Here's what happens in Linux:
> 
>   $ gcc -g -o ic ic.c
>   $ ./ic
>   in = <Liian pitkà sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
>   in = <Liian pitkà sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
>   in = <Liian pitkà sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
>   in = <Liian pitkà sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
> 
> Here's what happens on Cygwin:
> 
>   $ gcc -g -o ic ic.c -liconv
>   $ ./ic
>   iconv: 138 <Invalid or incomplete multibyte or wide character>
>   in = <Liian pitkà sana>, inbuf = <à sana>, inbytesleft = 7, outbytesleft = 492
>   iconv: 138 <Invalid or incomplete multibyte or wide character>
>   in = <Liian pitkà sana>, inbuf = <à sana>, inbytesleft = 7, outbytesleft = 492
>   iconv: 138 <Invalid or incomplete multibyte or wide character>
>   in = <Liian pitkà sana>, inbuf = <à sana>, inbytesleft = 7, outbytesleft = 492
>   in = <Liian pitkà sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 480

On glibc systems, the encoding "WCHAR_T" is equivalent to "UCS-4" with machine
dependent endianness and alignment. In particular it is independent of the
locale. That explains the first set of results.

In libiconv, on systems which don't define __STDC_ISO_10646__, the encoding
"WCHAR_T" is equivalent to wchar_t[], that is, dependent on the locale.
Changing the locale encoding after allocating an iconv_t from or to "WCHAR_T"
yields undefined behaviour. That explains the second set of results.


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00299.html>:

> I defined __STDC_ISO_10646__ for Cygwin 1.7.8 yesterday.

What is the Cygwin wchar_t[] encoding? Is it UTF-16, like on Win32? The
documentation is silent about it. I had expected to find some word about it
in <http://cygwin.com/cygwin-api/compatibility.html#std-susv4>
or <http://cygwin.com/cygwin-api/std-notes.html>.

In any case, sizeof (wchar_t) == 2. I don't think defining __STDC_ISO_10646__
is compliant with ISO C 99 in this situation. ISO C 99 section 6.10.8.(2) says:

  __STDC_ISO_10646__
          An integer constant of the form yyyymmL (for example,
          199712L), intended to indicate that values of type wchar_t are the
          coded representations of the characters defined by ISO/IEC 10646,
          along with all amendments and technical corrigenda as of the
          specified year and month.

But when characters outside the basic plane, such as
U+12345 (CUNEIFORM SIGN URU TIMES KI), are encoded by 2 consecutive wchar_t
values, values of type wchar_t don't correspond to ISO/IEC 10646 characters.
(Or maybe I'm underestimating what "coded representations" means...?)


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00357.html>:

>   #if __STDC_ISO_10646__ || ((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__)
> This should be
> ...
>   #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__ || defined __CYGWIN__

That makes sense if Cygwin guarantees that from now on and in the future,
the wchar_t encoding will always be UTF-16. Is this the case?


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00299.html>:

> Why on earth is libiconv on Cygwin using Windows functions in some
> places?

So that I could reuse the essentially same code on Cygwin as on native Win32.

Charles has submitted a patch on this topic to bug-gnulib; I will handle it.

> the old cygwin_conv_to_posix_path function as well.

Is cygwin_conv_to_posix_path deprecated? Does it introduce limitations of
some kind?

> The usage of a fixed table instaed of the charset.alias file in
> libcharset/lib/localcharset.c, function get_charset_aliases() is
> not good, not good at all.

The alternative is to have this table stored in a file charset.alias;
but then every package that includes the module 'localcharset' from
gnulib (that is, libiconv, gettext, coreutils, and many others) will
want to modify this file during "make install". And this causes a lot of
headaches to packaging systems. Therefore, on platforms which have
widely used packaging systems (Linux, MacOS X, Cygwin), it's better to
avoid the need for this file. Additionally, on Win32 systems relocatability
is a must, and the code to compute the location of charset.alias from
the location of libiconv.dll would be overkill.


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00303.html>:

> It looks like there's been some bitrot with respect
> to some of the "&& !CYGWIN" guards on WIN32.  Both libiconv and gettext,
> IIRC, jump thru hoops to ensure that [_]*WIN32 is defined for both
> "regular" win32 and for cygwin...which means defined(CYGWIN) guards are
> necessary.

The reason for these "&& !defined __CYGWIN__" clauses is that - at least
in Cygwin 1.5.x - gcc has an option that will define _WIN32 or __WIN32__.
So, when _WIN32 || __WIN32__ may evaluate to true on Cygwin, or it may
evaluate to false on Cygwin. Since I don't want libiconv or gettext
to be compiled in two possible ways on Cygwin, I add
"&& !defined __CYGWIN__".

Neither libiconv nor gettext defines or undefines _WIN32 or __WIN32__.
But they are prepared to either setting.


Replying to <http://www.cygwin.com/ml/cygwin/2011-01/msg00332.html>:

> there ARE still bugs in libiconv on Cygwin -- specifically:
>  - Even though iconv_open has been opened explicitely with "UTF-8" as
>    input string, the conversion still depends on the current application
>    codeset.  That doesn't make sense.

If the other argument to iconv_open is "CHAR" or "WCHAR_T", hence locale
dependent, and you change the locale in between, the result is undefined
behaviour.

>  - 'iconv_close ((iconv_t) -1);' crashes the application with a SEGV.

It's not a bug. From POSIX:2008
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv_open.html>
you can infer that (iconv_t) -1 is not a "conversion descriptor". It's a
return value used from iconv_open(), nothing more. From
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv_close.html>
you can see that the argument of iconv_close() has to be a conversion
descriptor. From the ERRORS section in the same page you can see that
iconv_close() is not required to catch a faulty argument. Note the word
"may", not "shall".


Bruno

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Bug in libiconv?
@ 2011-01-27 16:06 simrw
  0 siblings, 0 replies; 32+ messages in thread
From: simrw @ 2011-01-27 16:06 UTC (permalink / raw)
  To: cygwin

> If that doesn't correct the issue...then I'd try to run your test case
> on linux, but *explicitly* using libiconv on that system, rather than
> (as is typically the case on linux) relying on the underlying glibc
> implementation of iconv functionality.
>
> Did this.  Here are the characteristics of the test case object and
> executable:
>
> $ ldd ./foo
>         linux-vdso.so.1 =>  (0x00007fff51928000)
>         libiconv.so.2 => /home/me/libiconv/_inst/lib/libiconv.so.2
> (0x00007f0b7d7dd000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003d5b400000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003d5b000000)
> $ nm foo.o | grep ' U '
>                  U __errno_location
>                  U exit
>                  U fprintf
>          >>      U iconv
>          >>      U iconv_close
>          >>      U iconv_open
>                  U printf
>                  U setlocale
>                  U stderr
>                  U strerror
>                  U strlen

IMHO, that is not correctly compiled. You are still using
the version in glibc.
libiconv only has "libiconv_open", "libiconv_close" and "libiconv".
Looks like there is missing include path.
eg.
gcc -I/home/me/libiconv/_inst/include -o foo foo.c
-L/home/me/libiconv/_inst/lib -liconv

iconv.h in libiconv has eg.
#define iconv_open libiconv_open

The "nm" should look like this -
                 U __errno_location
                 U exit
                 U fprintf
                 U libiconv
                 U libiconv_close
                 U libiconv_open
                 U printf
                 U setlocale
                 U stderr
                 U strerror

Roger


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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Bug in libiconv?
@ 2011-01-25  6:36 Corinna Vinschen
  2011-01-25 11:15 ` Charles Wilson
  0 siblings, 1 reply; 32+ messages in thread
From: Corinna Vinschen @ 2011-01-25  6:36 UTC (permalink / raw)
  To: cygwin

Hi Chuck,
hi everyone else,


In a twisted turn of events, I'm trying to get the orphaned catgets
package to work correctly on Cygwin 1.7.  As you might know, the package
is derived from the glibc package.  Apart from other portability issues
of this *very* glibc-centric piece of code, I found some problem which
appears to point to two bugs in Cygwin's libiconv2.

For some reason, the iconv conversion seems to be overly dependent on
the usage of setlocale, and the returned value in the fourth parameter
appears to be incorrect, if the output codeset is "WCHAR_T".

Here's a simple testcase:

==== SNIP ====
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <iconv.h>
#include <locale.h>
#include <wchar.h>

iconv_t
open_iconv ()
{
  iconv_t cd_towcp = iconv_open ("WCHAR_T", "UTF-8");
  if (cd_towcp == (iconv_t) -1)
    {
      fprintf (stderr, "iconv_open: %d <%s>\n", errno, strerror (errno));
      exit (1);
    }
  return cd_towcp;
}

void
run_iconv (iconv_t cd_towcp, char *input)
{
  wchar_t out[256];

  char *inbuf = input;
  size_t inbytesleft = strlen (inbuf);
  char *outbuf = (char *) out;
  size_t outbytesleft = sizeof (out);
  size_t ret = iconv (cd_towcp, &inbuf, &inbytesleft, &outbuf, &outbytesleft);
  if (ret == (size_t) -1)
    fprintf (stderr, "iconv: %d <%s>\n", errno, strerror (errno));
  printf ("in = <%s>, inbuf = <%s>, inbytesleft = %zd, outbytesleft = %zd\n",
	  input, inbuf, inbytesleft, outbytesleft);
}

int
main ()
{
  iconv_t cd_towcp;
  char *finnish = "Liian pitk\303\244 sana";  // Umlaut-a
  
  setlocale (LC_ALL, "C");
  cd_towcp = open_iconv ();
  setlocale (LC_ALL, "C");
  run_iconv (cd_towcp, finnish);
  setlocale (LC_ALL, "C.UTF-8");
  run_iconv (cd_towcp, finnish);
  iconv_close (cd_towcp);
  
  setlocale (LC_ALL, "C.UTF-8");
  cd_towcp = open_iconv ();
  setlocale (LC_ALL, "C");
  run_iconv (cd_towcp, finnish);
  setlocale (LC_ALL, "C.UTF-8");
  run_iconv (cd_towcp, finnish);
  iconv_close (cd_towcp);

  return 0;
}
==== SNAP ====

Here are the important details:

- The input string is a fixed finnish UTF-8 sentence containing a
  single non-ASCII char.

- The testcase always calls setlocale before calling iconv_open(),
  then subsequently it sets setlocale before calling iconv().

- So the application tests to convert a UTF-8 to WCHAR_T string in four
  combinations of the current locale, in this order:

  - iconv_open "C",       iconv "C"
  - iconv_open "C",       iconv "C.UTF-8"
  - iconv_open "C.UTF-8", iconv "C"
  - iconv_open "C.UTF-8", iconv "C.UTF-8"

Here's what happens in Linux:

  $ gcc -g -o ic ic.c
  $ ./ic
  in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
  in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
  in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960
  in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 960

Here's what happens on Cygwin:

  $ gcc -g -o ic ic.c -liconv
  $ ./ic
  iconv: 138 <Invalid or incomplete multibyte or wide character>
  in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft = 492
  iconv: 138 <Invalid or incomplete multibyte or wide character>
  in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft = 492
  iconv: 138 <Invalid or incomplete multibyte or wide character>
  in = <Liian pitkä sana>, inbuf = <ä sana>, inbytesleft = 7, outbytesleft = 492
  in = <Liian pitkä sana>, inbuf = <>, inbytesleft = 0, outbytesleft = 480

So, AFAICS, there are two problems:

  - Even though iconv_open has been opened explicitely with "UTF-8" as
    input string, the conversion still depends on the current application
    codeset.  That dsoesn't make sense.

  - Even though the last parameter to iconv is defined in bytes, the
    value of outbytesleft after the conversion is the number of remaining
    wchar"t's, not the number of remaining bytes.  That's contrary to what
    POSIX defines, see
    http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html

Is this analyzes correct?  Is there by any chance a newer version of
libiconv2 which does not have these problems?


Thanks,
Corinna

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
end of thread, other threads:[~2011-02-02 22:57 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-26 13:39 Bug in libiconv? simrw
2011-01-26 13:50 ` Corinna Vinschen
2011-01-26 17:01   ` Charles Wilson
2011-01-26 22:39     ` Corinna Vinschen
  -- strict thread matches above, loose matches on Subject: below --
2011-02-02 18:58 Bruno Haible
2011-02-02 21:20 ` Corinna Vinschen
2011-02-02 22:57   ` Charles Wilson
2011-01-29  2:15 Bruno Haible
2011-01-29 12:34 ` Charles Wilson
2011-01-29 13:20 ` Charles Wilson
2011-01-29 17:15   ` Corinna Vinschen
2011-01-29 16:02 ` Corinna Vinschen
2011-01-29 17:51   ` Eric Blake
2011-01-29 18:12     ` Corinna Vinschen
2011-01-29 18:28       ` Eric Blake
2011-01-30 11:34         ` Corinna Vinschen
2011-01-30 11:43           ` Corinna Vinschen
2011-01-30  2:40     ` Corinna Vinschen
2011-01-27 16:06 simrw
2011-01-25  6:36 Corinna Vinschen
2011-01-25 11:15 ` Charles Wilson
2011-01-25 15:04   ` Corinna Vinschen
2011-01-25 18:58     ` Charles Wilson
2011-01-25 20:11       ` Corinna Vinschen
2011-01-28 22:13         ` Charles Wilson
2011-01-27  5:46     ` Charles Wilson
2011-01-27 16:05       ` Corinna Vinschen
2011-01-27 17:18         ` Charles Wilson
2011-01-27  3:53   ` Charles Wilson
2011-01-27 16:21     ` Corinna Vinschen
2011-01-27 17:39       ` Charles Wilson
2011-01-27 18:05         ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).