[removed libvirt mailing list]
On 08/17/2010 11:17 PM, Eric Blake wrote:
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?
Ultimately, this is the nicest - %zu would just work.
Personally, I don't t
On 08/17/2010 05:37 PM, Eric Blake wrote:
> On 08/17/2010 05:35 PM, Bruno Haible wrote:
What a shame that POSIX omitted an PRIu* for size_t.
>>>
>>> You can define it by yourself ...
>>
>> Or use uintptr_t instead of size_t. By the definition of these types,
>> you can be sure that uintptr_t
On 08/17/2010 05:35 PM, Bruno Haible wrote:
>>> What a shame that POSIX omitted an PRIu* for size_t.
>>
>> You can define it by yourself ...
>
> Or use uintptr_t instead of size_t. By the definition of these types,
> you can be sure that uintptr_t is at least as wide as size_t. Then use
>
> pr
> > What a shame that POSIX omitted an PRIu* for size_t.
>
> You can define it by yourself ...
Or use uintptr_t instead of size_t. By the definition of these types,
you can be sure that uintptr_t is at least as wide as size_t. Then use
printf ("%" PRIuPTR, (uintptr_t) size_t_value);
- Works
On 08/17/2010 04:33 PM, Bruno Haible wrote:
>> Which means you _can't_ use "%lu",(unsigned long)size_t_val.
>
> You _can_ use this. It will work as long as each of your program's data
> structures is less than 4 GB large. Remember that size_t values get
> larger than 4 GB only if you have a memory
On 08/17/2010 04:33 PM, Bruno Haible wrote:
>> What a shame that POSIX omitted an PRIu* for size_t.
>
> You can define it by yourself: Basically you define
>
> #if @BITSIZEOF_SIZE_T@ == 32
> # define PRIuSIZE PRIu32
> #endif
> #if @BITSIZEOF_SIZE_T@ == 64
> # define PRIuSIZE PRIu64
>
Hi Eric,
> My understanding is that on 64-bit windows,
> sizeof(long)==4 but sizeof(void*)==8; and ... sizeof(size_t) is also 8.
Yes, correct.
> Which means you _can't_ use "%lu",(unsigned long)size_t_val.
You _can_ use this. It will work as long as each of your program's data
structures is les
Eric Blake 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-format-strings
> However, S is awfully short; I'd prefer something
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 fo
On 08/17/10 23:17, Eric Blake wrote:
> libvirt is currently LGPLv2+
Can this be changed to LPGLv3+? That'd solve the problem.
> 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 poi
On 08/17/10 23:17, Eric Blake wrote:
> libvirt is currently LGPLv2+
Can this be changed to LPGLv3+? That'd solve the problem.
> 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 poi
libvirt is currently LGPLv2+, but needs to use the printf family of
functions to display size_t values, even on mingw where %zu support is
not built in. My understanding is that on 64-bit windows,
sizeof(long)==4 but sizeof(void*)==8; and if I'm reading
http://msdn.microsoft.com/en-us/library/s3f4
12 matches
Mail list logo
