[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib and *printf
From: |
Bruno Haible |
Subject: |
Re: gnulib and *printf |
Date: |
Sun, 11 Oct 2009 22:44:46 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Joel,
> 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.
Indeed, in your case it is de facto guaranteed that all table cells will be
ASCII strings, so that strlen and mbswidth return the same value.
> > 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?
A certain number of gnulib users want to get the functionality they need,
and not more. If gnulib copies into their module code that they deem not
necessary - and for which we cannot explain the necessity - they start
using words like "bloat" or "creeping dependencies".
The harm that a module with too many dependencies does is that it does not
increase gnulib's reputation with people who think this.
> To find the full list of printf modules, I just used
> "ls modules/*printf*".
OK, that was easy enough. I guess most people do the same.
> 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.
But if the project does not use the function? For example, the latest addition
to the list of *printf functions was 'dprintf'. gnulib added support for this.
But if your project does not use dprintf(), then you don't have to add it.
Therefore tracking the list of all *printf functions is normally not useful.
> Of course, Eric has shown me -DGNULIB_POSIXCHECK. I haven't explored it
> extensively yet, but it seems to improve the situation.
Yes, -DGNULIB_POSIXCHECK is a step towards finding the modules that your
project needs.
Bruno