bin/71628: [PATCH] cleanup of the usr.sbin/rpcbind code

[Dan Lukes]

The following reply was made to PR bin/71628; it has been noted by GNATS.

From: Dan Lukes <dan at obluda.cz>
To: Giorgos Keramidas <keramida at freebsd.org>
Cc: alfred at freebsd.org, bug-followup at freebsd.org
Subject: Re: bin/71628: [PATCH] cleanup of the usr.sbin/rpcbind code
Date: Mon, 13 Sep 2004 02:57:20 +0200 (CEST)

 On Sun, 12 Sep 2004, Giorgos Keramidas wrote:
 
 > He's probably the best person to suggest a fix for this warning, if one
 > is really needed.
 
  	There is no need for fix a error as there are no error. The 'fd' is
 correctly initialized with no exception, althought GCC can't evaluate it.
 
  	It's try to eliminate unnecesarry warning.
 
 > No.  I don't know why you think that this is a good fix for all the
 > uninitialized pointer warnings.  It's not.  Never :-/
 
  	Why ? It's written within the "description" section of the PR.
 Warning shoult be "attention marks" - THIS CONSTRUCT SHOULD BE REVIEWED.
 
  	If there are too many warnings related to correct code we can't use
 it for it purpose. Warnings become notice with almost no value.
 
  	Well. I compiled the code and evaluate that hundreds of warnings
 didn't point to problematic code, but are "false" only. I will compile the
 code next month. Do you think I recognise there are hundreds + 1 warning, so
 we should evaulate this +1 warning to be sure there are no error ?
 
  	Warnings may be very usefull information, unless they lie so much.
 Current code cause piles of false warnings. It "warnings" are hard to use as
 true warning ...
 
  	But any commiter can close all of my PR if he think I'm not true ...
 
 > After a quick glance at the source of rpcbind() I think that there's no way
 > that my_xrpt can be used uninitialized.  A proper fix for this warning
 > would be then to just set my_xrpt to NULL at first and let the rest of the
 > function unchanged regarding my_xrpt.
 
  	The unnecesarry initialisation of variable initialised again later
 seems to be vaste of resources. But IMHO only.