C Language, libclc: bitset interface, new final vote

libclc: bitset interface, new final vote

Author	Message
Bj?rn Augesta #1 / 27	libclc: bitset interface, new final vote Hello, voters and nay-sayers :-) This is a second attempt to get an approval for clc_bitset. Hopefully the last attempt? Please vote again, try "yes" this time :-) I have changed a few things based on your feedback. Here's a summary: 1. extern is gone. It was put there to make splint shut up about the usage of each function, but it didn't do much good. 2. The #endif in the tag now has a comment. 3. clc_bitset_set() has a new parameter, value. void clc_bitset_set(bitset, size_t, int value); If value is 0, the bit is set to 0, else the bit is set to 1. This change allows us to remove clc_bitset_clear and clc_bitset_assign. 4. Same thing for clc_bitset_set_all(). clc_bitset_clear_all() is gone. 5. clc_bitset_remap() is gone. 6. The #include statement is gone. You must now include stdlib.h yourself. 7. A function named clc_bitset_clone() has been added. It creates a new bitset from an existing bitset. It will allocate all necessary memory and then copy the bitset. It returns a new clc_bitset on success and NULL on failure. Call clc_bitset_free() to free it. This one is added so that bd can implement md5. 8. The empty/full functions have been renamed to int clc_bitset_is_all_set(clc_bitset b); int clc_bitset_is_all_clear(clc_bitset b); We're getting closer and closer to COBOL here... Unless I screwed up somewhere, this is a new and working version of the interface. Bj?rn #ifndef CLC_BITSET_H #define CLC_BITSET_H /* * Copyright (c) 2003, Bj?rn Augestad * All rights reserved. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * - Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * - Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * - Neither the name of the newsgroup comp.lang.c nor the names of * its contributors may be used to endorse or promote products * derived from this software without specific prior written * permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. / #ifdef __cplusplus extern "C" { #endif typedef struct clc_bitset_tag clc_bitset; clc_bitset clc_bitset_new(size_t bitcount); clc_bitset clc_bitset_clone(clc_bitset b); void clc_bitset_free(clc_bitset b); int clc_bitset_resize(clc_bitset b, size_t bitcount); void clc_bitset_set(clc_bitset b, size_t i, int value); void clc_bitset_set_all(clc_bitset b, int value); int clc_bitset_is_set(clc_bitset b, size_t i); int clc_bitset_is_all_set(clc_bitset b); int clc_bitset_is_all_clear(clc_bitset b); void clc_bitset_toggle(clc_bitset b, size_t i); void clc_bitset_toggle_all(clc_bitset b); size_t clc_bitset_size(clc_bitset b); void* clc_bitset_data(clc_bitset b); clc_bitset clc_bitset_map(void* mem, size_t cb); void clc_bitset_unmap(clc_bitset b); #ifdef __cplusplus Quote: } #endif #endif /* CLC_BITSET_H */
Wed, 17 Aug 2005 16:19:19 GMT

Emmanuel Delahay #2 / 27	libclc: bitset interface, new final vote Quote: > * Copyright (c) 2003, Bj?rn Augestad I'm not sure the '?' character is supported everywhere by all the compilers. I know that it's a pity, but I suggest Quote: > * Copyright (c) 2003, Bjorn Augestad -- -ed- emdel at noos.fr ~]=[o FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/ C-library: http://www.dinkumware.com/manuals/reader.aspx "Say 'No' to the war!" http://www.votenowar.org/
Wed, 17 Aug 2005 17:39:37 GMT

Randy Howar #3 / 27	libclc: bitset interface, new final vote Quote: > > * Copyright (c) 2003, Bj?rn Augestad > I'm not sure the '?' character is supported everywhere by all the compilers. Aww, let him keep his name, at least until a compiler coughs up {filter} on it. -- Randy Howard remove the obvious bits from my address to reply.
Wed, 17 Aug 2005 17:44:29 GMT

