From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brad King <brad.king@kitware.com>,
Johan Herland <johan@herland.net>, Jeff King <peff@peff.net>,
Vicent Marti <tanoku@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH v3 19/27] refs: add a concept of a reference transaction
Date: Mon, 14 Apr 2014 12:54:31 +0200 [thread overview]
Message-ID: <534BBE67.3040100@alum.mit.edu> (raw)
In-Reply-To: <xmqq8urhlzr1.fsf@gitster.dls.corp.google.com>
On 04/07/2014 09:13 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> +void ref_transaction_create(struct ref_transaction *transaction,
>> + const char *refname,
>> + unsigned char *new_sha1,
>> + int flags)
>> +{
>> + struct ref_update *update = add_update(transaction, refname);
>> +
>> + assert(!is_null_sha1(new_sha1));
>> + hashcpy(update->new_sha1, new_sha1);
>> + hashclr(update->old_sha1);
>> + update->flags = flags;
>> + update->have_old = 1;
>> +}
>> +
>> +void ref_transaction_delete(struct ref_transaction *transaction,
>> + const char *refname,
>> + unsigned char *old_sha1,
>> + int flags, int have_old)
>> +{
>> + struct ref_update *update = add_update(transaction, refname);
>> +
>> + update->flags = flags;
>> + update->have_old = have_old;
>> + if (have_old) {
>> + assert(!is_null_sha1(old_sha1));
>> + hashcpy(update->old_sha1, old_sha1);
>> + }
>> +}
>
> These assert()s will often turn into no-op in production builds. If
> it is a bug in the code (i.e. the callers are responsible for
> catching these conditions and issuing errors, and there are actually
> such checks implemented in the callers), it is fine to have these as
> assert()s, but otherwise these should be 'if (...) die("BUG:")', I
> think.
I forgot to confirm that the callers *do* verify that they don't pass
incorrect values to ref_transaction_create() and
ref_transaction_delete(). But if they wouldn't, then die("BUG:") would
not be appropriate either, would it? It would have to be die("you silly
user...").
Another reason I'm comfortable with only having assert()s in this case
is that even if the preconditions are not met, nothing really crazy
happens. If I were guarding against something nastier, like a buffer
overflow, then I would more likely have used die("BUG:") instead.
It is not material to this discussion, but I wonder how often production
builds use NDEBUG. I just checked that Debian does not; i.e.,
assertions are enabled for git there. Personally I wouldn't run code
built with NDEBUG unless building for a severely resource-constrained
device, and even then I'd be pretty nervous about it.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2014-04-14 10:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-07 13:47 [PATCH v3 00/27] Clean up update-refs --stdin and implement ref_transaction Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 01/27] t1400: fix name and expected result of one test Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 02/27] t1400: provide more usual input to the command Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 03/27] parse_arg(): really test that argument is properly terminated Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 04/27] t1400: add some more tests involving quoted arguments Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 05/27] refs.h: rename the action_on_err constants Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 06/27] update_refs(): fix constness Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 07/27] update-ref --stdin: read the whole input at once Michael Haggerty
2014-04-07 13:47 ` [PATCH v3 08/27] parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 09/27] update-ref.c: extract a new function, parse_refname() Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 10/27] update-ref --stdin: improve error messages for invalid values Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 11/27] update-ref --stdin: make error messages more consistent Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 12/27] update-ref --stdin: simplify error messages for missing oldvalues Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 13/27] t1400: test that stdin -z update treats empty <newvalue> as zeros Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 14/27] update-ref.c: extract a new function, parse_next_sha1() Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 15/27] update-ref --stdin -z: deprecate interpreting the empty string as zeros Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 16/27] t1400: test one mistake at a time Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 17/27] update-ref --stdin: improve the error message for unexpected EOF Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 18/27] update-ref --stdin: harmonize error messages Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 19/27] refs: add a concept of a reference transaction Michael Haggerty
2014-04-07 19:13 ` Junio C Hamano
2014-04-14 10:54 ` Michael Haggerty [this message]
2014-04-14 21:25 ` Junio C Hamano
2014-04-15 5:41 ` Michael Haggerty
2014-04-15 7:40 ` Junio C Hamano
2014-04-07 13:48 ` [PATCH v3 20/27] update-ref --stdin: reimplement using reference transactions Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 21/27] refs: remove API function update_refs() Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 22/27] struct ref_update: rename field "ref_name" to "refname" Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 23/27] struct ref_update: store refname as a FLEX_ARRAY Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 24/27] ref_transaction_commit(): simplify code using temporary variables Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 25/27] struct ref_update: add a lock field Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 26/27] struct ref_update: add a type field Michael Haggerty
2014-04-07 13:48 ` [PATCH v3 27/27] ref_transaction_commit(): work with transaction->updates in place Michael Haggerty
2014-04-11 19:57 ` [PATCH v3 00/27] Clean up update-refs --stdin and implement ref_transaction Ronnie Sahlberg
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=534BBE67.3040100@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=brad.king@kitware.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=peff@peff.net \
--cc=tanoku@gmail.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).