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. > > 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. :)
What about simply using a predetermined buffer length? PATH_MAX isn't really the right size to use for this anyway, which is why POSIX defines SYMLINK_MAX. Since alpm's maximum path length is 1024, using a buffer size of 2048 or 4096 leaves plenty of room for symlinks to point to any alpm-managed file (assuming the link doesn't do anything bizarre like repeat "./" thousands of times). There could be valid symlinks that point to non-managed files that we won't be able to read, but that appears to be the case no matter what we do. apg