From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36706 invoked by alias); 18 May 2017 09:42:09 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 36677 invoked by uid 89); 18 May 2017 09:42:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=surprising X-HELO: smtp.pacific.net From: Rical Jasan Subject: Re: [PATCH v3 4/7] manual: Refactor errno @comments. To: Zack Weinberg References: <58d7508efdc950d8b6bb53532b290845a9affa9c.1494920105.git.ricaljasan@pacific.net> Cc: Joseph Myers , GNU C Library , Carlos O'Donell , Michael Kerrisk Message-ID: <96efa163-cda4-443e-4182-0ec281517eec@pacific.net> Date: Thu, 18 May 2017 09:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00531.txt.bz2 On 05/17/2017 06:21 AM, Zack Weinberg wrote: > On Wed, May 17, 2017 at 12:44 AM, Rical Jasan > >> I was unaware of these dependencies---thanks for pointing them out. >> Nothing I've encountered indicated their existence, though "DO NOT >> REMOVE" makes a little more sense. >> >> After hacking on this a bit, I think this patch should be rescinded. >> Fixing the errlist.awks is easy, but it does nothing to help the screwy, >> Texinfo @comment-based dependency that is just asking for trouble. I'd >> like to propose an @errno{} macro to handle these, and then update the >> errlist.awks accordingly. Something like: >> >> @errno{EPERM, 1, Operation not permitted} >> >> should make the Awk scripts practically benign... > > This seems like a reasonable plan to me. Note that > https://sourceware.org/ml/libc-alpha/2017-05/msg00198.html also makes > changes in this area. Thanks for the heads-up on the pending changes. I've started a patch for this, adding @errno, converting the @comments in errno.texi, and updating sysdeps/gnu/errlist.awk so the generated errlist.c is unchanged, but I also want to add some consistency checking to it. I looked at sysdeps/mach/hurd/errnos.awk; seems to be similar. I'll get it started and make sure to follow your work. I'll ignore the NaCl bits since it sounds like that's going away soon. > I think the error *numbers* shouldn't be embedded in the manual. Only I had the same thought; very surprising to find the sources were being generated from the manual. I also thought it was strange because I remember a conversation a while back where it was pointed out the source and documentation are under different licences and generally couldn't cross-reference each other like that. [1] That conversation should have been on libc-alpha, but happened on libc-help (my fault). > Hurd uses these, and so it's not obvious that this part of the manual > has ABI implications but only for Hurd. It would be better if those > came from a sysdeps/ file - sysdeps/mach/hurd/bits/errno.h.in maybe? > It can't just be sysdeps/mach/hurd/bits/errno.h because the Hurd > errnos.awk pulls additional error numbers from several other places > (unfortunately, all of them are Mach headers that aren't in tree, > IIRC). This is.. interesting. If we do make a sysdeps/mach/hurd/bits/errno.h.in, it seems doing similarly for sysdeps/gnu/errlist.c would be the way to go, removing the dependency on the manual entirely (errlist.c is only generated from errno.texi). Separate input files for each is still quite a bit of duplication though (E* macros and error strings), so maybe an equivalent to the proposed @errno in something like misc/errno.? that both scripts could use would be more suitable? For now, I'll stick with using @errno in errno.texi, and figure out a way to validate the generated Hurd errno.h. Rical [1] https://sourceware.org/ml/libc-help/2016-10/msg00015.html