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-format-strings 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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list