Eric Blake
Fri Oct 31 13:15:00 GMT 2008

Hash: SHA1

According to Corinna Vinschen on 10/31/2008 5:17 AM:
>>   The safest course would be to declare or
>> preallocate a buffer of size PATH_MAX and pass it to realpath(); that
>> should work with any POSIX-compliant C library.
> Neverthless this is good advice if portability is an issue.

POSIX 200x (which is on track to be approved later this year) has modified
the requirements on realpath() that NULL be a universally accepted
argument.  Not all vendors comply with this yet, but at some point, it
will no longer be a GNU extension, but a POSIX-mandated requirement that
realpath() be able to malloc its result.  This is part of the overall
paradigm change in POSIX 200x that recognizes that it is legal to have
paths longer than PATH_MAX (and that is certainly the case with cygwin
1.7.0); as well as a thread-safety issue (in between the time you call
pathconf() and realpath(), some other process may have renamed one of the
symlinks on the path you are changing, such that your pathconf() results
are no longer valid for the file you end up resolving).  In fact, the
rationale given in POSIX for this change is:

"Since realpath( ) has no length argument, if {PATH_MAX} is not defined as
a constant in <limits.h>, applications have no way of determining how
large a buffer they need to allocate for it to be safe to pass to
realpath( ). A {PATH_MAX} value obtained from a prior pathconf( ) call is
out-of-date by the time realpath( ) is called. Hence the only reliable way
to use realpath( ) when {PATH_MAX} is not defined in <limits.h> is to pass
a null pointer for resolved_name so that realpath( ) will allocate a
buffer of the necessary size."

- --
Don't work too hard, make some time for fun as well!

Eric Blake   
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list