From: Johan Herland <johan@herland•net>
To: "Shawn O. Pearce" <spearce@spearce•org>
Cc: git@vger•kernel.org, gitster@pobox•com
Subject: Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
Date: Tue, 08 Dec 2009 02:55:17 +0100 [thread overview]
Message-ID: <200912080255.17568.johan@herland.net> (raw)
In-Reply-To: <20091207164311.GE17173@spearce.org>
On Monday 07 December 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland•net> wrote:
> > +static unsigned char convert_num_notes_to_fanout(uintmax_t num_notes)
> > +{
> > + unsigned char fanout = 0;
> > + while ((num_notes >>= 8))
> > + fanout++;
> > + return fanout;
> > +}
> > +
> > +static void construct_path_with_fanout(const char *hex_sha1,
> > + unsigned char fanout, char *path)
> > +{
> > + unsigned int i = 0, j = 0;
> > + if (fanout >= 20)
> > + die("Too large fanout (%u)", fanout);
>
> Shouldn't convert_num_notes_to_fanout have a guard to prevent this
> case from happening?
Well, it sort of already does (unless uintmax_t is more than 19 * 8 = 152
bits wide... ;)
Not sure what you're getting at:
- Should I add a "&& fanout < 19" condition to the while loop in
convert_num_notes_to_fanout()?
- Should I remove the "if (fanout >= 20) die(...)"? Of course,
construct_path_with_fanout() is only supposed to be called with values
returned from convert_num_notes_to_fanout(), so the condition only tests a
precondition that we believe to be true (FTR, it was converted from an
equivalent assert() in an earlier iteration), but I normally test for these
things anyway (when they are not blindingly obvious), just to make sure...
(and I believe a die(...) is kinder to the user than a segfault...)
...Johan
--
Johan Herland, <johan@herland•net>
www.herland.net
next prev parent reply other threads:[~2009-12-08 1:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 11:27 [RFC/PATCHv10 00/11] git notes Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation Johan Herland
2009-12-07 16:41 ` Shawn O. Pearce
2009-12-08 1:44 ` Johan Herland
2009-12-08 2:01 ` Shawn O. Pearce
2009-12-08 2:45 ` Johan Herland
2009-12-10 9:39 ` Johan Herland
2009-12-10 14:03 ` Shawn O. Pearce
2009-12-10 14:40 ` Johan Herland
2009-12-11 3:00 ` Junio C Hamano
2009-12-07 16:43 ` Shawn O. Pearce
2009-12-08 1:55 ` Johan Herland [this message]
2009-12-08 1:59 ` Shawn O. Pearce
2009-12-07 20:42 ` Junio C Hamano
2009-12-08 2:34 ` Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 02/11] Rename t9301 to t9350, to make room for more fast-import tests Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 03/11] Add more testcases to test fast-import of notes Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 04/11] Minor style fixes to notes.c Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 05/11] Notes API: get_commit_notes() -> format_note() + remove the commit restriction Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 06/11] Notes API: init_notes(): Initialize the notes tree from the given notes ref Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 07/11] Notes API: add_note(): Add note objects to the internal notes tree structure Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 08/11] Notes API: get_note(): Return the note annotating the given object Johan Herland
2009-12-07 20:52 ` Junio C Hamano
2009-12-08 3:18 ` Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 09/11] Notes API: for_each_note(): Traverse the entire notes tree with a callback Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 10/11] Notes API: Allow multiple concurrent notes trees with new struct notes_tree Johan Herland
2009-12-07 11:27 ` [RFC/PATCHv10 11/11] Refactor notes concatenation into a flexible interface for combining notes Johan Herland
2009-12-08 9:25 ` [RFC/PATCHv10 00/11] git notes Junio C Hamano
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=200912080255.17568.johan@herland.net \
--to=johan@herland$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=spearce@spearce$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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