Message ID | 20201005221247.13065-1-colomar.6.4.3@gmail.com |
---|---|
State | Not applicable |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 016B4385DC2E; Mon, 5 Oct 2020 22:13:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 016B4385DC2E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601935985; bh=piSDHxMppi0CIXJC6D3VAsGPOqAg8EM3DNDGhvsCgQE=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=i8MLu0a+HWGi5Gm8D1yU9hdLQLYwabOWF7ywtIpj0TfL6fw+NkNUN71zkQyPxvjdS sYKgKlTNyiXfXm/O/fQUS+7siSFda9uidpAeuN3quVCC2XQVwShF1vDO5wvWUvRi5W kq1MPr+Udq4bA0Mll4GwHz1bKknn62Ut0f31AMI0= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id AE7BA3857C50 for <libc-alpha@sourceware.org>; Mon, 5 Oct 2020 22:13:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE7BA3857C50 Received: by mail-wm1-x343.google.com with SMTP id p15so973889wmi.4 for <libc-alpha@sourceware.org>; Mon, 05 Oct 2020 15:13:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=piSDHxMppi0CIXJC6D3VAsGPOqAg8EM3DNDGhvsCgQE=; b=NFTi0NfMAqG+1+IVGDrWSzCaMCJNxiNtvWDTyu0zI1HgAf4Q30QVveMLbEPQ29BHuf 2+4hCL9Fbio3EcSalzSYPsLUA/T6J17bDDOBhMTqQ9VsxmHsb+f4/KaTuDcunw5d4oXG /O64go/xMq1Op3sJDFee6dCPphJ8iR3XKf+5ddxayIbR5uaalibsVzeW6r0M0vuJi6Jj aTXzoweF+lw9gFjnIjEf5KWrDLLD2YrwHjhUjcLJQGd3wNEYsDyCTpWl3LOKddK/UBjl R1rxESgvbl3b8ymXMpWss+hcruVbGX/VLgYjbXQU/C4lBsuForgfBhvt6AH8kDOrlgwb 5oWw== X-Gm-Message-State: AOAM532yBtS4Mokwlds3CbCypLL1AR35XFaYv4+xcUuoEbAUrdYxEUVV Nn8BJzKXFf0S8yN04aVH1Is= X-Google-Smtp-Source: ABdhPJzFptfrOBEvjsr0ExMzMNTfxtXm2+xg4ZoX74v5MTkAHvGFEpZczP5URnDQtn+ZCch6ovYfww== X-Received: by 2002:a1c:2042:: with SMTP id g63mr1404387wmg.174.1601935981859; Mon, 05 Oct 2020 15:13:01 -0700 (PDT) Received: from localhost.localdomain ([170.253.60.68]) by smtp.googlemail.com with ESMTPSA id g12sm1552581wro.89.2020.10.05.15.13.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 15:13:01 -0700 (PDT) To: mtk.manpages@gmail.com Subject: [PATCH 1/2] system_data_types.7: Add 'off_t' Date: Tue, 6 Oct 2020 00:12:47 +0200 Message-Id: <20201005221247.13065-1-colomar.6.4.3@gmail.com> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, KAM_ASCII_DIVIDERS, 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 <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Alejandro Colomar <colomar.6.4.3@gmail.com> Cc: Alejandro Colomar <colomar.6.4.3@gmail.com>, linux-man@vger.kernel.org, libc-alpha@sourceware.org, linux-kernel@vger.kernel.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
[1/2] system_data_types.7: Add 'off_t'
|
|
Commit Message
Alejandro Colomar
Oct. 5, 2020, 10:12 p.m. UTC
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
---
man7/system_data_types.7 | 50 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
Comments
On 10/6/20 12:12 AM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com> 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. Thanks, Michael > --- > man7/system_data_types.7 | 50 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 > index b8cbc8ffe..916efef08 100644 > --- a/man7/system_data_types.7 > +++ b/man7/system_data_types.7 > @@ -629,6 +629,56 @@ C99 and later; POSIX.1-2001 and later. > See also: > .BR lldiv (3) > .RE > +.\"------------------------------------- off_t ------------------------/ > +.TP > +.I off_t > +.RS > +Include: > +.IR <sys/types.h> . > +Alternatively, > +.IR <aio.h> , > +.IR <fcntl.h> , > +.IR <stdio.h> , > +.IR <sys/mman.h> , > +.IR <sys/stat.h.h> , > +or > +.IR <unistd.h> . > +.PP > +Used for file sizes. > +According to POSIX, > +this shall be a signed integer type. > +.PP > +Versions: > +.I <aio.h> > +and > +.I <stdio.h> > +define > +.I off_t > +since POSIX.1-2008. > +.PP > +Conforming to: > +POSIX.1-2001 and later. > +.PP > +See also: > +.BR fallocate (2), > +.BR lseek (2), > +.BR mmap (2), > +.BR mmap2 (2), > +.BR posix_fadvise (2), > +.BR pread (2), > +.BR preadv (2), > +.BR truncate (2), > +.BR fseeko (3), > +.BR getdirentries (3), > +.BR lockf (3), > +.BR posix_fallocate (3) > +.\".PP TODO: loff_t, off64_t > +.\"See also the > +.\".I loff_t > +.\"and > +.\".I off64_t > +.\"types in this page. > +.RE > .\"------------------------------------- pid_t ------------------------/ > .TP > .I pid_t >
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 <colomar.6.4.3@gmail.com> > > 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). Thanks, Alex
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 <colomar.6.4.3@gmail.com> >> >> 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
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 <colomar.6.4.3@gmail.com> >>> >>> 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? Cheers, A
Hi Alex, On Tue, 27 Oct 2020 at 16:25, Alejandro Colomar <colomar.6.4.3@gmail.com> 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 <colomar.6.4.3@gmail.com> > >>> > >>> 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/
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index b8cbc8ffe..916efef08 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -629,6 +629,56 @@ C99 and later; POSIX.1-2001 and later. See also: .BR lldiv (3) .RE +.\"------------------------------------- off_t ------------------------/ +.TP +.I off_t +.RS +Include: +.IR <sys/types.h> . +Alternatively, +.IR <aio.h> , +.IR <fcntl.h> , +.IR <stdio.h> , +.IR <sys/mman.h> , +.IR <sys/stat.h.h> , +or +.IR <unistd.h> . +.PP +Used for file sizes. +According to POSIX, +this shall be a signed integer type. +.PP +Versions: +.I <aio.h> +and +.I <stdio.h> +define +.I off_t +since POSIX.1-2008. +.PP +Conforming to: +POSIX.1-2001 and later. +.PP +See also: +.BR fallocate (2), +.BR lseek (2), +.BR mmap (2), +.BR mmap2 (2), +.BR posix_fadvise (2), +.BR pread (2), +.BR preadv (2), +.BR truncate (2), +.BR fseeko (3), +.BR getdirentries (3), +.BR lockf (3), +.BR posix_fallocate (3) +.\".PP TODO: loff_t, off64_t +.\"See also the +.\".I loff_t +.\"and +.\".I off64_t +.\"types in this page. +.RE .\"------------------------------------- pid_t ------------------------/ .TP .I pid_t