On 8/7/20 2:08 PM, Bruno Haible wrote:
I'm not sure whether the problem mentioned in lchown.texi and fchmodat.texi
for glibc 2.31 is still open, or fixed, or partially fixed in glibc 2.32.
I added some doc for that by installing the attached, which also adds doc for
the longstanding faccessat
glibc 2.32 was released two days ago. Let me update the documentation.
I'm not sure whether the problem mentioned in lchown.texi and fchmodat.texi
for glibc 2.31 is still open, or fixed, or partially fixed in glibc 2.32.
If any of you know, please feel free to update the question marks that I
left
[Dropping bug-gettext from CC]
Kamil Dudka wrote:
> > One of these lines must modify its contents. The question is: where?
> >
> > msg4 = strerror (1729576);
>
> I believe it is this ^^^ line.
Could it be related to this change in glibc 2.32?
* Both strerror and strerror_l now share the
clang (up to version 10.0) does not support __builtin_va_arg_pack and
__builtin_va_arg_pack_len: it complains about "use of unknown builtin".
We can leave this code in lib/cdefs.h
#if __GNUC_PREREQ (4,3)
# define __va_arg_pack() __builtin_va_arg_pack ()
# define __va_arg_pack_len() __builtin_va_a
> 2020-08-07 Bruno Haible
>
> Use __builtin_alloca with clang.
> * lib/alloca.in.h (alloca): Define as __builtin_alloca on clang.
This goes with it:
2020-08-07 Bruno Haible
alloca: No need to compile alloca.c with clang.
* lib/alloca.c: Skip all code with clan
clang supports __builtin_alloca.
On Windows, it does not have an header file, and therefore the use
of alloca(...) without any header file produces a warning
warning: implicitly declaring library function 'alloca' with type 'void
*(unsigned long long)'
Therefore, the bestes choices for gnulib
