Bug 28082

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.

					Dima Dorfman
					dima@unixfreak.org

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? :)  Also, was the
change to gcc also applied to -stable.  Eventually this change will be MFC.

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.

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.

Best regards,
Mike Barcroft

Comment 3 Dag-Erling Smørgrav 2001-06-13 01:53:17 UTC

State Changed
From-To: open->suspended

I'm sponsoring Mike for commit privileges, and am suspending this PR until 
core have processed his application so he can have a shot at closing it 
himself.

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
>

Comment 5 Dag-Erling Smørgrav 2001-06-22 02:52:49 UTC

State Changed
From-To: suspended->closed

Committed.  This patch will not be MFCed individually, as there are other 
whois(8) changes waiting in the pipeline.