On Thu, May 5, 2016 at 10:31 AM, John Baldwin <j...@freebsd.org> wrote:
> On Wednesday, May 04, 2016 10:34:11 PM Alan Somers wrote: > > Author: asomers > > Date: Wed May 4 22:34:11 2016 > > New Revision: 299090 > > URL: https://svnweb.freebsd.org/changeset/base/299090 > > > > Log: > > Improve performance and functionality of the bitstring(3) api > > > > Two new functions are provided, bit_ffs_at() and bit_ffc_at(), which > allow > > for efficient searching of set or cleared bits starting from any bit > offset > > within the bit string. > > > > Performance is improved by operating on longs instead of bytes and > using > > ffsl() for searches within a long. ffsl() is a compiler builtin in both > > clang and gcc for most architectures, converting what was a brute force > > while loop search into a couple of instructions. > > > > All of the bitstring(3) API continues to be contained in the header > file. > > Some of the functions are large enough that perhaps they should be > uninlined > > and moved to a library, but that is beyond the scope of this commit. > > Doesn't switching from bytes to longs break the ABI? That is, setting bit > 9 > now has a different representation on big-endian systems (0x00 0x01 before, > now 0x00 0x00 0x01 0x00 on 32-bit BE, and 4 more leading 0 bytes on > 64-bit). > This means you can't have an object file compiled against the old header > pass a bitstring to an object file compiled against the new header on > big-endian > systems. > > Even on little-endian systems if an old object file allocates storage for a > bitstring the new code might read off the end of it and fault (or return > garbage if bits are set in the extra bytes it reads off the end)? > > Is the API is so little used we don't care? > > -- > John Baldwin > The API isn't used in any shared libraries, so the only risk would be if it's used in a user application where the user's build system doesn't check for changes in system libraries, and the user upgrades FreeBSD without doing a clean build of his application, right? Am I missing any other scenarios? Do we need to warn users with a line in UPDATING or something? This is similar to an upgrade of the C++ compiler. C++ objects built by different minor versions of the compiler aren't guaranteed to be compatible. -Alan _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"