Hi Bruno. Thanks for your response. On Fri, 9 Oct 2009, Bruno Haible wrote:
> > In another case, I'm computing a column width for a table to be formatted > > to a stream. > > Note that snprintf is not suitable for this purpose, because as soon as > non-ASCII characters appear (in a UTF-8 locale for example), the number of > bytes and the number of columns for a string are different. For computing > the number of columns of a string, gnulib offers you the 'mbswidth' module. > And if your table cells have multiple lines and you want to do line breaking, > you can use the unilbrk/ulc-width-linebreaks module. Sorry, maybe I didn't provide enough detail again. I meant a table column not a string column, so I didn't mean to imply a discrepancy between bytes and string columns. I use snprintf like this: field_width = snprintf (NULL, 0, " %d", max_value); Later I use field_width for a "%*d" conversion on all rows of the table. I don't have much experience with mbswidth, but I don't think it can be useful here. By the way, don't look for any of that in Bison as it likely won't be there for a while. > > diff --git a/modules/all-printf b/modules/all-printf > > new file mode 100644 > > index 0000000..efc6f35 > > --- /dev/null > > +++ b/modules/all-printf > > @@ -0,0 +1,25 @@ > > +Description: > > +All functions in the printf family. > > + > > +Files: > > + > > +Depends-on: > > +dprintf > > +obstack-printf > > +snprintf > > +vasnprintf > > +vasprintf > > +vdprintf > > +vsnprintf > > +xprintf > > +xvasprintf > > This does not look very reusable: 80% of the programs don't use obstacks, 95% > of the programs don't use 'dprintf', and 30% of the programs are LGPL and > cannot use 'xvasprintf'. Forgetting licensing issues for a moment, what harm is there in including a module you don't currently need? My guess was that the harm is none or just some minor size increase. Is it worse than that? As for licensing, if a project is GPLv3 or GPLv3+, my understanding is that it can include any of the printf modules. If that's true and if all-printf and all-printf-posix were to state GPL in their License fields, then wouldn't most projects be fine to include them? The License field would also provide LGPL projects a clear indication that they can't benefit from such general modules. > So there is considerable variance in what various gnulib users would want. > Therefore the list that you want should probably better be shown in a piece > of documentation, rather than as a module. Either in MODULES.html (generated > by MODULES.html.sh), or in the doc/ directory. Would you care to write a > patch for the documentation? I'm not sure what you're hoping for, and documentation doesn't really address my issue. To find the full list of printf modules, I just used "ls modules/*printf*". But I figured a project's list of modules would be easier to check if it listed only 1 module in place of potentially 15 *printf-posix modules. Moreover, if ever gnulib grows a new printf module that a project needs (is there anything for wprintf yet?), the project's maintainers wouldn't have to remember to add it. Of course, Eric has shown me -DGNULIB_POSIXCHECK. I haven't explored it extensively yet, but it seems to improve the situation.
