From 95f7309cea563ccf7645acb207ff569ef70e36ec Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Thu, 24 Oct 2013 13:19:22 +0300 Subject: [PATCH] Re: [PATCH 1/3] cli: add insert --must-index option --- c9/8beeefb8324ddb3cefb00e5dcaf93dcf348c0d | 132 ++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 c9/8beeefb8324ddb3cefb00e5dcaf93dcf348c0d diff --git a/c9/8beeefb8324ddb3cefb00e5dcaf93dcf348c0d b/c9/8beeefb8324ddb3cefb00e5dcaf93dcf348c0d new file mode 100644 index 000000000..b5bd3072b --- /dev/null +++ b/c9/8beeefb8324ddb3cefb00e5dcaf93dcf348c0d @@ -0,0 +1,132 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 5A12E429E32 + for ; Thu, 24 Oct 2013 03:19:39 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id DARjGxw-64Yz for ; + Thu, 24 Oct 2013 03:19:31 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id 933BB429E29 + for ; Thu, 24 Oct 2013 03:19:31 -0700 (PDT) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id 2CFBD100217; + Thu, 24 Oct 2013 13:19:22 +0300 (EEST) +From: Tomi Ollila +To: David Bremner , Austin Clements +Subject: Re: [PATCH 1/3] cli: add insert --must-index option +In-Reply-To: <87ob6fv8he.fsf@zancas.localnet> +References: <1374365254-13227-1-git-send-email-novalazy@gmail.com> + <87ip048gbj.fsf@qmul.ac.uk> + <20130727151510.GA13750@hili.localdomain> + <87hadtxfrr.fsf@qmul.ac.uk> + <20130912001349.GA18821@hili.localdomain> + <87zjqhv264.fsf@zancas.localnet> + <87bo2xtdp2.fsf@unb.ca> + + <20131023193209.GF20337@mit.edu> <87ob6fv8he.fsf@zancas.localnet> +User-Agent: Notmuch/0.16+115~g11c2ff5 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 24 Oct 2013 10:19:39 -0000 + +On Thu, Oct 24 2013, David Bremner wrote: + +> Austin Clements writes: +> +>> And in libnotmuch, we would do something like +>> +>> notmuch_status_t +>> notmuch_database_open (const char *path, +>> notmuch_database_mode_t mode, +>> const notmuch_options_t *options, +>> notmuch_database_t **database) +>> { +>> notmuch_option_t real_options = NOTMUCH_OPTIONS_INIT; +>> if (real_options.options_length < options.options_length) +>> return error; +>> memmove(&real_options, options, options.options_length); +>> // ... +>> } +>> +> +> Does the C standard guarantee that if two structs have the same initial +> set of members, that they are aligned in a compatible way? I suppose it +> must work, but I'm still curious. + +If we have structures + +struct s1 { + long l1; + void * vp1; + short s1; + int i1; + char c1; +} + +& + +struct s2 { + long l1; + void * vp1; + short s1; + int i1; + char c1; + char c2; + // void * vp2; +}; + +The variables l1, vp1, s1, i1 & c1 have same offset from the beginning of +structure and uses same amount of space in both structures... + +... now the interesting point is what is the size of the structures (does C +compiler add padding to the end (to make the size multiple of something ?) +In any case all the other data is zeroed in the structure and sizeof data +is copied to "real" structure if Austin's suggestion is used... + +> Yet another approach would be to pass in array of descriptors, something +> like the command line argument parsing code does now. +> +> libnotmuch_opt_desc_t options[] = { +> { LIBNOTMUCH_OPT_LOGHOOK, loghook }, +> { 0, 0} +> } +> +> I guess passing a (void *) as the second element of the pair? + +Voidp and only that. Then we can hack other variables using +((char *)0 + (intvar)) or GINT_TO_POINTER... -- beautiful, eh ? ;) + +> Of course it's a bit more work to unpack this way. + +That is negligible to the elegance loss -- and what about bindings ! >;) + + +Tomi -- 2.26.2