From owner-freebsd-current@FreeBSD.ORG Fri Jun 10 10:28:23 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 194C816A41C; Fri, 10 Jun 2005 10:28:23 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D44E43D1D; Fri, 10 Jun 2005 10:28:22 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j5AASFI6013560; Fri, 10 Jun 2005 13:28:16 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) by orion.daedalusnetworks.priv (8.13.4/8.13.4) with ESMTP id j5AASE4N081614; Fri, 10 Jun 2005 13:28:14 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by orion.daedalusnetworks.priv (8.13.4/8.13.4/Submit) id j5AASDqF081613; Fri, 10 Jun 2005 13:28:13 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 10 Jun 2005 13:28:13 +0300 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20050610102813.GA81548@orion.daedalusnetworks.priv> References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050610094615.GC79474@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 10:28:23 -0000 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 = { 42 }; >> x = 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. That would be very hard to guarantee if two different modules that use the types are compiled with different alignment options, right? /* header1.h */ struct t1 {short t1s; int t1a;}; /* header2.h */ struct t2 {short t2s; int t2a;}; /* module1.c */ #include "header1.h" struct t1 x; /* module2.c */ #include "header1.h" #include "header2.h" extern struct t1 x; struct t2 y; 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? y.t2s = 10; y.t2a = 100; memcpy(&x, &y, sizeof(x)); Even the use of sizeof(x) is tricky here, since there is no guarantee that sizeof(x) < sizeof(y).