From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by sourceware.org (Postfix) with ESMTPS id 346053953C37 for ; Tue, 27 Oct 2020 16:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 346053953C37 Received: by mail-oi1-x241.google.com with SMTP id k65so1858710oih.8 for ; Tue, 27 Oct 2020 09:23:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=NEJ75eazugIxTiGgov7ny2tg8dhF8KBwSIY/K2VIUa4=; b=k98K4qguCHOS3LsG34ckUCHDC0rDeSXX++LTpXmUmz7FH4wwctex6xfQEgmSnHLU2U rhIpvwL2Paap8Nf+SRRiQy9byhiI/Qm/Ojxzoee0Y9jCVR/6s9zVLUhj8l6nQ/54SH/i TMln+L/FpjuDiYENX85m1ZTybhPHOio6B/ZIuJzn1FIrLrzmB2Hq40O65rOADz8oKdIW +yS3uL3P2HpN66E6l46iqohesqAav3BxcuQML002Zir/R0Fg5WeeoSPSNAen+WLHOS6r Ichri0nD+8YVbdIWuLFQQdDHHrg48sBnvYuPlNrpy/HTq1cLD4oPUOLvtflnzEHOPqcx nlkQ== X-Gm-Message-State: AOAM532HZViKyJ3eatgRhzh1h7gO9Yo4WtfvQBhOccJ1dCnVQY8vBe8Q MMz0lQBDwHIbTJVuLxM6Ohd9D2iDzsTeplZNjTQ= X-Google-Smtp-Source: ABdhPJxf30OOcub3IUjG3SD5xn1r3e8t3j3owMe5pBN43+O9xqetjoMtHQUUeD/+aW6OVOclzmoCD0eA0meBVq01ZQ0= X-Received: by 2002:aca:bb41:: with SMTP id l62mr2000939oif.148.1603815779450; Tue, 27 Oct 2020 09:22:59 -0700 (PDT) MIME-Version: 1.0 References: <20201005221247.13065-1-colomar.6.4.3@gmail.com> <87faeeeb-f2e0-7f1e-5692-78b43242f20b@gmail.com> <1e587ddc-99a3-f05a-857d-9d221c0818b1@gmail.com> In-Reply-To: <1e587ddc-99a3-f05a-857d-9d221c0818b1@gmail.com> Reply-To: mtk.manpages@gmail.com From: "Michael Kerrisk (man-pages)" Date: Tue, 27 Oct 2020 17:22:48 +0100 Message-ID: Subject: Re: [PATCH 1/2] system_data_types.7: Add 'off_t' To: Alejandro Colomar Cc: linux-man , "libc-alpha@sourceware.org" , lkml Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 16:23:01 -0000 Hi Alex, On Tue, 27 Oct 2020 at 16:25, Alejandro Colomar wrote: > > > > On 2020-10-27 14:47, Michael Kerrisk (man-pages) wrote: > > On 10/27/20 11:23 AM, Alejandro Colomar wrote: > >> Hi Michael, > >> > >> On 2020-10-07 08:53, Michael Kerrisk (man-pages) wrote: > >>> On 10/6/20 12:12 AM, Alejandro Colomar wrote: > >>>> Signed-off-by: Alejandro Colomar > >>> > >>> Hi Alex, > >>> > >>> Thanks, patch applied. And I trimmed the "See also" a little. > >>> I'd hold off on documenting loff_t and off64_t for the > >>> moment. As you note in another mail, the *lseek* man page > >>> situation is a bit of a mess. I'm not yet sure what to do. > >> > >> > >> I saw a TODO in the page about loff_t. > >> Just wanted to ping you in case you forgot about it (I did). > > > > I didn't forget it exactly. I just don't know that I have the > > inclination to do anything about the messy *llseek* pages. > > > > Thanks, > > > > Michael > > > > > > > Hi Michael, > > I've been reading them to add loff_t and off64_t to sys_data_types. > Now that I've read them (not too deep), > I think that lseek64(3) is good enough, > and maybe we should look for small details > missing there but present on the others, > and merge those to lseek64.3. > And then keep links in the other pages pointing to lseek64.3. > > Any thoughts? Those pages have a long history, and I confess to not understanding all of the details of the history. Looking more closely at the pages, I think they are good enough. Let's leave them alone. (I did apply one patch just now.) Thinking about it further, I don't think it's necessary to document loff_t in system_data_types(7). No APIs in the current glibc headers even use loff_t, as far as I can see. I'm not sure that 'off64_t' really needs documenting there either. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/