Bug#864358: ITP: bitfield -- bit array manipulation library
Package: wnpp Severity: wishlist Owner: Vitalie Ciubotaru * Package name: bitfield Version : 0.6.3 Upstream Author : Vitalie Ciubotaru * URL : https://github.com/ciubotaru/bitfield * License : GPL Programming Lang: C Description : bit array manipulation library bitfield is a library of functions for creating, modifying and destroying bit fields (or bit arrays), i.e. series of zeroes and ones spread across an array of storage units (unsigned long integers). Bit array is a simple data structure used in a wide range of software (starting from Linux kernel), yet there is no library that would provide this functionality, so every package has to reinvent the wheel. As the author, I would be willing to maintain the Debian package. This is my first submission, so I would need a sponsor.
Bug#864358: ITP: bitfield -- bit array manipulation library
Hi! On Wed, 2017-06-07 at 23:13:33 +0900, Vitalie Ciubotaru wrote: > Package: wnpp > Severity: wishlist > Owner: Vitalie Ciubotaru > > * Package name: bitfield > Version : 0.6.3 > Upstream Author : Vitalie Ciubotaru > * URL : https://github.com/ciubotaru/bitfield > * License : GPL > Programming Lang: C > Description : bit array manipulation library > > bitfield is a library of functions for creating, modifying and destroying bit > fields (or bit arrays), i.e. series of zeroes and ones spread across an array > of > storage units (unsigned long integers). > > Bit array is a simple data structure used in a wide range of software > (starting > from Linux kernel), yet there is no library that would provide this > functionality, so every package has to reinvent the wheel. Well, obviously not entirely as complete but the BSDs (and libbsd otherwise) do have something like . BTW, I noticed when I checked the implementation that you are using HAVE_BITFIELD_H as the header macro protector, but that's actually a bad idea, as with the typical autoconf based build-system that macro will already be defined if the build-system does something like AC_CHECK_HEADERS([bitfield.h]), which means the contents will be secluded. Thanks, Guillem
Bug#864358: ITP: bitfield -- bit array manipulation library
Hi. On 08/06/2017 12:28 AM, Guillem Jover wrote: > > Well, obviously not entirely as complete but the BSDs (and libbsd > otherwise) do have something like . > The difference between sys/bitstring.h and the package I propose is that bitstring.h implements a bit array within one unit of data storage (unsigned char, 1 byte, 8 bits), while my package uses an array of units (array of unsigned long integers, usually 32 or 64 bits EACH). This means that BSD's bit array can't be longer that 8 bits, while mine is limited by memory size only. > BTW, I noticed when I checked the implementation that you are using > HAVE_BITFIELD_H as the header macro protector, but that's actually a > bad idea, as with the typical autoconf based build-system that macro > will already be defined if the build-system does something like > AC_CHECK_HEADERS([bitfield.h]), which means the contents will be > secluded. Oh, yes, you are right. I was able to reproduce this problem. The name of the header guard needs to be changed. Thank you very much for pointing it out. Best regards, Vitalie Ciubotaru
Bug#864358: ITP: bitfield -- bit array manipulation library
On Mon, 2017-08-14 at 01:41:43 +0900, Vitalie Ciubotaru wrote: > On 08/06/2017 12:28 AM, Guillem Jover wrote: > > > > Well, obviously not entirely as complete but the BSDs (and libbsd > > otherwise) do have something like . > > > > The difference between sys/bitstring.h and the package I propose is that > bitstring.h implements a bit array within one unit of data storage (unsigned > char, 1 byte, 8 bits), while my package uses an array of units (array of > unsigned long integers, usually 32 or 64 bits EACH). This means that BSD's bit > array can't be longer that 8 bits, while mine is limited by memory size only. Nope, does support an unlimited amount of bits by using arrays of unsigned chars. You might want to recheck its implementation. :) > > BTW, I noticed when I checked the implementation that you are using > > HAVE_BITFIELD_H as the header macro protector, but that's actually a > > bad idea, as with the typical autoconf based build-system that macro > > will already be defined if the build-system does something like > > AC_CHECK_HEADERS([bitfield.h]), which means the contents will be > > secluded. > > Oh, yes, you are right. I was able to reproduce this problem. The name of the > header guard needs to be changed. Thank you very much for pointing it out. No problem! Regards, Guillem