On 08/17/2010 03:47 PM, Paul Eggert wrote: 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. 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. 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-... 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(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org