On 2012-06-08 08:39, Boyanich, Alastair wrote: 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. Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything... Sounds good. New code arrives I'll check it out. :) The new code is already accessible. Same place as always... Johnny 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