Re: [PATCH] Update gnulib to current upstream master

[Pedro Alves <palves@redhat.com>]

On 08/29/2018 08:34 PM, Sergio Durigan Junior wrote:
> --- /tmp/gnulib1.txt	2018-08-29 15:20:56.394418711 -0400
> +++ /tmp/gnulib2.txt	2018-08-29 15:22:57.846895510 -0400
> @@ -4,13 +4,14 @@
>      alloca-opt
>      assure
>      at-internal
> +    builtin-expect
> +    c99
>    canonicalize-lgpl
>      chdir
>      chdir-long
>      cloexec
>      close
>      closedir
> -    configmake
>      d-ino
>      d-type
>    dirent
> @@ -30,6 +31,7 @@
>      fcntl
>      fcntl-h
>      fd-hook
> +    fd-safer-flag
>      fdopendir
>      filename
>      filenamecat-lgpl
> @@ -37,6 +39,7 @@
>      float
>      fnmatch
>    fnmatch-gnu
> +    fnmatch-h

We have a fnmatch.h replacement file in src/include/, and we include
fnmatch.h using quotes ("fnmatch.h").  Hopefully this won't cause weird
definition mismatches on hosts where gnulib provides a replacement.
Let's keep an eye out on that.

>      fpieee
>      fpucw
>      frexp
> @@ -51,6 +54,7 @@
>      gettext-h
>      gettimeofday
>    glob
> +    glob-h
>      hard-locale
>      include_next
>      intprops
> @@ -59,8 +63,10 @@
>      isnand-nolibm
>      isnanl-nolibm
>      largefile
> +    libc-config
>    limits-h
>      localcharset
> +    localtime-buffer
>    lstat
>      malloc-posix
>      malloca
> @@ -94,7 +100,7 @@
>      rmdir
>      same-inode
>      save-cwd
> -    secure_getenv
> +    scratch_buffer
>    setenv
>    signal-h
>      snippet/_Noreturn
> @@ -103,8 +109,10 @@
>      snippet/warn-on-use
>      ssize_t
>      stat
> +    stat-time
> +    std-gnu11

I wonder whether we should be using std-gnu11 explicitly.

>      stdbool
>      stddef
>      stdint
>      stdio
>      stdlib
> @@ -130,40 +138,36 @@
>      verify
>    wchar
>    wctype-h
> +    xalloc-oversized
> 
> 
> It doesn't seem like we're importing any important module implicity, nor
> that we stopped important anything important, but I may be wrong.
> 

Agreed, I crosschecked the list diff above against
<https://www.gnu.org/software/gnulib/MODULES.html>, following the links
in the leftmost column to check relevant module descriptions, and in some
cases looked at the sources of the modules.  Nothing big stood out to me.

>> Should we cherry pick the getcwd fix to the 8.2 branch?
> If you're proposing cherry-picking only the patch to the .m4 file under
> the gnulib/ dir, then perhaps we could.  

This, cherry-pick the getcwd fix that was applied on the gnulib tree.

> Backporting the whole gnulib
> update is not a good idea, IMHO.  But I'm sure that's not what you
> meant.

That's not what I meant.

Thanks,
Pedro Alves