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. If I wouldn't have been able to trigger a segfault with an adjusted file system, I would have skipped sending this patch for being just a bad fairy tale. But a crashing pacman on a broken file system sounds worse than a system with such a PATH_MAX -- and that still wants to use pacman. :)
