Re: how to print size_t in LGPLv2+ program

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]