[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev EBCDIC and HTMLDTD.{c,h}
From: |
Klaus Weide |
Subject: |
Re: lynx-dev EBCDIC and HTMLDTD.{c,h} |
Date: |
Wed, 12 May 1999 14:27:11 -0500 (CDT) |
On Tue, 11 May 1999 address@hidden wrote:
> In a recent note, Klaus Weide said:
>
> > Date: Tue, 11 May 1999 15:23:40 -0500 (CDT)
> >
> > But the reordering-for-EBCDIC is not done in either tags_old[]
> > or the enum _HTMLElement. I don't think this can be right -
> > it should be either in all theses places, or nowhere.
> >
> Thanks for noticing this. I confess I fixed what testing
> showed to be broken, and ceased testing when I got what I
> perceived to be a workable Lynx. I guess this means the
> testing was exhausting rather than exhaustive. :-)
>
> > Maybe a different strcasecomp()-like function, based on the
> > ASCII order, should be used instead of changing the order
> > in enums and initializers. Lookup of entity names seems to
> > have the same kind of problem, it has been 'solved' in a
> > different way (linear search instead of binary search) at
> > least in HTMLGetEntityUCValue().
> >
> I wish I had thought of that. :-) But what should it be called?
> I wonder what it will do to performance? (but, of course,
> suitable "#ifdef"s leave zero impact in the ASCII case.)
strcasecomp already is our own function, so we are already foregoing
all optimization that a system strcasecmp might have...
OTOH, maybe your EBCDIC system already has ASCII-order comparison
function in some library, then useing those might make performance
better instead of worse. :)
> This doesn't fit into my schedule for 2-8-2. Nor, I suspect,
> does it fit in Tom's. :-)
Well the easy fix of doing the equivalent of tags_new[] for
tags_old[] and the enum is simpler...
Klaus