sizeof(function pointer)

Nathan Whitehorn nwhitehorn at freebsd.org
Wed Jun 1 01:19:22 UTC 2011


On 05/31/11 19:06, Alexander Kabaev wrote:
> On Tue, 31 May 2011 17:18:16 -0600
> Warner Losh<imp at bsdimp.com>  wrote:
>
>> On May 31, 2011, at 5:07 PM, mdf at 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).
>>>
>>> Another possibility is to malloc a blob that is sizeof(int(*)(void))
>>> and store that in a renamed s_unused; this is a bit messier but
>>> guaranteed to work.  I'd just rather the code be an MCF instead of a
>>> partial re-write.
>> It is the same on MIPS too for all three ABIs that we support (and
>> all ABIs that I know about).  It is true on ARM as well.
>>
>> Usually it is different only on segmented architectures like 16-bit
>> x86.
>>
> Not so on ia64, where they have special function descriptor type.
>

As is also true on PPC64 and (I think) at least some MIPS. But on all of 
these, a function pointer is a regular data pointer to the function 
descriptor, which then points to the function, so they are still the 
same size as a void *.
-Nathan



More information about the freebsd-hackers mailing list