wg7j and pa0gri 1.9d

["Mike Bilow, mikebw@ids.jvnc.net" <mikebw@IDS.JVNC.NET>]

In Message-ID: <1602@wb9uus.ampr.org>,
wb9uus@wb9uus.ampr.org writes:

>I recompiled
>using Borland C++ 2.0 and the only change I made to the makefile was to
>change the commented line from tcc to bcc and same for the flags line and
>I also defined nrs in the config.h file.  I have tried using tcc also and got
>the same results.
>    ------
>One other thing...  I get a lot of warnings while compiling that say....
>undefined structure 'ip'
>I did not get this when I was using the June 91 source files.  Does anyone
>know if this is a problem or something that is ok?
>I have gone back to the pa0gri v1.7j with ip access modifications source
>that is also pa0gri version 911020 and it compiles with no warnings or errors
>and it also runs without crashing.  I really like the features of the new
>versions but can't keep them running for more that 10 min.

I don't know why these "undefined structure" errors would make an apperance
now.  They have been appearing for me on all of Gerard's source since last
May.  In addition to "ip" being undefined, there are also a few of
"pseduo_header" and a couple of others I don't remember.

These have never really caused any problems that I know of, and they are
a result of failing to include certain header files in certain C modules.
When a C module uses some statement that requires knowledge of the innards
of a structure (such as ip.addr or ip->addr), then the linker will fail
with an error if it cannot resolve this statement.  However, it is not
similarly required as a practical matter that the linker know the innards
of a structure in order to use or pass a pointer to it or do certain
other operations.  In such cases, it is good C style to include the
appropriate header file (especially on an optimizing compiler!), but
you only get warnings and not errors if the linker knows enough to produce
reasonable output.

Gerard, Doug, and I had a discussion about this a few months ago.  Doug
and I were using the BC++ 2.0 compiler, and Gerard was using the TC 2.0
compiler.  This appears to be where the problem lies.  (Don't even
suggest to Gerard that he use TC++ 1.0!  Of course, he may not have the
maintenance release, TC++ 1.01...)

This is one of those problems like the order in which include directives
should appear.  There are similar oddities sprinkled throughout NOS code,
the worst of which are the occasional redefinitions of things from other
header files in some more limited header file, usually with a comment
"This is defined here so I can use it without having to include all of
the OTHER.H file."  This, of course, explicitly defeats the type checking
that header files are supposed to provide, reducing C almost to a kind
of fancy BASIC.

But yes, don't worry too much.  If the linker gets genuinely confused,
you will get errors, not warnings, and you will not get an EXE file.

-- Mike Bilow, <mikebw@ids.jvnc.net>  (Internet)