Re: Bitsets

[Zack Weinberg]

Michael Hayes <address@hidden> writes:

> I have attached a new version of a bitset library for review.  The
> goal is to replace the sbitmap and bitmap routines used in GCC with a
> common interface that will support multiple bitset implementations.
>
> Now for a little bit of history.  I submitted an earlier version of
> this code for review well over a year ago.  Mark Mitchell reviewed it
> favourably but requested some changes to the function vectoring.  I
> resubmitted the changes, Mark was too busy, another reviewer had a
> look but dropped the ball. 

I believe that was me, and I want to apologize for dropping the
ball.  I always meant to come back to it but whenever I had a chance I
could never find the current version of the patch.  Now you've made it
clear what the current version is, I promise to look at this Monday
morning.

> In the interim I have been to busy to push the issue but the
> routines were adopted for use in Bison where they have been
> ISO-fied.  The Bison folks are keen for the routines to be used in
> GCC to share the maintenance.
>
> I originally wrote the routines as an extension to libiberty but this
> still has a K+R C restriction.  So I've created a separate library,
> primarily for testing and benchmarking.  The code is based on the
> current version in the Bison CVS repository but I have made a number
> of performance improvements and have added another bitset
> implementation.  This is similar to GCC's sbitmaps but allows for a
> variable size.

I don't see any reason why not to have a data-structures library,
separate from libiberty (which could then concentrate on its original
portability function) and requiring a C89 compiler.  But it would be
best to call it libdatastructures (or some abbreviation of that term)
rather than libbitset.

Alternatively I have *heard* that binutils was only waiting for us to
go C89 before taking the plunge themselves; if they do, I believe
there is no longer any reason to require K+R coding in libiberty.

zw