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