Chris Bart #4 / 27	libclc: bitset interface, new final vote 02:39:37a: Quote: >> * Copyright (c) 2003, Bj?rn Augestad > I'm not sure the '?' character is supported everywhere by all the > compilers. I know that it's a pity, but I suggest Eh, wouldn't a trigraph be ANSI-compliant now? :: Ducks and runs like a Pascal programmer faced with JCL. ::
Wed, 17 Aug 2005 19:08:56 GMT

CBFalcone #5 / 27	libclc: bitset interface, new final vote Quote: > This is a second attempt to get an approval for clc_bitset. Hopefully > the last attempt? Please vote again, try "yes" this time :-) > I have changed a few things based on your feedback. Here's a summary: ... snip ... > #ifndef CLC_BITSET_H > #define CLC_BITSET_H ... snip ... > #ifdef __cplusplus > extern "C" { > #endif > typedef struct clc_bitset_tag* clc_bitset; > clc_bitset clc_bitset_new(size_t bitcount); > clc_bitset clc_bitset_clone(clc_bitset b); > void clc_bitset_free(clc_bitset b); > int clc_bitset_resize(clc_bitset b, size_t bitcount); > void clc_bitset_set(clc_bitset b, size_t i, int value); > void clc_bitset_set_all(clc_bitset b, int value); > int clc_bitset_is_set(clc_bitset b, size_t i); > int clc_bitset_is_all_set(clc_bitset b); > int clc_bitset_is_all_clear(clc_bitset b); > void clc_bitset_toggle(clc_bitset b, size_t i); > void clc_bitset_toggle_all(clc_bitset b); > size_t clc_bitset_size(clc_bitset b); > void* clc_bitset_data(clc_bitset b); > clc_bitset clc_bitset_map(void* mem, size_t cb); > void clc_bitset_unmap(clc_bitset b); > #ifdef __cplusplus > } > #endif > #endif /* CLC_BITSET_H */ Better, but not done. I still see no purpose to data/map/unmap, except to lock in the implementation and make future revision impossible. I don't even understand what they are supposed to do. The resize operation should return a bitset. Without this the system cannot expand a bitset via realloc, which may change the pointer. As I said earlier, I think there should be certain other operations. However omitting them does not make future revision incompatible, so no more on that. You don't need set_all and is_all_set, but they may well be handy. You have set and toggle, but not clr. You should have all three, and they should return the previous bit state IMO (especially set and clr). -- Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Wed, 17 Aug 2005 21:08:12 GMT

