Message ID | 20201001150638.102544-1-colomar.6.4.3@gmail.com |
---|---|
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 3D37C398B464; Thu, 1 Oct 2020 15:07:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3D37C398B464 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601564822; bh=agvrGpgDrH5qNLTLM7psr6FXV6CRbe2pCP0Jtc60da0=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=lq9yxQ7LgsyTw18Xk/E8IoutfExYoSbA7GXySsha7jj8w53vukeNqEoAOiN3Tx6+L 8JcFg4eEH2fLA82Icy6weAtmrsvg68StSZoQcDa7sUPAY+PmCsUUhWVvWeTL1RLcVf g1KQAt69ZFP6Ry3SQTaFZEA3khjvbpV7gOsrXwUY= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 1C770398B15C for <libc-alpha@sourceware.org>; Thu, 1 Oct 2020 15:06:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1C770398B15C Received: by mail-wr1-x433.google.com with SMTP id k10so6208001wru.6 for <libc-alpha@sourceware.org>; Thu, 01 Oct 2020 08:06:59 -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=agvrGpgDrH5qNLTLM7psr6FXV6CRbe2pCP0Jtc60da0=; b=PzVsRS+4x5b84Eanjr7f1NNvcb/LztKsX8Ils/hCu07qtdA1MKr1g5mNeHjExzloPp Gec0l8MT9vXPUgx5N+yanPHfYIy5o/T8jzmY6qsXL+uhcY/kfDErmEnga29pUQnU+KUD MpYC7y+Z5rPlOFCSdDfucU6e4WDxdZf6lhAQqvwsYDjPsVfUhvK0xfagdd6hJJt6Ey+8 4NutrT/uvnscglBpPrNJvMX4v+QgYYMqr1kgRAj0S4Gs6gZF0/ojYV2E/uVDyZbrbHtO z12Z0f9XNjKaBCVOpfttuBVT/B+YeNuX9XPZjerqij9QeW/Iqps5fxgmJLGEDTh8sJ9T iv7Q== X-Gm-Message-State: AOAM5305kjRgKnUuIYTbSzlPTv/y2C7SwNOeKPU1x5klR6UCwzEM8d73 pRZs4SKd3BmY+59Oo1uiTkQ= X-Google-Smtp-Source: ABdhPJzPUfaekBNaCnjr8Op1ahcsSXKml9SUEEuXHWa4LmF5IFwTAfo6ZBL8y9Ti5ITWuOuLWbISiw== X-Received: by 2002:a5d:40c4:: with SMTP id b4mr9574693wrq.151.1601564818247; Thu, 01 Oct 2020 08:06:58 -0700 (PDT) Received: from localhost.localdomain ([170.253.60.68]) by smtp.googlemail.com with ESMTPSA id f5sm351238wmh.16.2020.10.01.08.06.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Oct 2020 08:06:57 -0700 (PDT) To: mtk.manpages@gmail.com Subject: [PATCH 0/2] Document void * Date: Thu, 1 Oct 2020 17:06:37 +0200 Message-Id: <20201001150638.102544-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=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, 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, gcc@gcc.gnu.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Document void *
|
|
Message
Alejandro Colomar
Oct. 1, 2020, 3:06 p.m. UTC
Hello Michael, This type is very special, so I will probably have missed some details about it. Also, do you like the link name? For anyone reading this, please comment :) Cheers, Alex Alejandro Colomar (2): system_data_types.7: Add 'void *' void-*.3: New link to system_data_types(7) man3/void-*.3 | 1 + man7/system_data_types.7 | 42 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 41 insertions(+), 2 deletions(-) create mode 100644 man3/void-*.3
Comments
Hello Alex, On 10/1/20 5:06 PM, Alejandro Colomar wrote: > Hello Michael, > > This type is very special, > so I will probably have missed some details about it. I do wonder if we actually need this in page at all, and given: > Also, do you like the link name? I really don't like it... I don't want to create files whose names are globbing characters; that's a road to pain. So, even if we did document this type in the page, I don't think we can have a good link name. (I suppose we could add it to the pagewithout having a link.) Thanks, Michael
Hi Michael, On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote: > Hello Alex, > > On 10/1/20 5:06 PM, Alejandro Colomar wrote: >> Hello Michael, >> >> This type is very special, >> so I will probably have missed some details about it. > > I do wonder if we actually need this in page at all, and given: I think it should be. I would also document 'void', even if it's a bit weird... They are very useful, so why not document them? > >> Also, do you like the link name? > > I really don't like it... I don't want to create files > whose names are globbing characters; that's a road to pain. Yeah, me neither... :) > > So, even if we did document this type in the page, > I don't think we can have a good link name. (I suppose we > could add it to the pagewithout having a link.) But maybe we can have a link void.3. > > Thanks, > > Michael > Thanks, Alex
On Thu, 1 Oct 2020 at 16:51, Alejandro Colomar via Gcc <gcc@gcc.gnu.org> wrote: > > Hi Michael, > > On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote: > > Hello Alex, > > > > On 10/1/20 5:06 PM, Alejandro Colomar wrote: > >> Hello Michael, > >> > >> This type is very special, > >> so I will probably have missed some details about it. > > > > I do wonder if we actually need this in page at all, and given: > > > I think it should be. > I would also document 'void', even if it's a bit weird... > They are very useful, so why not document them? Because the man-pages are not a tutorial for the C language. "The Linux man-pages project documents the Linux kernel and C library interfaces that are employed by user-space programs." void and void* are not APIs.
Hi Jonathan! On 10/2/20 3:19 PM, Jonathan Wakely wrote: > On Thu, 1 Oct 2020 at 16:51, Alejandro Colomar via Gcc <gcc@gcc.gnu.org> wrote: >> >> Hi Michael, >> >> On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote: >>> Hello Alex, >>> >>> On 10/1/20 5:06 PM, Alejandro Colomar wrote: >>>> Hello Michael, >>>> >>>> This type is very special, >>>> so I will probably have missed some details about it. >>> >>> I do wonder if we actually need this in page at all, and given: >> >> >> I think it should be. >> I would also document 'void', even if it's a bit weird... >> They are very useful, so why not document them? > > Because the man-pages are not a tutorial for the C language. > > "The Linux man-pages project documents the Linux kernel and C library > interfaces that are employed by user-space programs." > > void and void* are not APIs. Agreed, but the rationale of the page is to document topics that are helpful when using the APIs. And, as I noted already stuff like 'void *' is borerline, but I think it's helpful to have some info summarized in one place. And, additionally, POSIX adds a detail to the C standard (casting between void * and function pointer). By the way, thanks for all of your input so far. Among other things, it made me realize that some navigational corrections were needed. Cheers, Michael