From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 13 20:45:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3937216A4CE for ; Mon, 13 Dec 2004 20:45:39 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6890B43D53 for ; Mon, 13 Dec 2004 20:45:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBDKi9Ld082815; Mon, 13 Dec 2004 13:44:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 13 Dec 2004 13:44:08 -0700 (MST) Message-Id: <20041213.134408.119860158.imp@bsdimp.com> To: PeterJeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20041213185738.GD79646@cirb503493.alcatel.com.au> References: <200412131142.iBDBgMp4082138@mail.squidge.com> <20041213185738.GD79646@cirb503493.alcatel.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.ORG cc: henry@jot.to Subject: Re: du(1)/fts(3) integer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 20:45:39 -0000 In message: <20041213185738.GD79646@cirb503493.alcatel.com.au> Peter Jeremy writes: : For 6.x, the ABI isn't fixed so fts_number can be changed to int64_t. We have to be careful how we deal with these things... You do not have license to break libc ABI, even in current, without careful consideration of the consequences to backward compatibility... We're trying hard not to do this... : The 5.x ABI is fixed so there's no simple solution there. Possible hacks : would be: : - Add a new 'fts_number64' at the end of FTSENT. Since FTSENT is always : managed by fts(3) and the documentation allows for undocumented fields, : this should be permitted, though a "new" du(1) with an "old" libc : would break badly. : - Move fts_number to the end of FTSENT and leave a 'long' hole where the : existing fts_number is. This changes the ABI but old programs remain : compatible with the new fts. (Though new programs break with the : old fts). : - Have du(1) treat fts_pointer as an integer that : it can concatenate to fts_number on 32-bit architectures: : int64_t x = (int64_t)(ulong)p->fts_parent->fts_number | : ((int64_t)(ulong)p->fts_parent->fts_pointer) << 32; : x += p->fts_statp->st_blocks; : p->fts_parent->fts_number = (long)x; : p->fts_parent->fts_pointer = (void *)(long)(x >> 32); : etc. Wouldn't it be better to keep fts_number where it is, rename it to fts_number32 (say) and introduce a fts_number at the end? Then you'd update them both. Let the 32 bit one overflow, who cares: you've not broken anything. That way old libc.so and new du would work except in overflow cases. Warner