Bj?rn Augesta #6 / 27	libclc: bitset interface, new final vote Quote: >>This is a second attempt to get an approval for clc_bitset. Hopefully >>the last attempt? Please vote again, try "yes" this time :-) >>I have changed a few things based on your feedback. Here's a summary: > ... snip ... >>#ifndef CLC_BITSET_H >>#define CLC_BITSET_H > ... snip ... >>#ifdef __cplusplus >>extern "C" { >>#endif >>typedef struct clc_bitset_tag* clc_bitset; >>clc_bitset clc_bitset_new(size_t bitcount); >>clc_bitset clc_bitset_clone(clc_bitset b); >>void clc_bitset_free(clc_bitset b); >>int clc_bitset_resize(clc_bitset b, size_t bitcount); >>void clc_bitset_set(clc_bitset b, size_t i, int value); >>void clc_bitset_set_all(clc_bitset b, int value); >>int clc_bitset_is_set(clc_bitset b, size_t i); >>int clc_bitset_is_all_set(clc_bitset b); >>int clc_bitset_is_all_clear(clc_bitset b); >>void clc_bitset_toggle(clc_bitset b, size_t i); >>void clc_bitset_toggle_all(clc_bitset b); >>size_t clc_bitset_size(clc_bitset b); >>void* clc_bitset_data(clc_bitset b); >>clc_bitset clc_bitset_map(void* mem, size_t cb); >>void clc_bitset_unmap(clc_bitset b); >>#ifdef __cplusplus >>} >>#endif >>#endif /* CLC_BITSET_H */ > Better, but not done. I still see no purpose to data/map/unmap, > except to lock in the implementation and make future revision > impossible. I don't even understand what they are supposed to do. They are not supposed to do anything special, but they allow the caller to create bitsets from existing memory. This basically means that you can manipulate any writable range of memory as a bitset. This may for some people be a very good thing. Remember that a memory mapped file can be a "writable range of memory". Consider this if you wonder why we need clc_bitset_map(). You can write a bitset to file today, but how do you read it back from a file and create a bitset? Quote: > The resize operation should return a bitset. Without this the > system cannot expand a bitset via realloc, which may change the > pointer. The bitset uses a separate pointer to store the data. That pointer can be reallocated. Check the implementation thread for further details. Quote: > As I said earlier, I think there should be certain other > operations. However omitting them does not make future revision > incompatible, so no more on that. Agree. > You don't need set_all and is_all_set, but they may well be > handy. You have set and toggle, but not clr. You should have all > three, and they should return the previous bit state IMO > (especially set and clr). I humbly disagree :-) Please see elsethread for why. BTW, did you miss the change to clc_bitset_set()? It now includes a value parameter (set\|clear), which removes the need for clc_bitset_clear(). Bj?rn
Wed, 17 Aug 2005 21:31:19 GMT

Randy Howar #7 / 27	libclc: bitset interface, new final vote Quote: > Remember that a memory mapped file can be a "writable range of memory". > Consider this if you wonder why we need clc_bitset_map(). You can write > a bitset to file today, but how do you read it back from a file and > create a bitset? More importantly, how do you do this portably? I.e. write a file on platform a, and read it back on platform b? Expecting all the while for bit 17 to always come back the way you expect. -- Randy Howard remove the obvious bits from my address to reply.
Wed, 17 Aug 2005 22:14:02 GMT

Bj?rn Augesta #8 / 27	libclc: bitset interface, new final vote Quote: >>Remember that a memory mapped file can be a "writable range of memory". >>Consider this if you wonder why we need clc_bitset_map(). You can write >>a bitset to file today, but how do you read it back from a file and >>create a bitset? > More importantly, how do you do this portably? I.e. write a > file on platform a, and read it back on platform b? Expecting > all the while for bit 17 to always come back the way you expect. I'll just wait for the libclc DOM parser. Then we dump and restore it as XML :-) Bj?rn
Wed, 17 Aug 2005 22:40:16 GMT

bd #9 / 27	libclc: bitset interface, new final vote Quote: > Hello, voters and nay-sayers :-) > This is a second attempt to get an approval for clc_bitset. Hopefully > the last attempt? Please vote again, try "yes" this time :-) [snip] It's okay for now. We'll want to add things later, like range functions, etc, but this is a good first version. -- Freenet distribution (temporary): http://24.25.175.161:8891/z-iSjFHtTuo/ Peter's hungry, time to eat lunch.
Wed, 17 Aug 2005 23:05:02 GMT

Ben Pfaf #10 / 27	libclc: bitset interface, new final vote Quote: > 02:39:37a: > >> * Copyright (c) 2003, Bj?rn Augestad > > I'm not sure the '?' character is supported everywhere by all the > > compilers. I know that it's a pity, but I suggest > Eh, wouldn't a trigraph be ANSI-compliant now? There's a trigraph for ?? -- "We put [the best] Assembler programmers in a little glass case in the hallway near the Exit sign. The sign on the case says, `In case of optimization problem, break glass.' Meanwhile, the problem solvers are busy doing their work in languages most appropriate to the job at hand." --Richard Riehle
Thu, 18 Aug 2005 01:42:35 GMT

