From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id 2EC483953819 for ; Mon, 28 Sep 2020 14:51:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2EC483953819 Received: by mail-wm1-x341.google.com with SMTP id v12so1451236wmh.3 for ; Mon, 28 Sep 2020 07:51:41 -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=xO67P31SiFpAjaEFj6KzNiP3I8rXIMv/IEdqg/GSCJc=; b=V3hCHdFORm5JIDSaDSdDuqIgE+1ZgvGuFX6BEvwRAi9Az4bb1M8jXC4gAOJpEG3u4Y L0d0h1IKK4vEA2CaHnE4MJHsTrbksbL9y7UwYYi4qu1QJZkH3AtPzR9LBaWm8Hf5ABVS B+1/GW9XFkb6ElolRjBjXOFi0s86lqjifivauje5xnr8U92hibL9ct8DLboLIe4FNTGz /g8e1Ak7RGVc7fTQa1+zc0WpfyfdJEDXS2glw/O5y9HtaUp/3eAn05QElN6B6p6sH4w5 BL2c6QmCPKgLvOTK5eMTh7WXjWorYn61t8RpY6CD/AAsDm88Ibew1O3bkWD8t8+XGAmv r9vQ== X-Gm-Message-State: AOAM5314ak9YaxiSIlFCrIuGqqioUdLKW2aslXZx6sQTkSQHNnOifdFt Aysejc2vRiydJlsjXr61fww+21XtJ1k= X-Google-Smtp-Source: ABdhPJx5GMpPznCsYp0zG+NmtpC3lJYZnlAMiQSphRnQGp/Vtbg54174SSTCvW7wgV6HdRWp5py4pA== X-Received: by 2002:a1c:7c1a:: with SMTP id x26mr2123289wmc.112.1601304699944; Mon, 28 Sep 2020 07:51:39 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id z15sm1812253wrv.94.2020.09.28.07.51.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 07:51:39 -0700 (PDT) Subject: Re: [PATCH 1/2] system_data_types.7: Document size_t To: Dave Martin , "G. Branden Robinson" Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org, libc-alpha@sourceware.org References: <20200918112755.21428-1-colomar.6.4.3@gmail.com> <20200918112755.21428-2-colomar.6.4.3@gmail.com> <20200928134122.GG6642@arm.com> <8ce3d63c-445f-827b-a49a-914e8dd622d4@gmail.com> <20200928135506.2wsf3cwvkkbreqa3@localhost.localdomain> <20200928141524.GH6642@arm.com> From: Alejandro Colomar Message-ID: Date: Mon, 28 Sep 2020 16:51:38 +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: <20200928141524.GH6642@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 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: Mon, 28 Sep 2020 14:51:42 -0000 Hi Dave! On 2020-09-28 16:15, Dave Martin wrote: > On Mon, Sep 28, 2020 at 11:55:08PM +1000, G. Branden Robinson wrote: >> Hi, Alex! >> >> At 2020-09-28T15:48:14+0200, Alejandro Colomar wrote: >>>> Where does this arbitrary-looking list of headers come from? >>> >>> There are two parts: left to the ';', and right to the ';'. >>> >>> Left: The canonical C standard header, and the canonical POSIX header, >>> in alphabetical order. >>> >>> Right: All other headers that shall define the header, according to >>> either the C or the POSIX standards, in alphabetical order. > > To clarify, does POSIX _guarantee_ that all of those headers define this > type? (I admit I'm too lazy to search through the POSIX standard for an > answer to this). Yes, POSIX does guarantee that all those headers define the type. > > If not, this list would serve only to legitimise bad habits and it may > be better to leave it out. > > >> That's not a bad scheme but it is not inferable from the current man >> page text; I almost commented on the inconsistency in one of my earlier >> messages but deemed it out of scope. Please document it, perhaps in an >> introductory paragraph at the top of the Description section. > > Ack, I think it would be better to state this explicity rather than > having some terse syntax that people need to understand. Would you like to propose something? > > > IIUC, a program intended to be fully portable between C implementations > must include , not rely on one of the others. Yes, in principle, programmers should use the first header in the list. However, we listed all of them for completeness. We only listed headers that guarantee to define the type, thogh, either by C or POSIX: .\" Layout: .\" A list of type names (the struct/union keyword will be omitted). .\" Each entry will have the following parts: .\" * Include .\" The headers will be in the following order: .\" 1) The main header that shall define the type .\" according to the C Standard, .\" and .\" the main header that shall define the type .\" according to POSIX, .\" in alphabetical order. .\" ; .\" 2) All other headers that shall define the type .\" as described in the previous header(s) .\" according to the C Standard or POSIX, .\" in alphabetical order. .\" *) All headers that define the type .\" *if* the type is not defined by C nor POSIX, .\" in alphabetical order. .\" .\" * Definition (no "Definition" header) .\" Only struct/union types will have definition; .\" typedefs will remain opaque. .\" .\" * Description (no "Description" header) .\" A few lines describing the type. .\" .\" * Conforming to .\" Format: CXY and later; POSIX.1-XXXX and later. .\" Forget about pre-C99 C standards (i.e., C89/C90) .\" .\" * Notes (optional) .\" .\" * See also > > (In practice it seems reasonable to include any header that is specified > to declare types or function prototypes that themselves require a > definition of size_t, but this is awkward to describe, and not explicit > in the standard.) > > [...] > > Cheers > ---Dave > Cheers, Alex