bin/71628: [PATCH] cleanup of the usr.sbin/rpcbind code
keramida at freebsd.org
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 freebsd.org>
To: Dan Lukes <dan at obluda.cz>
Cc: Dima Dorfman <dd 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 08:43:38 +0300
On 2004-09-13 05:59, Dan Lukes <dan at obluda.cz> 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