Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Sep 2004 06:00:53 GMT
From:      Giorgos Keramidas <keramida@freebsd.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/71630: [PATCH] cleanup of the usr.sbin/pppd code
Message-ID:  <200409130600.i8D60r1m015130@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/71630; it has been noted by GNATS.

From: Giorgos Keramidas <keramida@freebsd.org>
To: Dan Lukes <dan@obluda.cz>
Cc: bug-followup@freebsd.org
Subject: Re: bin/71630: [PATCH] cleanup of the usr.sbin/pppd code
Date: Mon, 13 Sep 2004 08:54:34 +0300

 On 2004-09-13 03:07, Dan Lukes <dan@obluda.cz> wrote:
 > On Sun, 12 Sep 2004, Giorgos Keramidas wrote:
 > >On 2004-09-12 04:38, Dan Lukes <dan@obluda.cz> wrote:
 > >>-     FILE *iffile;
 > >>+     FILE *iffile = iffile; /* to avoid "may be used unitialized" warning */
 > >
 > >Nope.  NULL is the proper initialization value for (FILE *) objects.
 > >This way any bugs that might exist further down will be exposed by a
 > >dereference of a NULL pointer which everyone will notice.  Hiding the
 >
 > True initialisation is not necesarry with current code, so it's waste of
 > resources now.
 >
 > I like defensive style of programming, but it has negative impact on
 > performance.
 
 The impact is not greater than the impact of the bogus initialization
 shown above though.  The only difference is the extra safety the NULL
 initialization buys us.
 
 > Somebody should evaluate if we can live with unnecesarry initialisation
 > here.  If yes, it's better patch to iffile=NULL, if not, my patch is
 > better.
 
 The initialiation you suggested will result in the same sort of extra code,
 if not more.  It also invokes implementation defined behavior, which is
 Evil(TM) and should be avoided if possible; even with a slight increase in
 the cost (which is not the case here, but anyway).
 
 Another thing to note is that the initialization of pointers to NULL is so
 common that some compilers might use special optimization tricks to reduce
 the impact you mention.
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409130600.i8D60r1m015130>