[comp.protocols.tcp-ip.ibmpc] MAKEing KA9Q from the sources - Compiler warnings?

EE599038@rvax.ccit.arizona.edu (Paul Charette) (02/27/90)

	I am trying to MAKE KA9Q from it's sources (from the NOS archive
FTP'd from flash.bellcore - src.arc, that is).  It _does_ create a perfectly
workable version of net.exe, but I get two flavors of compiler warnings all
through the MAKE process.  Examples of these are:

   Warning main.c 166: Parameter 'v2' is never used in function keyboard

AND

   Warning main.c 577: Undefined structure 'ax25_cb'

	Concerning the first, it seems like Phil passes some parameters to
some routines and then never uses them.  While this isn't harmful, it goes
unexplained.  I am just curious as to why this is.  I can always suppress the
messages by adding "-w-par" to the CFLAGS definition in the makefile.

	As for the second, I find it a little more disconcerting.  It seems
to be a result of include files which use structure definitions from other
include files.  If the "structure defining" include file doesn't get included
before the "structure declaring" include file, we get the error.  Again, it 
appears to be non-fatal.  My concern with this one is that if I mask it 
off by appending "-w-stu" to CFLAGS, then any code I add/modify may have
undefined structures of my own devising and the compiler won't tell me.

	I realize that these may just be things I have to live with, and that's
okay.  I guess I just wanted to make sure I'm not missing something ;-)
I suppose once net.exe is MAKEd I can remove the "-w-stu" and "-w-par" from
CFLAGS and any warnings that MAKE generates then will be limited to modules
that I have been working on.

	Any explainations, flames, and supportive messages appreciated.

Thanks!

Paul Charette
Department of Electrical and Computer Engineering
University of Arizona
Tucson, Arizona

"The truth doesn't gouge your eyes, but it does redden them."
						- Maninka proverb

EE599038@rvax.ccit.arizona.edu (Paul Charette) (02/27/90)

	The following information should have been included in my last
message, but I forgot, so here it is:

	I also get two other compilation warnings when I MAKE KA9Q.
They are:

	Warning smtpserv.c 322: Unreachable code in function getmsgtxt
	Warning alloc.c 166: Suspicious pointer conversion in function grabcore

	Again, I don't know the particulars and subtleties of the code
involved so I don't want to try to "fix" anything.  I guess I'd just like
re-assurance that these are ok.

	Reassurance anyone?

Cheers,
Paul

dave@tacky.cs.olemiss.edu ("David E. Johnson") (02/28/90)

All of the warnings mentioned when compiling NOS with Turbo C are
OK!!!

Turbo C is picky and some of these things just can't be corrected
easily.  Phil gave up on doing it.  You are not missing anything.  You
can set some flags on the compiler to stop showing these messages, if
you wish.

dave

karn@ka9q.bellcore.com (Phil Karn) (03/07/90)

In article <D1A3A9D0549F802D3C@rvax.ccit.arizona.edu> EE599038@rvax.ccit.arizona.edu (Paul Charette) writes:
>
>	I am trying to MAKE KA9Q from it's sources (from the NOS archive
>FTP'd from flash.bellcore - src.arc, that is).  It _does_ create a perfectly
>workable version of net.exe, but I get two flavors of compiler warnings all
>through the MAKE process.  Examples of these are:
>
>   Warning main.c 166: Parameter 'v2' is never used in function keyboard
>
>AND
>
>   Warning main.c 577: Undefined structure 'ax25_cb'

Yes, these two warnings will occur, but they are harmless. I turn them off
in my own turboc.cfg file.

The first warning occurs because I have a standard set of parameters for
newly created tasks, but not all tasks need them. Turning off this warning
doesn't cause any harm.

The second warning occurs because there are several occurances of
circular structure pointer references, i.e., structure A containing a
pointer to an instance of structure B, and vice versa. It's impossible
to declare both structures simultaneously, hence the warning. Since all
structure pointers have the same size, this doesn't cause any harm.
(If the size or contents of the structure were needed, then an error,
not a warning, would result.)

Phil