From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by sourceware.org (Postfix) with ESMTPS id 66E66386F407 for ; Fri, 2 Oct 2020 13:20:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 66E66386F407 Received: by mail-wm1-x342.google.com with SMTP id w2so1680950wmi.1 for ; Fri, 02 Oct 2020 06:20:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/JX4Jd0493SLr9+MjpTZSSB8EEv9+SWoccnHkCLNQOs=; b=iyiK1J1bhoJxQJCFJ1WiNFBRFMEUWlajZ1ZSDtNMW2MnLMgT1HLapxrUorEt6r825b S+V2sGL3MQldAFRfqWgTV7rY7eSWW0/4mAZzfZeG70YdxHudMW3oJgEmcnmawki8eZOM lPDUqUQYOsFiYcQVWQgTIlxGz3Yww0u50HbXkWTqqB5LyW+O142mP6dvsRA6lXmD71Zc /H3JfbMguxI/3/vXf7XaLRvhiNAKWgBIhXQ61uWxvk7Fi7Z5YWOg9LE1EEMEVpitngLw kyTIPVKZWBfbLvgFu+lnSADn724cKtLFYE1IBLaZeTTDOFHRhCVnz+JYAbZJOYq4jEUV slPg== X-Gm-Message-State: AOAM5328zoAvgcvcKWSXKfFyqvS4H2CkJh/bQ4xIE0PqEL2lZAtuJz6F SAsWxnGURWy4vypl3KGPteo= X-Google-Smtp-Source: ABdhPJzX+caDkpml67KMGJULyJ4USuiAOmh99POcfkM/aOxt23s2o2Y+Vr8ZKqzcNtbXxxdTknI99Q== X-Received: by 2002:a1c:e283:: with SMTP id z125mr2607245wmg.154.1601644828511; Fri, 02 Oct 2020 06:20:28 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id a81sm1848137wmf.32.2020.10.02.06.20.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 06:20:27 -0700 (PDT) Subject: Re: [PATCH v2 1/2] system_data_types.7: Add 'void *' To: Jonathan Wakely , "Michael Kerrisk (man-pages)" Cc: Paul Eggert , linux-man , GNU C Library , "linux-kernel@vger.kernel.org" , "gcc@gcc.gnu.org" References: <41affebd-3354-9420-0048-bffd14535e95@gmail.com> <20201001154946.104626-2-colomar.6.4.3@gmail.com> <538b683f-01d2-6148-4f1d-1b293eb5cd6b@cs.ucla.edu> <4b86f6e9-0d8a-f14a-73ce-ebbdc9d9edba@gmail.com> From: Alejandro Colomar Message-ID: <63826e82-7a19-0ecc-f73c-56aa560a842f@gmail.com> Date: Fri, 2 Oct 2020 15:20:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, 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: Fri, 02 Oct 2020 13:20:48 -0000 On 2020-10-02 15:06, Jonathan Wakely wrote: > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) > wrote: >> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: >>> >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: >>>> However, it might be good that someone starts a page called >>>> 'type_qualifiers(7)' or something like that. >>> >>> Who is this for? Who is trying to learn C from man pages? Should >>> somebody stop them? >> >> Yes, I think so. To add context, Alex has been doing a lot of work to >> build up the new system_data_types(7) page [1], which I think is >> especially useful for the POSIX system data types that are used with >> various APIs. > > It's definitely useful for types like struct siginfo_t and struct > timeval, which aren't in C. Hi Jonathan, But then the line is a bit diffuse. Would you document 'ssize_t' and not 'size_t'? Would you not document intN_t types? Would you document stdint types, including 'intptr_t', and not 'void *'? I guess the basic types (int, long, ...) can be left out for now, and apart from 'int' those rarely are the most appropriate types for most uses. But other than that, I would document all of the types. And even... when all of the other types are documented, it will be only a little extra effort to document those, so in the future I might consider that. But yes, priority should probably go to Linux/POSIX-only types. Thanks, Alex > > Trying to document C seems like a huge task, ill-suited for man-pages, > and not worth the effort. > > Maybe some people prefer man pages, but for everybody else > https://en.cppreference.com/w/c already exists and seems like a better > use of time. >