Re: gnulib and *printf

[Joel E. Denny]

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.