Re: [libvirt] how to print size_t in LGPLv2+ program
On 08/17/2010 03:47 PM, Paul Eggert wrote:
On 08/17/10 23:17, Eric Blake wrote:
libvirt is currently LGPLv2+
Can this be changed to LPGLv3+? That'd solve the problem.
True, but it would have knock-on effects on all sorts of other clients of libvirt. I'm re-adding the libvirt list for thoughts from anyone else.
Is it worth relaxing the license on the *printf-posix family of modules to LGPLv2+ from their current LGPLv3+, or is this too big of a request?
I dunno, at some point we should be encouraging people to switch to LGPLv3+.
It makes sense for the FSF to request that GNU projects use better licenses. Unfortunately, libvirt is not a GNU project; so it is more a question as to how Red Hat wants to license it, rather than what the FSF prefers. At any rate, I think the ultimate decision on how libvirt is licensed is rather political in nature, and will involve quite a bit of discussion among more than just the software developers contributing to libvirt. But at least libvirt is LGPLv2+; unlike some projects (like git) that are explicitly v2-only and can't do the upgrade. Meanwhile, I tend to agree that relaxing printf-posix to LGPLv2+ is a rather hefty sledge-hammer, and probably not appropriate for gnulib.
since using umaxtostr penalizes 32-bit machines for converting to the 64-bit intermediary, maybe it's worth adding a size_t variant?
That would be fine. The *tostr routines were mainly written for two reasons. First, for platforms that can't/couldn't portably and reliably output wide integers. Second, speed.
What a shame that POSIX omitted an <inttypes.h> PRIu* for size_t.
We could add one in gnulib, no?
In a quick google search, I found this use of PRIdS (which is geared more for ssize_t, but the analog PRIuS would apply to size_t): http://bytes.com/topic/c/answers/506972-64-bit-portability-size_t-printf-for... However, S is awfully short; I'd prefer something a bit longer like PRIuSIZE. Is there any other project already using gnulib that has invented a PRIuXXX name for size_t? It would also be nice if we had some prior art from glibc or even one of the BSD systems to copy a commonly-used name. Meanwhile, the idea is slightly more appealing than relicensing lots of gnulib or using the inttostr code; but it still requires auditing code and forbidding "%zu" in favor of "%"PRIuSIZE (or whatever other name we settle on). Also, it seems like we might want to create a new intttypes-plus (or inttypes-gnu) module, and leave the existing inttypes module as providing just the namespace guaranteed by glibc, while requiring the use of the new module to pollute the namespace with these new (but useful) macros. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Eric Blake <eblake@redhat.com> writes:
In a quick google search, I found this use of PRIdS (which is geared more for ssize_t, but the analog PRIuS would apply to size_t): http://bytes.com/topic/c/answers/506972-64-bit-portability-size_t-printf-for... However, S is awfully short; I'd prefer something a bit longer like PRIuSIZE.
To my eye, PRIuSIZE follows the pattern set by PRIdPTR, PRIuLEASTN, etc. I like it. -- Ben Pfaff http://benpfaff.org
Eric Blake wrote:
it still requires auditing code and forbidding "%zu" in favor of "%"PRIuSIZE (or whatever other name we settle on).
You could hack GCC, clang, or even xgettext to produce a warning when it sees a 'z' size modifier in a format string. Bruno
On Tue, Aug 17, 2010 at 6:41 PM, Bruno Haible wrote:
Eric Blake wrote:
it still requires auditing code and forbidding "%zu" in favor of "%"PRIuSIZE (or whatever other name we settle on).
You could hack GCC, clang, or even xgettext to produce a warning when it sees a 'z' size modifier in a format string.
or build it with a mingw toolchain and watch the warnings flood in ;) -mike
participants (4)
-
Ben Pfaff -
Bruno Haible -
Eric Blake -
Mike Frysinger