On Thu, 14 Apr 2016, Peter Wemm wrote:
On Thursday, April 14, 2016 12:14:13 PM Pedro Giffuni wrote:
On 04/14/16 12:04, Pedro F. Giffuni wrote:
Author: pfg
Date: Thu Apr 14 17:04:06 2016
New Revision: 297974
URL: https://svnweb.freebsd.org/changeset/base/297974
Log:
x86: for pointers replace 0 with NULL.
These are mostly cosmetical, no functional change.
Found with devel/coccinelle.
Modified:
head/sys/i386/i386/db_disasm.c
head/sys/i386/i386/pmap.c
head/sys/i386/ibcs2/imgact_coff.c
head/sys/x86/x86/nexus.c
...
Modified: head/sys/i386/i386/pmap.c
==========================================================================
==== --- head/sys/i386/i386/pmap.c Thu Apr 14 16:32:27 2016
(r297973)
+++ head/sys/i386/i386/pmap.c Thu Apr 14 17:04:06 2016 (r297974)
@@ -269,15 +269,15 @@ pt_entry_t *CMAP3;
static pd_entry_t *KPTD;
caddr_t ptvmmap = 0;
caddr_t CADDR3;
-struct msgbuf *msgbufp = 0;
+struct msgbuf *msgbufp = NULL;
/*
* Crashdump maps.
*/
static caddr_t crashdumpmap;
-static pt_entry_t *PMAP1 = 0, *PMAP2;
-static pt_entry_t *PADDR1 = 0, *PADDR2;
+static pt_entry_t *PMAP1 = NULL, *PMAP2;
+static pt_entry_t *PADDR1 = NULL, *PADDR2;
#ifdef SMP
static int PMAP1cpu;
static int PMAP1changedcpu;
Hmm .. being static, there is no need to initialize these.
Several eons ago, at least some of these were initialized to force them into
the data section so that they had known or safe values before the bss zero
pass. I don't know if that was ever an issue on freebsd, or just the upstream
code. You'd have to look well back into ancient 2.0 or earlier vintage code.
I have a vague memory that our early a.out kernel had to zero its own bss
because the early a.out boot blocks didn't, and these variables would have
been caught in the crossfire. Or something..
I fixed this in 2003. Much later than I thought or could remember without
the commit logs.
Someone named peter removed clearing of the bss in locore to work
around bugs exposed by gcc changes. This broke booting without loader,
so someone named bde put back the clearing in the right place in locore
so that it didn't clobber variables like cpu_id. It was only a few
variables like cpu_id which were affected, and the problem was changing
them from nonzero to 0, not setting them to 0.
In any case, I'd be surprised if the compiler didn't put them in the bss
section these days anyway. At least without cc -ffreestanding, anyway.
gcc apparently started doing this as late as 2003. -fno-initialized-in-bss
can be used to restore the old behaviour, but we never used it.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
