[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bitsets

From: Daniel Berlin
Subject: Re: Bitsets
Date: Sun, 8 Jun 2003 12:03:58 -0400

On Sunday, June 8, 2003, at 02:57  AM, Zack Weinberg wrote:

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

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.

For the record, i agree with Zack here. I know DJ doesn't like to add datastructures to libiberty anyway, and they probably account for all the API problems between versions libiberty ever has.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]