Date: Tue, 12 Jun 2001 21:40:02 -0700 (PDT) From: Dima Dorfman <dima@unixfreak.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/28082: [patch] src/usr.bin/whois clean-up Message-ID: <200106130440.f5D4e2Y15189@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/28082; it has been noted by GNATS. From: Dima Dorfman <dima@unixfreak.org> To: Mike Barcroft <mike@q9media.com> Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/28082: [patch] src/usr.bin/whois clean-up Date: Tue, 12 Jun 2001 21:31:19 -0700 Mike Barcroft <mike@q9media.com> writes: > On 6/11/01 11:38 PM, Dima Dorfman at dima@unixfreak.org wrote: > > > mike@q9media.com writes: > >> Description: > >> > >> The following patch has been sent to -audit. Reviewed by mikeh and gad. > >> All problems brought up were resolved. > >> > >> > >> 20010605 whois.patch > >> > >> o Silence warnings and set WARNS=2 > >> o Fix two memory leaks > >> o asprint -> strdup where appropriate > >> o calloc/strcpy/strcat -> aprintf > >> o Convert to ANSI C to avoid having to prototype main() > > > > I don't think this is a good reason to ANSIify something, especially > > since gcc no longer complains about that. > > Would you not agree that prototyping main() is evil? :) I agree that prototyping main() is evil in most cases. It makes sense to prototype it if main() is recursive, but a program with a recursive main() probably has other problems ;-). > Also, was the > change to gcc also applied to -stable. Not yet. But neither have the WARNS= patches, so it isn't a problem. David did say that he would apply the patch to -stable as well. > Eventually this change will be MFC. If it were to be MFC'd as is, no breakage would result because -stable doesn't have WARNS=. > > I recall David saying something about it only being applied to the current > verion of gcc, and future versions may not have it. I would hate to > introduce something that could result in future breakage, as a result of a > new gcc import. I don't think this will be much of a problem. whois(1) also wouldn't be the only program in this position, and a temporary remedy is readily available, namely NO_WERROR. Granted this isn't ideal, but it's enough to fix it until we can decide what to do. Furthermore, I don't think it's appropriate to ANSIify a program simply for the sake of removing the warning. I don't mean this case, but there are programs which are WARNS=1-ready modulo this warning. It'd be nice to set WARNS=1 for them without having to ANSIify. > > My goal was to take a more proactive step towards current style(9) > conventions. Although style(9) recommends staying with current conventions > unless you're changing 50% or more, I feel I'm justified in this change. > Others in -audit also felt it was "the right thing to do". > > If you still feel ANSIify this is the wrong thing to do in this case, I'd be > more than happy to convert the prototypes back to __P() and produce a new > patch. Personally, I don't particularly care. It looks like DES is sponoring you for a commit bit, so you can decide which you prefer (probably the ANSIfication). Good luck! Dima Dorfman dima@unixfreak.org > > Best regards, > Mike Barcroft > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106130440.f5D4e2Y15189>