From: Adam Wolfe Gordon Date: Mon, 9 Apr 2012 15:46:48 +0000 (+1800) Subject: Re: [PATCH 2/4] dirent->d_type not available on Soalris X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=500aff0719adc41fd283025a93277c52a823d290;p=notmuch-archives.git Re: [PATCH 2/4] dirent->d_type not available on Soalris --- diff --git a/dc/e3addfa108ccfd4c9a08723352bd23a169e49a b/dc/e3addfa108ccfd4c9a08723352bd23a169e49a new file mode 100644 index 000000000..b76239050 --- /dev/null +++ b/dc/e3addfa108ccfd4c9a08723352bd23a169e49a @@ -0,0 +1,90 @@ +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 9C4B0417330 + for ; Mon, 9 Apr 2012 08:46:52 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 Y7btr283TDyw for ; + Mon, 9 Apr 2012 08:46:51 -0700 (PDT) +Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com + [209.85.217.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 8D694417322 + for ; Mon, 9 Apr 2012 08:46:51 -0700 (PDT) +Received: by lban1 with SMTP id n1so2151991lba.26 + for ; Mon, 09 Apr 2012 08:46:48 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=google.com; s=20120113; + h=mime-version:sender:x-originating-ip:in-reply-to:references:date + :x-google-sender-auth:message-id:subject:from:to:content-type + :x-gm-message-state; + bh=jYf3WZ/KdVSarJ/GD3eUBvak5Rg8ru1l64judCndEGw=; + b=k1bxYdBK6glTKsC2UFOVYCK/1XdNQv/VoOHX/YX3wk3He3ZU6AiuqwywyWnD8SXmXJ + 16VFrUUBLbjZQXQgNbIrzU567AtXeLwlCRjFt8x67dofuRtJEyuOIyFVQzxyZ6BKh+dp + AIzDXF8oVm7DbVkK+io5L+Q8JVKfq3dw9+FFe3siqunsHpXThzSpWjNzUGM8COjmKXKk + lGFSNx9Gg2aCdZ6yUQtTY4YVhSsXPebDERdFR1rCi0OXNs1IS9fWlc4eUHqMrHZH0c4Z + KtkMuAhoXYS7D5PSFLjGcWgBqqEKg2VamC8xBlK0wvWETy3YDw6dyyHgopbQvMe04DSO + JHrg== +MIME-Version: 1.0 +Received: by 10.152.112.161 with SMTP id ir1mr12148984lab.13.1333986408438; + Mon, 09 Apr 2012 08:46:48 -0700 (PDT) +Sender: awg@xvx.ca +Received: by 10.112.97.14 with HTTP; Mon, 9 Apr 2012 08:46:48 -0700 (PDT) +X-Originating-IP: [128.221.197.57] +In-Reply-To: <20120409151258.GB10554@pub.czech.sun.com> +References: <1333966665-10469-1-git-send-email-Vladimir.Marek@oracle.com> + <1333966665-10469-3-git-send-email-Vladimir.Marek@oracle.com> + + <20120409151258.GB10554@pub.czech.sun.com> +Date: Mon, 9 Apr 2012 09:46:48 -0600 +X-Google-Sender-Auth: cFbPKTGG27IfhA76xuicJyn5pAM +Message-ID: + +Subject: Re: [PATCH 2/4] dirent->d_type not available on Soalris +From: Adam Wolfe Gordon +To: Notmuch Mail +Content-Type: text/plain; charset=ISO-8859-1 +X-Gm-Message-State: + ALoCoQl3E8S3h8NubFEqV4NB1FMNrSgPlHhn+1rd1bMtqacAPI4HSmDzPjhlzvNfhXdFrFfdq/b/ +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: Mon, 09 Apr 2012 15:46:52 -0000 + +On Mon, Apr 9, 2012 at 09:12, Vladimir Marek wrote: +> Fair enough. Is there some performance test suite? Another way would be +> to make this compile time option set by configure. Used only when the +> system in question does not have dirent->d_type member. + +I like the idea of making it configurable. From the Linux readdir(3) man page: + +> Under glibc, programs can check for the availability +> of the fields not defined in POSIX.1 by testing whether +> the macros _DIRENT_HAVE_D_NAMLEN, +> _DIRENT_HAVE_D_RECLEN, _DIRENT_HAVE_D_OFF, +> or _DIRENT_HAVE_D_TYPE are defined. + +I read this as meaning that we can just test for _DIRENT_HAVE_D_TYPE +instead of adding our own define. + +I expect the stat system calls will provide some overhead, and there's +no real need to pay that overhead on systems where it isn't necessary. + +-- Adam