Re: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’

Hi, >> Can you also comment on this: >> >> > BTW, it’s unclear to me from the manual whether RESULT_LEN above should >> > be the size in bytes or the size in uint32_t. > > It's documented in chapter 2 "Conventions" of the manual [1]. The *LENGTHP > value indicates the string length in units (i.e.

Re: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’

Hi Ludo, > Can you also comment on this: > > > BTW, it’s unclear to me from the manual whether RESULT_LEN above should > > be the size in bytes or the size in uint32_t. It's documented in chapter 2 "Conventions" of the manual [1]. The *LENGTHP value indicates the string length in units (i.e. uin

Re: [PATCH] New modules nproc, pthread.

On 07/13/10 02:07, Pádraig Brady wrote: > The coreutils build just failed on our integration server > as it doesn't have Ah. A dinosaur, or a purposeful torture-test? > So currently the coreutils code would need more ifdefs > which I would prefer not to do, or we could expand the > emulation i

Re: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’

Hello Bruno! Bruno Haible writes: > Ludovic Courtès wrote in > : >> In the example below, conversion from UTF-8 to UCS-4 succeeds but >> ‘u32_conv_from_encoding’ allocates memory on the heap although the >> supplied buffer

Re: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’

Hello Ludo, Ludovic Courtès wrote in : > In the example below, conversion from UTF-8 to UCS-4 succeeds but > ‘u32_conv_from_encoding’ allocates memory on the heap although the > supplied buffer appears to be large enough: I

Re: [PATCH] New modules nproc, pthread.

On 25/03/09 20:04, Paul Eggert wrote: > This patch is to add multithread support for coreutils. The code was > written by Glen Lenker, who has filed papers with the GNU project. > The pthread emulation (for platforms that lack pthreads) is very minimal, > just enough for coreutils to get by. The

Re: [PATCH] strtod: make it more-accurate typically, and don't require libm

Hi Paul, > but won't the "return 0.0" cause some compilers to > issue bogus warnings about X and EXPONENT not being used? > That's why I had the "x + exponent" in there. We have a macro for this purpose in gnulib (actually, even two): _GL_UNUSED and _UNUSED_PARAMETER_. Alternatively, a cast to vo