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

Giorgos Keramidas keramida at
Sun Sep 12 22:50:25 PDT 2004

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

From: Giorgos Keramidas <keramida at>
To: Dan Lukes <dan at>
Cc: Dima Dorfman <dd at>, bug-followup at
Subject: Re: bin/71628: [PATCH] cleanup of the usr.sbin/rpcbind code
Date: Mon, 13 Sep 2004 08:43:38 +0300

 On 2004-09-13 05:59, Dan Lukes <dan at> wrote:
 > Dima Dorfman wrote:
 > > Any initialization in the form "T v = v" invokes undefined behavior by
 > > using the indeterminate value of an object. Eliminating a warning or
 > 	Unless compiler documentation say other ...
 > 	The v=v DURING DECLARATION (not later) is special case.
 > 	Even on non GCC compiler it didn't make things worse - the value of v
 > has not been changed by v=v statement ...
 Undefined behavior is always worse.  It means you cannot determine what
 the program will do until you run it, which is worse than setting a
 pointer to NULL, which might be equivalent to:
 	char *p = 0;
 and translate to 1-2 machine instructions.
 > > compiler can't be convinced that the variable is never used before
 > > being initialized, please initialize it to something obviously bogus.
 > 	It can be convicted, by "v=v" trick during declaration of variable.
 > It's hack, of course.
 A dangerous one too.  See my post about a "trap" that might be generated
 when you try to set a pointer's value to something completely bogus.
 > 	It seems to be similar to "declared but newer used" warning. It is
 > eliminated by compiler specific hack also ("__unused")- not by true
 > usage of variable.
 That's a different thing.  Not using a variable isn't really dangerous.
 Using the value of a pointer whose initial value contains garbage *is*
 > If you thing those patches can't be used (with or without corrections
 > you recommended) then close the PR
 I think a lot of the work in these patches is useful.  A few changes
 here, a minor fix there and it'll be nice if they're committed and have
 as many warnings fixed as possible.  This is my personal opinion though.
 Keep up the good work ;-)

More information about the freebsd-bugs mailing list