Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 May 2011 17:18:16 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        mdf@freebsd.org
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: sizeof(function pointer)
Message-ID:  <D541877D-0EE5-4EC3-9197-E9F2A7A10AC1@bsdimp.com>
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 May 31, 2011, at 5:07 PM, 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.
>=20
> 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 *) =3D=3D 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).
>=20
> 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.

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D541877D-0EE5-4EC3-9197-E9F2A7A10AC1>