On Wed, 15 Nov 2000, Sam TH wrote:
> On Wed, Nov 15, 2000 at 03:30:39PM +0400, Vlad Harchev wrote:
> > On Wed, 15 Nov 2000, Sam TH wrote:
> >
> > > On Wed, Nov 15, 2000 at 02:30:33PM +0400, Vlad Harchev wrote:
> > > > On Wed, 15 Nov 2000, Sam TH wrote:
> > > >
> > > > > On Wed, Nov 15, 2000 at 01:48:06PM +0400, Vlad Harchev wrote:
> > > > > > On Mon, 13 Nov 2000, Pierre Abbat wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > May be glibc is buggy in MDK as usual?
> > > > >
> > > > > I'm going to try to find the source package for this, and see what
> > > > > is causing that problem.
> > > >
> > > > I think that even finding out what's wrong and with what won't help us to
> > > > solve this problem (unless we require MDK users to upgrade their glibc, if
> > > > there are updates for it). This problem should be fixed internally to AW IMO.
> > >
> > > Well, the original libpng bug, back about 6 months ago, required looking
> > > in the library to find the problem, but the problem was our fault.
> >
> > Current case is completely different IMO. iconv(handle,0,0,0,0) is a valid
> > use for any valid handle - that's stated in manuals. It's impossible that AW
> > is guilty, glibc from MDK is.
>
> Well, my copy of the man page doesn't say exactly that, but close enough.
>
> Ok, after spending some quality time with various version of iconv.c in glibc
> source rpm's, I have indeed verified that this is a bug in glibc 2.1.2, which
> was fixed in the glibc CVS tree on 20-12-99. So, you need a version of glibc
> which includes that fix, in order to run that code properly. For the curious,
> here's the code:
>[...]
Nice research. But it gave us nothing IMO (only that it's really glibc bug).
> >
> > > > > But I would still accept a patch for this.
> > > > >
> > > > Anyways, I can start composing such patch only after you put nightly snapshot
> > > > (or I will make a patch against yesterday version).
> > >
>
> Regardless of what the bug was, I look forward to your UT_iconv_reset
> patch. That should fix Pierre's problem nicely.
I've already did it.
> > > It should be up in about 5 minutes. You really ought to get CVS. It's
> > > lots faster.
> >
> > Of course CVS is the right thing, but I don't know how it performs on
> > connections that break often. So it's safer for me to use patches from your
> > page.
>
> I think cvs recovers rather well if it is interuppted in the middle of a
> transfer. You really ought to try it, it's a wonderful tool.
Yes, of course it's nice. I just can't find time to study/test it properly.
> >
> > > >
> > > > Could anybody please mail me trace log (that AW writes to stdout) of a
> > > > session with smartquotes enabled, in which "Abccd" <CR> (with quotes) is typed
> > > > - so I will be able to see what AW with working smartquotes should put in debug
> > > > log and how it behaves.
> > >
> > > I tested it, and got identical results to yours. Of course, I still get
> > > ? instead of smart quotes, but I don't think the two issues are related.
> >
> > Very very strange.
> > My AW is linked with libiconv, and yours? I think this can be the only reason
> > for differences in behaviour.
> >
> > I will look again into the code and force linking with glibc's iconv after I
> > downloaded nightly diffs.
>
> Mine is linked with the sytem library's version of iconv.
I've already fixed this bug. It was a stupid bug of me. I also had to change
RemapGlyphsTable to make real "nice" quotes to be used though. I'm researching
right now why it is necessary (as I understand, smartquotes really worked -
i.e. nice quotes were used - before nonlatin1 patch) and I will test it with
libiconv too.
Best regards,
-Vlad
