Date: Tue, 28 Mar 2006 13:00:06 -0500 From: John Baldwin <jhb@freebsd.org> To: "Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=" <des@des.no> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include atomic.h Message-ID: <200603281300.09419.jhb@freebsd.org> In-Reply-To: <86y7yuwn01.fsf@xps.des.no> References: <200603281434.k2SEYmaR031447@repoman.freebsd.org> <200603281032.10624.jhb@freebsd.org> <86y7yuwn01.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 March 2006 11:30, Dag-Erling Sm=F8rgrav wrote: > John Baldwin <jhb@freebsd.org> writes: > > On Tuesday 28 March 2006 09:34, Dag-Erling Smorgrav wrote: > > > Log: > > > Use wrapper macros for atomic pointer operations in order to perfor= m the > > > correct casts. This should probably be merged to other architectur= es. > > It should really be uintptr_t rather than u_int. >=20 > I realize that, but I wasn't sure I could safely assume that uintptr_t > is defined - and by definition, at this point in the code, we know > that u_int is compatible with a pointer. Hmm, I think you can assume that because sparc64's atomic.h uses uintptr_t. I'd prefer it as it would reduce diff's with other archs as well (I tend to do diff's between files in sys/i386 and sys/amd64). One reason for not having the casts, btw, is that you lose type checking. Requiring the caller to add the casts in places that aren't operating on uintptr_t's (note that the mutex and rwlock code both do operate on uintptr_t's) should force them to have to think (somewhat) and make sure they are really operating on a pointer and not an int, etc. Maybe that level of typechecking isn't needed and perhaps I'm being overly paranoid due to all the (older) code that assumes sizeof(int) =3D=3D sizeof(ptr). =2D-=20 John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603281300.09419.jhb>