Date: Thu, 8 Mar 2012 18:10:11 -0600 From: "Conrad J. Sabatier" <conrads@cox.net> To: freebsd-questions@FreeBSD.org Subject: realpath(3): a curiosity question Message-ID: <20120308181011.0b097de1@cox.net>
next in thread | raw e-mail | index | archive | help
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@cox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120308181011.0b097de1>