Re: [PATCH 3/9] posix: Allow glob to match dangling symlinks [BZ #866]

[Paul Eggert <eggert at cs dot ucla dot edu>]

Adhemerval Zanella wrote:
> since make also packs
> its own glob copy from gnulib, it is matter to fix on make if and when
> it syncs with gnulib.

No, GNU Make uses glibc glob if it passes the compatibility tests in 
'configure', which it does. So previously-built instances of GNU make will 
likely crash if run with a glibc containing the proposed symlink changes. Even 
if you rebuild GNU Make from scratch it will still crash, because glibc glob 
will pass GNU Make's tests even with the patch.

We could fix this by incrementing _GNU_GLOB_INTERFACE_VERSION to 2 (causing GNU 
Make's configure-time test to fail), but this is a serious step that requires 
changing the libc.so major version number, creating backwards-compatibility 
functions for the old behavior, etc. I doubt whether the symlink glitch with 
'glob' is worth all this effort.

How about the following idea instead: establish two new flags GLOB_FOLLOW and 
GLOB_NOFOLLOW, where the caller specifies whether symlinks should be followed. 
The default is system-dependent. For glibc the default is GLOB_FOLLOW (we can 
even make GLOB_FOLLOW zero). For FreeBSD the default would be GLOB_NOFOLLOW, 
assuming they like the idea of supporting these flags. This maintains 
backward-compatibility for both kinds of platforms. For application code 
preferring GLOB_NOFOLLOW semantics if available, a simple:

#include <glob.h>
#ifndef GLOB_NOFOLLOW
# define GLOB_NOFOLLOW 0
#endif

will do, as long as all calls go glob specify 'GLOB_NOFOLLOW'. We can implement 
this idea first in Gnulib and then propose it for glibc.

Anyway, I'll submit a bug report to GNU Make, since it should not be assuming 
this implementation detail of glibc, regardless of what we decide about the 
above matter. However, it will be at best many years before we can assume this 
bug is fixed in the wild.