Re: [PATCH] Fix and expand bitvec interface.

Hi Max, On Wed, Jan 13, 2016 at 03:24:29PM +0100, suraev(a)alumni.ntnu.no wrote: we generally don't use 'unsigned' in the code so far, but 'unsigned int'. So it's a bit odd to see 'unsigned' without int here. In general, I probably wouldn't care too much. However, given that it is a single function that has one 'unsigned int' and one 'unsigned' argument, it seems a bit odd. If you're printing a single character only, using fputc() should be much more efficient. I'm not sure if gcc is good to detect that and replace it by itself. If yes, no need to change the code. If not, better use fputc. Also, the library should generally not just printf. For the majority of the programs running as daemons this doesn't make sense. The general way to deal with this is to offer a function that generates the string, i.e. 'char *bitvec_to_string(bitvec *bv)'. Since we assume single-threaded useres only, having a static buffer and always returning that buffer has so far been the the generally accepted form. If you don't like that, offer a bitvec_to_string_r() using a caller-allocated string, or maybe even better, something that take a talloc context as first argument, form where the output-string is then allocated. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)