On 05/31/11 19:06, Alexander Kabaev wrote:
On Tue, 31 May 2011 17:18:16 -0600
Warner Losh<i...@bsdimp.com>  wrote:
On May 31, 2011, at 5:07 PM, m...@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

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to