realpath(3): a curiosity question

[Conrad J. Sabatier]

I'm just wondering if anyone knows the rationale behind the differing
return codes from realpath() for non-existent paths, depending on
whether the non-existent element of a path is at the end of the
path or if it occurs somewhere further up the chain.

Not asking that it be changed, mind you.  Just wondering why it was
decided to distinguish between these two cases.  From the programmer's
perspective, this is something of a minor annoyance, as running a
non-existent path through realpath() may or may not return NULL, and
therefore still requires additional code to further validate the path
returned in the non-NULL case.

Granted, the stated purpose of this function is not to verify a path's
existence, but nonetheless, having a function that might be called
non-deterministic in the results it returns just seems, well, *bad* to
me (for lack of a better word at the moment).

Does anyone have any idea what the reasoning is behind this design?

-- 
Conrad J. Sabatier
conrads at cox.net