[HECnet] New bridge.c feedback

[Boyanich, Alastair]

Hi Johnny,

Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite
C compilers as they're quite anal and chatty warning wise.

Sounds good. New code arrives I'll check it out. :) 

Al.


-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, 8 June 2012 4:35 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] New bridge.c feedback

On 2012-06-08 01:30, Boyanich, Alastair wrote:

Hi Johnny,

Yes. It seems to want<strings.h>   6.5.24 and above (or 6.5.29f in my
case) was aiming at SUSv3 compliance away from base XPG4 so things
were
moved to strings.h

(http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) ..
it's also in the 3c index man page, you were right.

Excellent. Included strings.h as well now. Not a problem on the
systems
here. We'll see if it hits problems for anyone else.

So, compiles on IRIX 6.5.29 if the header is included. Worth gating
it
in via #ifdef ? I'm also a fan of enum types. Binary emitted is
~298kb.

Also, your welcome to an account on the system if you wish to
poke/play
around, it's accessible over ssh and the general internet (it's my
daily
shell/hacking on code box).

-Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal.
See
below.

Even better. Thanks.

cc-3201 cc: REMARK File = bridge.c, Line = 158
    The parameter "data" was never referenced.

    int lookup(struct sockaddr_in *sa, char *data)
                                                                                      ^

Yeah. I noticed that one too. I don't remember why data was in there
in
the first place, since I'm not using it. Might as well drop it.

cc-1506 cc: REMARK File = bridge.c, Line = 460
    There is an implicit conversion from "unsigned long" to "long";
rounding, sign
                    extension, or loss of accuracy may result.

        delta = timedelta(bridge[index].lasttime);
                        ^

Thanks.

cc-3201 cc: REMARK File = bridge.c, Line = 559
    The parameter "r" was never referenced.

    void dump_nomatch(struct sockaddr_in *r, struct DATA *d)
                                                                                ^

That one is because dump_nomatch is a function I wrote for debugging
help. The body of the function is normally empty, since it's inside a
#if

Need to think a little about how/if I'll get rid of that warning...

cc-3201 cc: REMARK File = bridge.c, Line = 559
    The parameter "d" was never referenced.

    void dump_nomatch(struct sockaddr_in *r, struct DATA *d)
                                                                                                                ^

Same story...

cc-1185 cc: WARNING File = bridge.c, Line = 579
    An enumerated type is mixed with another type.

        d->type = classify_packet(d);
                        ^

That one should already have been fixed...

cc-1171 cc: WARNING File = bridge.c, Line = 685
    The indicated expression has no effect.

        if (port == 0) port == DPORT;
                                      ^

Also alredy fixed...

cc-1498 cc: REMARK File = bridge.c, Line = 709
    There is no prototype for the call to read_conf.

        read_conf();
        ^

Think I fixed that. However, this is a little messy, since I'm doing
things slightly unconventional. read_conf() is called both in the
normal
main program, and is also the signal handling function for SIGHUP.
However, signal functions actually takes one argument. By setting up a
prototype, I had to include one argument here, which is unused (I
totally don't care about it), so now you might get a warning about an
unused parameter. But prototypes are a good thing, so the unused
parameter warning is better to have.

cc-1209 cc: REMARK File = bridge.c, Line = 715
    The controlling expression is constant.

        while(1) {
                    ^

Yes. That's how you get an infinite loop. :-)

Thanks for the feedback. See what happens with the fixed code...

	Johnny