Date: Sun, 5 Jun 2011 11:05:47 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: mdf@FreeBSD.org Cc: freebsd-hackers <freebsd-hackers@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: sizeof(function pointer) Message-ID: <alpine.BSF.2.00.1106051103170.74164@fledge.watson.org> In-Reply-To: <BANLkTimctcBWRrYVLyc-WLgePyCXqaPTGA@mail.gmail.com> References: <BANLkTimctcBWRrYVLyc-WLgePyCXqaPTGA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 May 2011, mdf@FreeBSD.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds drains > to sbufs. The reason for MFC is that several pieces of new code in CURRENT > are using the drain functionality and it would make MFCing those changes > much easier. > > The problem is that r212367 added a pointer to a drain function in the sbuf > (it replaced a pointer to void). The C standard doesn't guarantee that a > void * and a function pointer have the same size, though its true on amd64, > i386 and I believe PPC. What I'm wondering is, though not guaranteed by the > standard, is it *practically* true that sizeof(void *) == > sizeof(int(*)(void)), such that an MFC won't break binary compatibility for > any supported architecture? (The standard does guarantee, though not in > words, that all function pointers have the same size, since it guarantees > that pointers to functions can be cast to other pointers to functions and > back without changing the value). I think you're OK for MFC purposes, but that in general, we shouldn't assume that they are the same size. I.e., we should use a function pointer type where we mean a function pointer type, and never write code that casts a function pointer to a regular pointer. (Which the change is fine with respect to, I believe). I'm doing some research on an experimental architecture where certain types of function pointers are 256-bit. This has some interesting consequences; we haven't yet gotten to investigating C language extensions/compatibility, but that will follow in the next year or so. (We also have 256-bit data references, similar to pointers, for use in some environments, which will also prove interesting. I'm not yet convinced we'll try to use a general pointer type for them, but perhaps instead extend the language to have a qualified type of some sort). Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1106051103170.74164>