CBFalcone #11 / 27	libclc: bitset interface, new final vote Quote: > >>This is a second attempt to get an approval for clc_bitset. Hopefully > >>the last attempt? Please vote again, try "yes" this time :-) > >>I have changed a few things based on your feedback. Here's a summary: > > ... snip ... > >>#ifndef CLC_BITSET_H > >>#define CLC_BITSET_H > > ... snip ... > >>#ifdef __cplusplus > >>extern "C" { > >>#endif > >>typedef struct clc_bitset_tag* clc_bitset; > >>clc_bitset clc_bitset_new(size_t bitcount); > >>clc_bitset clc_bitset_clone(clc_bitset b); > >>void clc_bitset_free(clc_bitset b); > >>int clc_bitset_resize(clc_bitset b, size_t bitcount); > >>void clc_bitset_set(clc_bitset b, size_t i, int value); > >>void clc_bitset_set_all(clc_bitset b, int value); > >>int clc_bitset_is_set(clc_bitset b, size_t i); > >>int clc_bitset_is_all_set(clc_bitset b); > >>int clc_bitset_is_all_clear(clc_bitset b); > >>void clc_bitset_toggle(clc_bitset b, size_t i); > >>void clc_bitset_toggle_all(clc_bitset b); > >>size_t clc_bitset_size(clc_bitset b); > >>void* clc_bitset_data(clc_bitset b); > >>clc_bitset clc_bitset_map(void* mem, size_t cb); > >>void clc_bitset_unmap(clc_bitset b); > >>#ifdef __cplusplus > >>} > >>#endif > >>#endif /* CLC_BITSET_H / > > Better, but not done. I still see no purpose to data/map/unmap, > > except to lock in the implementation and make future revision > > impossible. I don't even understand what they are supposed to do. > They are not supposed to do anything special, but they allow the caller > to create bitsets from existing memory. This basically means that you > can manipulate any writable range of memory as a bitset. This may for > some people be a very good thing. You are tying the implementation down. If they are needed, they belong in a separate module specifically labelled as non-portable, or as dependant on the core module. Quote: > Remember that a memory mapped file can be a "writable range of memory". > Consider this if you wonder why we need clc_bitset_map(). You can write > a bitset to file today, but how do you read it back from a file and > create a bitset? That is NOT universally possible, let alone convenient. As it stands the user has the tools to create such. for (i = 0; i < bitset_size(bitset); i++) putchar(bitset_is_set(bitset, i) + '0'); memory mapped files are not part of standard C. Even files are not guaranteed, just functions to try* to use them. Quote: > > The resize operation should return a bitset. Without this the > > system cannot expand a bitset via realloc, which may change the > > pointer. > The bitset uses a separate pointer to store the data. That pointer can > be reallocated. Check the implementation thread for further details. Once more, you are tying down the implementation. Less stringently, but unnecessarily. - Hide quoted text - - Show quoted text - Quote: > > As I said earlier, I think there should be certain other > > operations. However omitting them does not make future revision > > incompatible, so no more on that. > Agree. > > You don't need set_all and is_all_set, but they may well be > > handy. You have set and toggle, but not clr. You should have all > > three, and they should return the previous bit state IMO > > (especially set and clr). > I humbly disagree :-) Please see elsethread for why. > BTW, did you miss the change to clc_bitset_set()? It now includes a > value parameter (set\|clear), which removes the need for clc_bitset_clear(). Yes, I did miss that. Set and toggle should still return the previous value. This allows code such as: savedbit = set(bitset, bitnum, bit); dosomethingthatneedsitset(bitset); set(bitset, bitnum, savedbit); /* put things back */ which is not the cleanest thing in the world, but may save a lot of time and effort. -- Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Thu, 18 Aug 2005 03:14:38 GMT

