On 06/06/16 at 08:27pm, Tobias Stoeckmann wrote:
On Mon, Jun 06, 2016 at 01:27:52AM -0400, Andrew Gregory wrote:
Since we're already talking about unlikely scenarios... My reading of readlink(2) and readlink(3p) suggest this might still run into problems on oddly configured systems. POSIX leaves up to the implementation what happens if bufsize > SSIZE_MAX and nothing guarantees that PATH_MAX is less than SSIZE_MAX.
That is true, in fact we would have to check if PATH_MAX is defined at all. If it's not there, we actually would have to call path_conf to figure it out. And even then it might be -1 to show that we really have no limits at all.
But on the bright side, "currently" this is proven by reality to be no issue, after all nobody filed a bug report for his system, that pacman does not compile. ;)
Same goes for PATH_MAX being larger than SSIZE_MAX. As long as we can trust the system that SSIZE_MAX really states the largest value for an ssize_t and that it has the same size like size_t, we would have run out of stack space looong before even reaching this function call.
I don't follow your logic. SSIZE_MAX is only guaranteed to be at least 32,767. PATH_MAX can easily be larger than that without coming close to exhausting my system's resources. apg