This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: realpath bug in glibc?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 3 Apr 2015 19:05:15 +0200
- Subject: Re: realpath bug in glibc?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqPa1=cnNoJ3685NjphmM=zSmQjVihKV0Ytg1KPingqMA at mail dot gmail dot com>
On Fri, Apr 03, 2015 at 09:51:44AM -0700, H.J. Lu wrote:
> gcc/ada/cstreams.c in GCC has
>
> /* Use realpath function which resolves links and references to . and ..
> on those Unix systems that support it. Note that GNU/Linux provides it but
> cannot handle more than 5 symbolic links in a full name, so we use the
> getcwd approach instead. */
>
> It is hard for me to believe. Is this statement false?
>
Not sure about 5 but there is limit. It uses __eloop_threshold which
uses SYMLOOP_MAX thas described in
sysdeps/generic/eloop-treshold.h:
/* POSIX specifies SYMLOOP_MAX as the "Maximum number of symbolic
links that can be reliably traversed in the resolution of a
pathname in the absence of a loop." This makes it a minimum that
we should certainly accept. But it leaves open the possibility
that more might sometimes work--just not "reliably".