Bj?rn Augesta #12 / 27	libclc: bitset interface, new final vote Quote: >>>>This is a second attempt to get an approval for clc_bitset. Hopefully >>>>the last attempt? Please vote again, try "yes" this time :-) >>>>I have changed a few things based on your feedback. Here's a summary: >>>... snip ... >>>>#ifndef CLC_BITSET_H >>>>#define CLC_BITSET_H >>>... snip ... >>>>#ifdef __cplusplus >>>>extern "C" { >>>>#endif >>>>typedef struct clc_bitset_tag* clc_bitset; >>>>clc_bitset clc_bitset_new(size_t bitcount); >>>>clc_bitset clc_bitset_clone(clc_bitset b); >>>>void clc_bitset_free(clc_bitset b); >>>>int clc_bitset_resize(clc_bitset b, size_t bitcount); >>>>void clc_bitset_set(clc_bitset b, size_t i, int value); >>>>void clc_bitset_set_all(clc_bitset b, int value); >>>>int clc_bitset_is_set(clc_bitset b, size_t i); >>>>int clc_bitset_is_all_set(clc_bitset b); >>>>int clc_bitset_is_all_clear(clc_bitset b); >>>>void clc_bitset_toggle(clc_bitset b, size_t i); >>>>void clc_bitset_toggle_all(clc_bitset b); >>>>size_t clc_bitset_size(clc_bitset b); >>>>void* clc_bitset_data(clc_bitset b); >>>>clc_bitset clc_bitset_map(void* mem, size_t cb); >>>>void clc_bitset_unmap(clc_bitset b); >>>>#ifdef __cplusplus >>>>} >>>>#endif >>>>#endif /* CLC_BITSET_H / >>>Better, but not done. I still see no purpose to data/map/unmap, >>>except to lock in the implementation and make future revision >>>impossible. I don't even understand what they are supposed to do. >>They are not supposed to do anything special, but they allow the caller >>to create bitsets from existing memory. This basically means that you >>can manipulate any writable range of memory as a bitset. This may for >>some people be a very good thing. > You are tying the implementation down. If they are needed, they > belong in a separate module specifically labelled as non-portable, > or as dependant on the core module. Forgive my lack of understanding here, but I fail to see why clc_bitset_map() is non-portable. To me the function is 100% portable, the same way that UINT_MAX and sizeof(int) is portable. Please explain. I do understand that it may be hard to write the contents of a bitset to a file on one platform and then read it into a bitset on another platform. That doesn't make make clc_bitset_map() any less portable than int i; fwrite(&i, sizeof i, 1, f); on one platform and the corresponding fread() on another platform. - Hide quoted text - - Show quoted text - Quote: >>Remember that a memory mapped file can be a "writable range of memory". >>Consider this if you wonder why we need clc_bitset_map(). You can write >>a bitset to file today, but how do you read it back from a file and >>create a bitset? > That is NOT universally possible, let alone convenient. As it > stands the user has the tools to create such. > for (i = 0; i < bitset_size(bitset); i++) > putchar(bitset_is_set(bitset, i) + '0'); > memory mapped files are not part of standard C. Even files are > not guaranteed, just functions to try* to use them. So? You know what I meant :-) - Hide quoted text - - Show quoted text - Quote: >>>The resize operation should return a bitset. Without this the >>>system cannot expand a bitset via realloc, which may change the >>>pointer. >>The bitset uses a separate pointer to store the data. That pointer can >>be reallocated. Check the implementation thread for further details. > Once more, you are tying down the implementation. Less > stringently, but unnecessarily. >>>As I said earlier, I think there should be certain other >>>operations. However omitting them does not make future revision >>>incompatible, so no more on that. >>Agree. >>>You don't need set_all and is_all_set, but they may well be >>>handy. You have set and toggle, but not clr. You should have all >>>three, and they should return the previous bit state IMO >>>(especially set and clr). >>I humbly disagree :-) Please see elsethread for why. >>BTW, did you miss the change to clc_bitset_set()? It now includes a >>value parameter (set\|clear), which removes the need for clc_bitset_clear(). > Yes, I did miss that. Set and toggle should still return the > previous value. This allows code such as: > savedbit = set(bitset, bitnum, bit); > dosomethingthatneedsitset(bitset); > set(bitset, bitnum, savedbit); /* put things back */ > which is not the cleanest thing in the world, but may save a lot > of time and effort. Which can be written as savedbit = clc_bitset_is_set(bitset, bitnum); clc_bitset_set(bitset, bitnum, bit); dosomethingthatneedsitset(bitset); clc_bitset_set(bitset, bitnum, savedbit); One extra line, I don't see a lot of time and effort saved ;-) It is feature creep and a potentionally confusing interface. Why confusing? Here's a couple of reasons: - Does toggle return the new or the old value? - Does set/toggle returning 0 mean that an error occured? - Why does set return 0 the first time it's called and 1 the second time? (Not very confusing, I admit that) The good thing about the proposed interface is - It is not confusing in any way. - It is the best performing solution for most users - If "most users" ignore the returned value, "most users" don't get lint warnings about ignored values. - It can be changed to implement your solution later. Your solution cannot be reversed without invalidating existing code. Let's triage this, is it a "Must have", "Should have" or "Nice to have"? Bj?rn
Thu, 18 Aug 2005 04:07:42 GMT

