Re: LYNX-DEV Compilation error LYNX2-7-2 VAX VMS 7.1 DEC C 5.6 with

[Foteos Macrides]

"T.E.Dickey" <address@hidden> wrote:
>>      I just tried building -113 on VMS here and had no errors or
>> warnings.  I haven't looked closely at the actual mods in it, and the
>> block of time I had to play with Lynx got used up fixing bugs in v2.7.2,
>> and in the CONNECT support (for proxying https URLs) in lynx272ssleay.zip.
>> I don't know when I'll find another block of time, but let me warn you
>> that some of those chartrans patches were misguided, based on inferences
>> drawn from bugs in the development code's chartrans support.  They
>details would be useful.  this isn't complete, yet (and won't be this week).

        Again, I don't have time left on this round to get into details
in relation to the actual code, but here's some relevant information:

        The chartrans support in v2.7.2 uses a variation of the original
makeuctb.c and UCdomap.c code, which does not set an internal default
charset.  The conversions are done in SGML.c, HTPlain.c and LYCharUtils.c
based on the foo_uni.tbl-derived headers in src/chrtrans, structures in
LYCharSets.c, and functions in UCdomap.c and UCAux.c. The utf-8 header
is just a dummy, and does not have any means of actually generating
or converting utf-8 multibyte characters, and not all of the other
charsets had Unicode conversion tables, such that conversions to them
could not be done.  I therefore added code in SGML.c, HTPlain.c and
LYCharUtils.c for handling conversions, externally, to utf-8 when
that's the current Display Character Set, or to the SevenBitApproximations
array in LYCharSets.c or the "7 bit approximations" (def7_uni) Unicode
table, in that search order, when the initial Unicode table-based
conversion attempt fails for a current Display Character Set.  Klaus
then followed that by modifying makeuctb.c and UCdomap.c to treat
def7_uni as the default on the initial Unicode table-based conversion
attempt, with the consequence (bug) in the devel code that when your
current Display Character set was UNICODE UTF-8, DEC Multinational,
Macintosh (8-bit), Next character set, or Other ISO Latin, you always
got def7_uni approximations, even when the Display Character Set had
the multibyte or 8-bit equivalents, and you no longer had the ability
to regulate the approximations based on the LY_UMLAUT symbol.  The
bug was reported for UNICODE UTF-8, and Klaus went to my external
multibye conversions to deal with it for utf-8.  I later added
dmcs_uni, mac_uni, and next_uni conversion tables, which Klaus
included in the development code, but thereby masking the bug for
those character sets, and it still persisted for Other ISO Latin.
LP apparently drew incorrect inferences based on that bug, and the
fact that I filled in the holes (added all of the tables) for
iso-8859-1 through -10, which were also included in the devel code,
and he eliminated Other ISO Latin in those patches.  However, there
are iso-8859-11 and -12 charsets, not yet finalized, but may be, and
others may follow, and the code for dealing with them is still in
SGML.c, HTPlain.c and LYCharSets.c (though it doesn't work in the
devel code).  The other changes LP made were to cast the listing
order to what I had set up in v2.7.2 (which I, obviously, think is
better :), and to add more named character entities (which is a
judgement call, since all from HTML 4.0 were already in v2.7.2 and
the devel code, but since they're the rest of the Cyrillic and Greek
ones... :).


>> further mask the bugs, rather than fixing them.  Also, the problem
>> with the INTERNAL_LINK stuff was not just the inefficacy of the
>> compilation symbol for not using it (see the 1997-10-26 entry in
>> CHANGES.new), but in its invalid logic (see the verbose repetition of
>again - details would be useful (what aspect invalidates the logic?)
>
>> it in the 1997-11-03 CHANGES.new entries) despite Roy Fielding's replies
>> about whether he intended those interpretations in his URL -> URI drafts,
>> and that no other browser has or would implement them, even if he had
>> intended that.  Sigh...

        Details were provided when Klaus made those changes in logic,
and are available in the lynx-dev archives, plus clarification was
sought and received directly from Roy, but all fell on deaf ears.
Briefly, the URL -> URI drafts seek to combine and expand RFCs 1738
and 1808, and thus include information on how to determine the base
for resolving partial references to absolute URLs and URL-References.
A fragment is not part of a URL, and the combination of a URL and
fragment is a URL-Reference.  Roy sought to avoid unnecessary
retrievals by specifying that when the partial or absolute URL
field of a URL-Reference is empty, it defaults to "(current document)",
rather than to the base derived from a BASE element, Content-Location,
or Content-Base.  That's a change from RFCs 1738 and 1808 (which would
have required you to include a URL field with the fragment if you want
it to be an instruction for "(current document)" and the base points
elsewhere), and is a more flexible way to achieve that objective, since
otherwise the document would need to be edited whenever the URL for
"(current document)" changes, or if you want equivalent results
when retrieval of the same document is done via different schemes
(e.g., http, or file, or ftp).  "(current document)" is what is being
rendered for display or for inclusion in a larger document that is
being assembled (the latter is a wrinkle for GUIs handling frames,
inlines, etc., but not for Lynx).  The intent, spelled out in a
footnote for the earliest Fielding drafts, is to facilitate handling
of fragments for positioning within the document when the rendering
is completed, so that activating the link for that URL-Reference
can be treated as a movement command, without a new retrieval and
rendering of the same document, even if it had a no-cache directive such
that a new retrieval and rendering (dump from cache) would be required
when it is not "current".  The INTERNAL_LINK stuff in the devel code
treats URL-References derived from a fragment with no URL as always
having a no-cache override (whether or not it points to a position
in the document that is presently "current", and ones that did have
a URL component as not acquiring the override, even if they did
fully resolve to the document that is presently "current".  As
someone who did spend many years developing Lynx, I find it very sad
that its users will be stuck with that stuff in its next release (but
getting rid of it, now, from the devel code is a non-trivial task).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================