lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Lynx 2.7.1fm


From: Foteos Macrides
Subject: Re: LYNX-DEV Lynx 2.7.1fm
Date: Wed, 10 Dec 1997 18:43:59 -0500 (EST)

"Brian Tillman, x8425" <address@hidden> wrote:
>I fetched Lynx 2.7.1fm today, compiled on OpenVMS VAX V5.5-2 with VAX C
>V3.1-051 (yes, I know they're old; I can't change that).  Neither the compile
>not the link produced any warning or error level messages whatsoever (unlike
>the current Lynx 2.7.1 development code) and the LYNX.EXE was produced.  I
>can run it and it seems to work for a very cursory test (i.e., I can link to
>lynx.browser.org and navigate there).  However, when I attempt to exit via
>CTRL/Z I receive:
>[...]

        I can't reproduce crashes on ^Z in 2.7.1fm, and have no good guess
about why you get them, but I doubt it's due to your old version of VMS.
Note also that what looked like a problem with a shared image library
function with VMS v7.1 now looks like a optimization problem with a newer
version of DECC than I have (code is being "optimized" in a way such that
arguments which should always have a value or be a zero-length string end
up as NULL).  I have no idea where that problem lies, either, and suspect
that it applies to all versions of Lynx.

        The devel code was trashed for VMS again, shortly after I posted
the patches to get it built on VMS, so I've only been looking at it for
any bug fixes or tweaks that might be relevant to 2.7.1fm, and not
actually exercizing it.  The problem you reported in building the devel
code was reported previously, also by someone trying to build it on VMS,
but its not specific to VMS and shouldn't be ignored.  It's due to a
change described by this comment in UCAux.h:

/*
 *  A type for a "Translation Quality" (actually, Transcoding Quality).
 *  This is a fuzzy concept since we are just looking at the charset
 *  not what characters are actually there, so it's just a guess for
 *  "common" cases.  TQ_NO must be 0 since callers of functions that
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 *  return this type may treat result as a boolean flag.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 *  The functions returning this type could be improved to use more
 *  knowledge from the translation tables.
 */
typedef enum {
    TQ_NO       = 0,            /* must be 0 */
    TQ_POOR     = 1,
    TQ_GOOD     = 2,
    TQ_EXCELLENT = 3
} UCTQ_t;


That gets by with gcc, but other compilers, for both Unix and VMS, balk
at the misuse of an enum as a boolean flag.  All of the if() clauses
in the devel code which treat the enum return values as a boolean flag
should be changed to do explicit equality or inequality checks (i.e.,
== TQ_NO or != TQ_NO), as is done for the HTCJK enum (== NOCJK or
!= NOCJK), often in the same if() clauses.

                                Fote

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]