Hallvard B Furuset #13 / 27	libclc: bitset interface, new final vote Quote: >>> * Copyright (c) 2003, Bj?rn Augestad >> I'm not sure the '?' character is supported everywhere by all the >> compilers. > Aww, let him keep his name, at least until a compiler coughs up > {filter} on it. You mean 'Bj?rn'? All the world is not latin-1, you know. -- Hallvard
Thu, 18 Aug 2005 06:28:12 GMT

Hallvard B Furuset #14 / 27	libclc: bitset interface, new final vote Quote: >> Consider this if you wonder why we need clc_bitset_map(). You can write >> a bitset to file today, but how do you read it back from a file and >> create a bitset? > That is NOT universally possible, let alone convenient. As it > stands the user has the tools to create such. > for (i = 0; i < bitset_size(bitset); i++) > putchar(bitset_is_set(bitset, i) + '0'); That's slow and takes up much more file space than necessary if one only needs files used for a single platform. Which is OK sometimes, but I like to have the option of dumping and restoring the data structure quickly. At least for something as simple as a bitset. Quote: >>> The resize operation should return a bitset. Then it must return NULL if realloc fails. Should that mean the bitset was destroyed, or that the old bitset is still intact? With realloc I almost always would have preferred the former option since it makes the code simpler, but that would make it annoying if I ever wanted the latter option. BTW, I still think the _free operation should be renamed _delete. Also, Bj?rn, I think you are moving far too quickly. I don't see much point in calling for a vote when several things are still being discussed and new points are cropping up. (As opposed to when the discussion gets repetitive and people are just shooting old arguments at each other). Now you ended up modifying the interface (in other threads) _after_ calling for the vote. Not good. Also, people who have been away for a week or so should have time to go through the discussion they have missed and raise any points they are concerned about. It's not as we are in any hurry. If you feel the waiting slows you down too much, you can always start discussion on a new module in the meantime. -- Hallvard
Thu, 18 Aug 2005 06:53:36 GMT

Randy Howar #15 / 27	libclc: bitset interface, new final vote says... Quote: > >>> * Copyright (c) 2003, Bj?rn Augestad > >> I'm not sure the '?' character is supported everywhere by all the > >> compilers. > > Aww, let him keep his name, at least until a compiler coughs up > > {filter} on it. > You mean 'Bj?rn'? All the world is not latin-1, you know. I mean, do you know of any compiler that will fail to work on a source with his name in the copyright string within a comment block? If so, then I agree it needs to be changed. Otherwise, I don't see the point. -- Randy Howard remove the obvious bits from my address to reply.
Thu, 18 Aug 2005 08:45:20 GMT

Page 1 of 2

[ 27 post ]

Go to page: [1] [2]