The build system for gnulib automagically detects and links against
libselinux. This causes trouble if e.g. findutils are compiled on a host
where selinux is present, but run on a system without. See also
https://bugs.gentoo.org/show_bug.cgi?id=330139.
The attached patch is only meant to illus
On 8/14/10 6:27 AM, Bruno Haible wrote:
Or import the module 'progname' from gnulib, and start the main()
function of your program with the statement
set_program_name (argv[0]);
That worked perfectly. Thanks.
Peter
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
Attached, a patch which cleans up the syntax bits documentation.
--
http://rrt.sc3d.org
0002-Document-syntax-flags-better.patch
Description: Binary data
Eric Blake wrote:
> Here's where a cross-project change to GNU Coding Standards could be
> helpful - if we all agree that gnulib should add the macro and gettext
> should add the support for it at the same time, then it would be much
> easier for all remaining GNU projects to take advantage of a
>
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
>
[This question ought to have been sent to bug-gettext, not bug-gnulib.]
Hi Eric,
> Use of PRIuMAX in a translated string produces a .pot file that
> refers to the special string , and which requires the
> need-formatstring-macros option passed to AM_GNU_GETTEXT in configure.ac
> to be universally
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 modifi
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 08/17/2010 04:05 PM, Eric Blake wrote:
> Mingw64 lacks %zu, and has the unfortunate setup where
> sizeof(long)==4 but sizeof(size_t)==8. Since gnulib's
> printf-posix module is not LGPLv2+, the best we can do
> is manually cast to the only portable int type known to
> hold size_t, and rely on g
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
3. "@comment xx something about leftmost-longest": I found this
comment in the section "Alternation Operator". Since there is already
a paragraph about leftmost-longest matching in general ("What Gets
Matched?"), what was intended here?
Probably we wrote the xx comment before writi
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
On 14 August 2010 23:09, Karl Berry wrote:
> [reducing to bug-gnulib]
>
> unhappy with code-generated documentation.
>
> We can have code-generated documentation *if* you (or someone) writes
> rms with a detailed explanation of the situation (I can review any
> draft). He always (to my knowled
I noticed that regex.h referred to the non-existent "regex_compile"
when it meant "re_compile_pattern". I have fixed this. The attached
patch also incidentally contains some whitespace cleanup which Emacs
did automatically, where there were 8 spaces instead of TABs. Feel
free to remove this portion
On 15 August 2010 14:45, Paolo Bonzini wrote:
>
> The non-thread-safety isn't only for RE_NO_SUB, but for all syntax options.
> RE_NO_SUB makes it worse only because it is _not_ a syntax option, but a
> setting to provide improved matching speed.
>
> I think RE_NO_SUB should be documented, and a
On 14 August 2010 23:15, Bruno Haible wrote:
> Reuben Thomas wrote:
>> New patch attached.
>
> I've applied it for you.
Thanks again.
Reading further, I came up with the following:
1. I believe the @ignored section about RE_NO_EMPTY_ALTS can be
removed, as it no longer exists.
2. Equivalence c
On 08/16/2010 05:11 PM, Eric Blake wrote:
> But I'll hold off for another day or two before pushing this, in case
> there are any more comments or suggested improvements.
>
> ChangeLog |9 +
> doc/posix-headers/stddef.texi |5 +
> lib/stddef.in.h
On 08/16/2010 06:04 PM, Bruno Haible wrote:
> Paolo Bonzini wrote:
#define offsetof(__a,__b) ((size_t)(&(((__a*)0)->__b)))
>> In C, the macro will work in practice with all compilers.
>
> In C++, however, some versions of g++ give a warning or error
> if this macro is used for a type that is
26 matches
Mail list logo
