Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Martin Sebor <msebor@gmail.com>]

On 09/12/2015 04:09 AM, Jonathan Wakely wrote:
> On 11 September 2015 at 18:39, Martin Sebor wrote:
>> On 09/11/2015 08:21 AM, Jonathan Wakely wrote:
>>>
>>> Solaris 10 doesn't follow POSIX in accepting a null pointer as the
>>> second argument to realpath(), so allocate a buffer for it.
>>
>>
>> FWIW, the NULL requirement is new in Issue 7. In Issue 6, the behavior
>> is implementation-defined, and before then it was an error. Solaris 10
>> claims conformance to SUSv2 and its realpath fails with EINVAL.
>> Solaris 11 says it conforms to Issue 6 but according to the man page
>> its realpath already implements the Issue 7 requirement.
>
> Thanks.
>
>> I suspect the same problem will come up on other systems so checking
>> the POSIX version might be better than testing for each OS.
>
> The problem with doing that is that many BSD systems have supported
> passing NULL as an extension long before issue 7, so if we just check
> something like _POSIX_VERSION >= 200809L then we can only canonicalize
> paths up to PATH_MAX on many systems where the extension is available
> but _POSIX_VERSION implies conformance to an older standard.

You're right. I agree that just checking the POSIX version may not
lead to optimal results. Some implementations also support multiple
versions and the one in effect may not be the one most recent. To
get the most out of those, it's usually recommended to set
_POSIX_C_SOURCE to the latest version before including any headers,
then test the supported version, and when the supported version is
less than the one requested and involves implementation defined
behavior (as in Issue 6) or undefined behavior that's known to be
used to provide extensions (as in SUSv2), check the implementation
version just as the patch does.

>
> So maybe we want an autoconf macro saying whether realpath() accepts
> NULL, and just hardcode it for the targets known to support it, and
> only check _POSIX_VERSION for the unknowns.

That will work for Issue 6 where the realpath behavior is
implementation-defined. The test wouldn't yield reliable results
for SUSv2 implementations where the behavior is undefined. There,
the result would have to be hardcoded based on what the manual says.
An autoconf test won't help with the ENAMETOOLONG problem since it
might depend on the filesystem. To overcome that, libstdc++ would
need to do the path traversal itself.

Martin