From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] attr: don't confuse prefixes with leading directories
Date: Tue, 10 Jan 2012 14:32:06 -0500 [thread overview]
Message-ID: <20120110193206.GA16826@sigill.intra.peff.net> (raw)
In-Reply-To: <20120110192810.GA16018@sigill.intra.peff.net>
On Tue, Jan 10, 2012 at 02:28:10PM -0500, Jeff King wrote:
> On Tue, Jan 10, 2012 at 11:23:01AM -0800, Junio C Hamano wrote:
>
> > > I'm not sure if the right solution is to change the popping loop to:
> > >
> > > /* we will never run out of stack, because we always have the root */
> > > while (attr_stack->origin) {
> > > ...
> >
> > Yeah, that makes sense, as that existing check "attr_stack &&" was a
> > misguided defensive coding, that was _not_ defensive at all as we didn't
> > do anything after we stop iterating from that loop and without checking
> > dereferenced attr_stack->origin, which was a simple bogosity.
> >
> > >
> > > Or to be extra defensive and put:
> > >
> > > if (!attr_stack)
> > > die("BUG: we ran out of attr stack!?");
> > >
> > > after the loop, or to somehow handle the case of an empty attr stack
> > > below (which is hard to do, because it can't be triggered, so I have no
> > > idea what it would mean).
> >
> > And this is even more so.
>
> I wasn't clear: the second one is "even more so" making sense, or "even
> more so" misguided defensive coding?
If the latter, then I think we want this:
-- >8 --
Subject: [PATCH] attr: drop misguided defensive coding
In prepare_attr_stack, we pop the old elements of the stack
(which were left from a previous lookup and may or may not
be useful to us). Our loop to do so checks that we never
reach the top of the stack. However, the code immediately
afterwards will segfault if we did actually reach the top of
the stack.
Fortunately, this is not an actual bug, since we will never
pop all of the stack elements (we will always keep the root
gitattributes, as well as the builtin ones). So the extra
check in the loop condition simply clutters the code and
makes the intent less clear. Let's get rid of it.
Signed-off-by: Jeff King <peff@peff.net>
---
attr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index fa975da..cf8f2bc 100644
--- a/attr.c
+++ b/attr.c
@@ -577,7 +577,7 @@ static void prepare_attr_stack(const char *path)
* Pop the ones from directories that are not the prefix of
* the path we are checking.
*/
- while (attr_stack && attr_stack->origin) {
+ while (attr_stack->origin) {
int namelen = strlen(attr_stack->origin);
elem = attr_stack;
--
1.7.9.rc0.33.gd3c17
next prev parent reply other threads:[~2012-01-10 19:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 7:03 [BUG] gitattribute macro expansion oddity Jeff King
2012-01-10 9:01 ` Michael Haggerty
2012-01-10 17:11 ` Jeff King
2012-01-10 18:08 ` [PATCH] attr: don't confuse prefixes with leading directories Jeff King
2012-01-10 18:21 ` Jeff King
2012-01-10 19:23 ` Junio C Hamano
2012-01-10 19:28 ` Jeff King
2012-01-10 19:32 ` Jeff King [this message]
2012-01-10 20:25 ` Junio C Hamano
2012-01-10 22:31 ` Jeff King
2012-01-10 19:25 ` Junio C Hamano
2012-01-10 17:22 ` [BUG] gitattribute macro expansion oddity Junio C Hamano
2012-01-11 4:37 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120110193206.GA16826@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).