On Wed, Mar 28, 2012 at 04:01:45PM -0500, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > That is the cost of using the mkpath convenience function (otherwise,
> > the compiler will complain that ".*" expects an int). We can do it
> > manually, but in practice, do you really expect your PATH environment
> > variable to overflow an int?
>
> I'd think a check like
>
> if (end - p > INT_MAX)
> die("holy cow your PATH is big");
>
> would be good enough. Or even
>
> assert(end - p <= INT_MAX);
>
> if there is some environment limit I forgot about that makes that
> always true.
You can generally only pass a limited amount through execve. In theory
we could putenv() an arbitrarily large string, but I'm not sure we need
to worry about that. The execve limitation ranges from a few pages to a
few dozen pages by default. On recent versions of linux, it is based on
the stack rlimit. But my reading of execve(2) says that individual items
are still capped at 32 pages.
However, you have a much bigger problem with giant PATH elements, which
is that the whole thing is generally going to get stuck in a PATH_MAX
buffer and truncated. I would expect ENAMETOOLONG or EINVAL from execvp
in that case. That's what dietlibc will do. But glibc being glibc, it's
dynamically allocated there.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html