Thread (19 messages) flat view 19 messages, 4 authors, 2016-06-15

Re: [PATCH 2/2] git: continue alias lookup on EACCES errors

From: Jeff King <hidden>
Date: 2016-06-15 22:53:25

Possibly related (same subject, not in this thread)

On Wed, Mar 28, 2012 at 04:01:45PM -0500, Jonathan Nieder wrote:
Jeff King wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help