From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 00:28:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA96D106566C; Wed, 1 Jun 2011 00:28:53 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 424078FC1E; Wed, 1 Jun 2011 00:28:52 +0000 (UTC) Received: by qyk35 with SMTP id 35so1821262qyk.13 for ; Tue, 31 May 2011 17:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=IM66R4Za3evntw4WtQmp2GY7iMRljYhRKyJHHV4zoHg=; b=AsaFi7uiKbakyR8cTkioBmm0/4hFgLehmBFa7Icg6hWAr43NswOxrfqHn+hPAlqzKk kL5XKKVhweorkOznzYBTFNLp3GWyzobNWO48FK/pdtzTB4IXX9UeaRj4BaP4wBbj6YkJ NRKiQpS1pKA932836nWGcDQA6kJB+oOM3kXWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=uPPuS6omPM1SOU+USPUgF2VCKl6xr1dlnZwp8iYxsyZWjhlvYiNkwt9zo1/GmdXETD Mh3u/LFG9mPReM2KMenOrN2CKwtxuVZStodL1u6uMDzCxwUdlq0kGqLzY5SrwB9WJG8N Rtpv8cViG+TUwpAjp42QVapiRhmttZonTdX0U= Received: by 10.229.49.133 with SMTP id v5mr4786871qcf.165.1306886820296; Tue, 31 May 2011 17:07:00 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id j18sm356659qck.3.2011.05.31.17.06.58 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 17:06:59 -0700 (PDT) Date: Tue, 31 May 2011 20:06:52 -0400 From: Alexander Kabaev To: Warner Losh Message-ID: <20110531200652.3fd6fcbe@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/T7iGdQ5fH88cY+VF2hw12sz"; protocol="application/pgp-signature" Cc: Bruce, mdf@freebsd.org, Evans , freebsd-hackers Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 00:28:53 -0000 --Sig_/T7iGdQ5fH88cY+VF2hw12sz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 May 2011 17:18:16 -0600 Warner Losh wrote: >=20 > On May 31, 2011, at 5:07 PM, mdf@freebsd.org wrote: >=20 > > 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. >=20 > 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. >=20 > Usually it is different only on segmented architectures like 16-bit > x86. >=20 Not so on ia64, where they have special function descriptor type. --=20 Alexander Kabaev --Sig_/T7iGdQ5fH88cY+VF2hw12sz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFN5YKhQ6z1jMm+XZYRAiK3AKCSuEio0fx7ad5Fz2KpK+nuHTgKfwCfe3Ct Cd5nVJmXm44uRN/E6dm36yE= =hwor -----END PGP SIGNATURE----- --Sig_/T7iGdQ5fH88cY+VF2hw12sz--