lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Can you help me please (fwd)


From: Foteos Macrides
Subject: Re: lynx-dev Can you help me please (fwd)
Date: Sun, 10 May 1998 21:39:06 -0400

"T.E.Dickey" <address@hidden> wrote:
>> >>          This is an FAQ which has been explained numerous times on the 
>> >> list.  
>> >been there, done that: "bzero" is not referenced in the Lynx source, 
                            ^^^^^
>>   
>>         Neither are the other functions or macros in that list, and in 
>> another further down in tcp.h.  As has been stressed, they appear in the 
>> MultiNet headers or library functions to which Lynx is linked, with missing 
>> or variable prototyping that cause problems with the compilers' own headers 
>> across versions -- one of the kinds of thing autoconf deals with for the 
>> Unix folks. 
>
>perhaps a better fix than removing the extern would be to #undef bcopy?
                                                                  ?????
>(it depends on which problem it is fixing - since an undeclared extern
>would only normally break a compile if it were used in a table, as an
>address).

        It was *bzero* (*not* bcopy).

        All of the extern declarations in the two for-VMS-with-MultiNet set
of extern foo() declarations are ones which have a history of eliciting
compiler warnings because they are not prototyped in one or another version
of MultiNet headers, but are encountered (and presumeably used somehow or
other), when linking to the MultiNet libraries.  Using foo() for the C
compilers (like foo(...) for the C++ compilers) satisfies them, and avoids
the warning, alarm on the part of VMSers trying to build Lynx, and bug
reports to lynx-dev.  Once they appear in compiler warnings, one knows that
the prototyping has been done in either the MultiNet or compiler headers,
and can be removed from tcp.h.  I would not undef it, and possibly mess up
who knows what in the MultiNet libraries.

        It's easier to note which of the tcp.h "temporary" prototypes elicited
an argument warning, e.g., bzero in the warning report that was posted, and
tell the person, "simply delete the extern declaration for bzero where indicated
in tcp.h", than to explain where and how to add an extern declaration for the
opposite warnings, that would be more common.  Perhaps Brian Tillman would be
kind enough to do that on behalf his fellow VMSers (which I no longer am :).

                                Fote
-- 
Foteos Macrides

reply via email to

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