Bruno Haible wrote:
>
>
> Probably the only solution is to use #include_next only in gnulib's
> math.in.h
> but not in the other header files that are overridden by gnulib. I'm
> applying
> this; please let us know whether it works.
>
>
Unfortunately, this does not seem to work either (AIX
Hi,
Attached is a patch that fixes btowc.m4, mbrtowc.m4, wcrtomb.m4,
wcsrtombs.m4, and wctob.m4, so that they don't error out when cross
compiling.
Regards,
--
Yoann Vandoorselaere
PreludeIDS Technologies
diff --git a/m4/btowc.m4 b/m4/btowc.m4
index 64ff829..065684e 100644
--- a/m4/btowc.m4
++
Bruno Haible wrote:
> Pádraig Brady wrote:
>> ... then we need to use realloc like this I think:
>>
>> errno=0
>> np = realloc (p, n);
>> if (np==NULL && errno==ENOMEM) {
>> free (p);
>> error ();
>> }
>>
>> I.E. xrealloc etc. should be changed to check ENOMEM as above?
>
> This wa
Bruno Haible writes:
> Simon Josefsson wrote:
>> What about a realloc-gnu which implements a behaviour we think it is
>> useful? I know that we used -gnu for modules that are glibc extensions
>> over POSIX
>
> Yes, the two standards to which gnulib leans are POSIX and glibc's behaviour.
>
>> but
Simon Josefsson wrote:
> What about a realloc-gnu which implements a behaviour we think it is
> useful? I know that we used -gnu for modules that are glibc extensions
> over POSIX
Yes, the two standards to which gnulib leans are POSIX and glibc's behaviour.
> but I think we could extend it to be
Pádraig Brady wrote:
> ... then we need to use realloc like this I think:
>
> errno=0
> np = realloc (p, n);
> if (np==NULL && errno==ENOMEM) {
> free (p);
> error ();
> }
>
> I.E. xrealloc etc. should be changed to check ENOMEM as above?
This way of checking realloc's return val
Bruno Haible wrote:
> [Re-adding bug-gnulib in CC, because this discussion is generally interesting]
>
> Hi Pádraig,
>
> Pádraig Brady wrote:
>>> size_t n = 10;
>>> void *p = malloc (n);
>>> ...
>>> for (;;)
>>> {
>>> ...
>>> n = ...; /* larger than the original n */
>>>
Bruno Haible writes:
>> Perhaps we should have a single realloc-posix
>> module that behaves as glibc does now.
>
> No no, a module with suffix '-posix' is meant to provide the POSIX
> guarantees for the function and not more. (Cf. for example, the
> fnmatch-posix and fnmatch-gnu modules.)
What
