From owner-svn-src-all@freebsd.org Sat Jul 30 20:19:06 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD5B8BA8720 for ; Sat, 30 Jul 2016 20:19:06 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D79A1589 for ; Sat, 30 Jul 2016 20:19:05 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f48.google.com with SMTP id g62so91846790lfe.3 for ; Sat, 30 Jul 2016 13:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=O+qF/okj5rAGEiZDQ9SGEzPMhc8DRr2Edr9qPno5qxc=; b=RVamdyAr5dQkZrbF6Crc19Xl4YpRzHYg71bg48VMUwg2C43Jw4SMrE6c1GdoUAcz9i lmK/+PZbZ+qSKzBE3X+lHKkDXCk37Q/wGcnsv+kFTXLpJN8ZhEXPdwG5zohKtcPHIo9+ tP7bRH0nKHgG87nbxXGmKQ5+VD1r5HJK+ilArBNEK9J2TkjIvWTUZ4lxyYE2yFiTo9IV +psxWfWEKX21Zh8NM+LfQGeUDu0hcjIBUasrlKwWFlgNlts02JsMqiKFQL1vodi33izO qh8ah84SKHUlqATB6PtscOUhq82hJ72S4WzlCZLemO3n+G3qdsrE0/hhKmxgwM+jvGjF TWvw== X-Gm-Message-State: AEkoouuw8rpelCbskBOuXjg21Wut78U0D+AN63YIAn/gET+j8sy8M+Graadw8I20rLCyfQ== X-Received: by 10.25.17.70 with SMTP id g67mr18601007lfi.145.1469909458707; Sat, 30 Jul 2016 13:10:58 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id 62sm3860281ljj.3.2016.07.30.13.10.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jul 2016 13:10:58 -0700 (PDT) Subject: Re: svn commit: r303530 - head/lib/libc/gen To: Bruce Evans References: <201607300209.u6U29BXC082700@repo.freebsd.org> <20160730140305.G1962@besplex.bde.org> <84c77b80-8b51-8698-f27a-7f6452867d66@freebsd.org> <20160730184454.I2661@besplex.bde.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: <71b31670-244e-73e1-2092-4c4de5b8a692@freebsd.org> Date: Sat, 30 Jul 2016 23:10:55 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160730184454.I2661@besplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 20:19:06 -0000 On 30.07.2016 11:52, Bruce Evans wrote: > On Sat, 30 Jul 2016, Andrey Chernov wrote: > >> On 30.07.2016 7:15, Bruce Evans wrote: >>> On Sat, 30 Jul 2016, Andrey A. Chernov wrote: >>> >>>> Log: >>>> Reset errno for readdirfunc() before contunue. >>> >>> In C99, library functions are not permitted to set errno to 0. The >>> glob() >>> family shouldn't use a different (worse) convention, and POSIX doesn't >>> seem to have any special wording to allow different behaviour. BTW, POSIX says so too: "No function in this volume of POSIX.1-2008 shall set errno to 0." >> This is historic practice for this function at least since GLOB_LIMIT >> was introduced (in 2001) and common across NetBSD/OpenBSD. Existent >> programs may relay on that to check that limit is reached and not >> allocation error, so with few additional overwriting from my side I add >> nothing new: >> >> Revision 80525 >> Modified Sun Jul 29 00:52:37 2001 UTC (15 years ago) by mikeh >> ... >> errno = 0 is documented. See glob(3), GLOB_NOSPACE section too. > > Hmm. This is not in the BUGS section. Strangely, the related non-bug > that glob() may fail and set errno (to a reasonable but nonstandard and > undocumented value?) is in the BUGS section. I guess this is a bug > in conjunction with the promise to set errno to 0 for some failures. > >> The real problem is that glob(3) is very limited in error return codes, >> so they reuse existent codes with errno hack. > > It should have just used the least-unclosely-related standard errno > instead of 0. I was thinking about this way too, f.e. E2BIG or ERANGE are nice candidatures, but still can't decide to break cross-BSD compatibility and historic practice.