From owner-freebsd-current@FreeBSD.ORG Fri Jun 10 11:02:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B75A116A41C; Fri, 10 Jun 2005 11:02:30 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C6C143D48; Fri, 10 Jun 2005 11:02:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5AB2SGx048623; Fri, 10 Jun 2005 14:02:28 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 46878-13; Fri, 10 Jun 2005 14:02:27 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5AB2Qvc048620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2005 14:02:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j5AB2t99079980; Fri, 10 Jun 2005 14:02:55 +0300 (EEST) (envelope-from ru) Date: Fri, 10 Jun 2005 14:02:55 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20050610110254.GB79872@ip.net.ua> References: <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <84dead72050610001675a32c19@mail.gmail.com> <863brq3bbz.fsf@xps.des.no> <84dead7205061001534b9385b3@mail.gmail.com> <863brqy41j.fsf@xps.des.no> <20050610091624.GA35628@wombat.fafoe.narf.at> <20050610094615.GC79474@ip.net.ua> <20050610102813.GA81548@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: <20050610102813.GA81548@orion.daedalusnetworks.priv> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: [current tinderbox] failure on ...all... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 11:02:30 -0000 --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2005 at 01:28:13PM +0300, Giorgos Keramidas wrote: > On 2005-06-10 12:46, Ruslan Ermilov wrote: > >On Fri, Jun 10, 2005 at 11:16:27AM +0200, Stefan Farfeleder wrote: > >>On Fri, Jun 10, 2005 at 11:06:16AM +0200, Dag-Erling Sm?rgrav wrote: > >>>Joseph Koshy writes: > >>>> Dag-Erling Sm?rgrav writes: > >>>> > It also seems strange to me that you on the one hand introduce a > >>>> > new struct to separate MD and MI interfaces, and on the other hand > >>>> > continue to assume that they are assignment-compatible. > >>>> I'd be very surprised if two C structures with identical definitions > >>>> were not assignment compatible. > >>> > >>> I wouldn't be surprised if the standard says they aren't. > >>> Unfortunately, my copy is at home. > >> > >> Do you mean the following? > >> > >> struct t1 { int a; } x; > >> struct t2 { int a; } y =3D { 42 }; > >> x =3D y; > >> > >> The types `struct t1' and `struct t2' are not compatible and thus not > >> assignable. See 6.2.7 and 6.5.16.1. > > > > If you're to byte-copy say t1 to t2, is it guaranteed to work? That > > is, do both types are guaranteed to have the same size and alignment > > of their structure members? I'm pretty sure this is guaranteed, as > > lot of code assumes this, for example, the sockaddr* structures. >=20 > That would be very hard to guarantee if two different modules that use > the types are compiled with different alignment options, right? >=20 > /* header1.h */ > struct t1 {short t1s; int t1a;}; >=20 > /* header2.h */ > struct t2 {short t2s; int t2a;}; >=20 > /* module1.c */ > #include "header1.h" > struct t1 x; >=20 > /* module2.c */ > #include "header1.h" > #include "header2.h" > extern struct t1 x; > struct t2 y; >=20 > If the two modules are compiled with different options that may affect > struct member alignment, how would one ensure that it is correct to > use code like this in module.c? >=20 > y.t2s =3D 10; > y.t2a =3D 100; > memcpy(&x, &y, sizeof(x)); >=20 > Even the use of sizeof(x) is tricky here, since there is no guarantee > that sizeof(x) < sizeof(y). >=20 And if both modules use the same t1 but compiled with different alignment options, the memcpy() in module.c won't work either, even a simple assignme= nt could break. :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --E39vaYmALEf/7YXx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqXNeqRfpzJluFF4RAsQ7AJ4pOpwfHa9pMA192G/s94tYnIXFDQCeMS2g P65duEJGuR4adpOBPubl9a4= =2Wtx -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx--