Date: Mon, 13 Dec 2004 13:44:08 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: PeterJeremy@optushome.com.au Cc: henry@jot.to Subject: Re: du(1)/fts(3) integer overflow Message-ID: <20041213.134408.119860158.imp@bsdimp.com> In-Reply-To: <20041213185738.GD79646@cirb503493.alcatel.com.au> References: <200412131142.iBDBgMp4082138@mail.squidge.com> <20041213185738.GD79646@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20041213185738.GD79646@cirb503493.alcatel.com.au>
Peter Jeremy <PeterJeremy@optushome.com.au> 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).
: - <Severe_kludge_alert>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. </Severe_kludge_alert>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041213.134408.119860158.imp>