Message ID | 20200925073140.173394-5-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 85CD43983035; Fri, 25 Sep 2020 07:33:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85CD43983035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601019183; bh=CqQEr9T9uuGEo0PcdlXtzfk+/8ip6WKHDoNoQ0qMOUA=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=e1GDkgxSOf2gRS29dxxg1rL8XAesXuwCe4ofe/9z9Iecwd1cxBzngLPcHkvrRxRtY UeXUWsCHbWa0BOzHa2Tif9ldQbQKpABw7FGNDj+FxpCczSKamWT2vfiEhZ+XOTiwgu lzbcBmvcRf3l1F0FrGqexJQUNhmij0sr7osntq4w= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id B79823840C27 for <libc-alpha@sourceware.org>; Fri, 25 Sep 2020 07:33:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B79823840C27 Received: by mail-wr1-x442.google.com with SMTP id t10so2461581wrv.1 for <libc-alpha@sourceware.org>; Fri, 25 Sep 2020 00:33: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:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CqQEr9T9uuGEo0PcdlXtzfk+/8ip6WKHDoNoQ0qMOUA=; b=L3dPSLelU4F6W8Owa/J96NxpEkRkFt/ozm/z6GCaUp2AjxXpd0rKZO+iHOy+UDlTrW 8+xfVhO2WpMUyoyMOh5zsS1ftT39nLxnI9mN/Q0T5wOok3RGu5u1pKCEa/+3vGdeLW40 QtOrfKOvmiNqi6/3PPVkRi1xVSJQHyZgG4pvsm8pvQKqc2fFglGryvEJztV8aiIVQVJ+ aYXkDtJGHuYC0/+5yxU0Yl8ICY2idxRKgv/+kSmjF+/vF6E7Pm77tDvDlvxmKJ7wWbCf /eKEM1EHnBYwmfAaJkc0q/uZPTWcQDgJmJSWNsNnptDj/jujG+mMKqQ6ZALn28HHyKVj z1aw== X-Gm-Message-State: AOAM532BGeBcCtTAzywbswhES7vNX1dpOtosz/5+75IYZTzQBsJS2lHr vNDqV7c1kJLeDBOV3JJFvAQ= X-Google-Smtp-Source: ABdhPJwLIRDKSZhXDCTVrKn5tw9FxQKS//qix++yP2nRMysrigzE8KGp4AsNvjYwaFnv7woZLvcWdQ== X-Received: by 2002:adf:d4c7:: with SMTP id w7mr2962133wrk.263.1601019179854; Fri, 25 Sep 2020 00:32:59 -0700 (PDT) Received: from localhost.localdomain ([170.253.60.68]) by smtp.googlemail.com with ESMTPSA id n2sm1974314wma.29.2020.09.25.00.32.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2020 00:32:59 -0700 (PDT) To: mtk.manpages@gmail.com Subject: [PATCH 04/10] system_data_types.7: Add float_t Date: Fri, 25 Sep 2020 09:31:35 +0200 Message-Id: <20200925073140.173394-5-colomar.6.4.3@gmail.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200925073140.173394-1-colomar.6.4.3@gmail.com> References: <20200925073140.173394-1-colomar.6.4.3@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.4 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 Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Add types, and some fixes
|
|
Commit Message
Alejandro Colomar
Sept. 25, 2020, 7:31 a.m. UTC
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
---
man7/system_data_types.7 | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
Comments
Hi Alex, A few comments here that also apply for the double_t patch. Could you revise please? On 9/25/20 9:31 AM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com> > --- > man7/system_data_types.7 | 36 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 > index b04457bbf..238b9593b 100644 > --- a/man7/system_data_types.7 > +++ b/man7/system_data_types.7 > @@ -147,6 +147,42 @@ Conforming to: C99 and later; POSIX.1-2001 and later. > .IP > See also: > .BR fenv (3) > +.\"------------------------------------- float_t ----------------------/ > +.TP > +.I float_t > +.IP > +Include: > +.IR <math.h> . > +.IP > +The implementation's most efficient floating type at least as wide as > +.IR float . The C standard is rather terse here. Perhaps we could make the reader's life a little easier. How about something like: [[ This a type that is intended to be the implementation's most efficient floating type that is at least as wide as .IR float . ]] > +Its type depends on the value of the macro > +.BR FLT_EVAL_METHOD : > +.RS > +.IP * > +0; > +.I float_t > +is > +.IR float . > +.IP * > +1; > +.I float_t > +is > +.IR double . > +.IP * > +2; > +.I float_t > +is > +.IR "long double" . > +.IP * > +Other implementation-defined values. > +.RE I think we can format this better as a hanging list. Something like this: [[ .TP 0 .I float_t is .IR float . .TP 1 .I float_t is .IR double . .TP 2 .I float_t is .IR "long double" . .IP For other values of .BR FLT_EVAL_METHOD , the type of .I float_t is implementation-defined. ]] > +.IP > +Conforming to: C99 and later; POSIX.1-2001 and later. > +.IP > +See also the > +.I double_t > +type in this page. > .\"------------------------------------- gid_t ------------------------/ > .TP > .I gid_t Thanks, Michael
Hi Michael, On 2020-09-25 10:13, Michael Kerrisk (man-pages) wrote: > Hi Alex, > > A few comments here that also apply for the double_t patch. > Could you revise please? > > On 9/25/20 9:31 AM, Alejandro Colomar wrote: >> +The implementation's most efficient floating type at least as wide as >> +.IR float . > > The C standard is rather terse here. Perhaps we could make the > reader's life a little easier. How about something like: > > [[ > This a type that is intended to be the implementation's > most efficient floating type that is at least as wide as > .IR float . > ]] I removed the "intended" part to simplify it a bit. Do you prefer to keep it? > >> +Its type depends on the value of the macro >> +.BR FLT_EVAL_METHOD : >> +.RS >> +.IP * >> +0; >> +.I float_t >> +is >> +.IR float . >> +.IP * >> +1; >> +.I float_t >> +is >> +.IR double . >> +.IP * >> +2; >> +.I float_t >> +is >> +.IR "long double" . >> +.IP * >> +Other implementation-defined values. >> +.RE > > I think we can format this better as a hanging list. > Something like this: > > [[ > .TP > 0 > .I float_t > is > .IR float . > .TP > 1 > .I float_t > is > .IR double . > .TP > 2 > .I float_t > is > .IR "long double" . > .IP > For other values of > .BR FLT_EVAL_METHOD , > the type of > .I float_t > is implementation-defined. > ] Yes, I wasn't convinced by my formatting. Thanks! I'll fix this patch, and the srcfix that depends on this too. BTW, I'll also add a note that FLT_EVAL_METHOD is defined in <float.h> Would you add that to "Notes", or as part of the description? > >> +.IP >> +Conforming to: C99 and later; POSIX.1-2001 and later. >> +.IP >> +See also the >> +.I double_t >> +type in this page. >> .\"------------------------------------- gid_t ------------------------/ >> .TP >> .I gid_t > > Thanks, > > Michael > > Thanks, Alex
Hi Alex, On 9/25/20 10:22 AM, Alejandro Colomar wrote: > Hi Michael, > > On 2020-09-25 10:13, Michael Kerrisk (man-pages) wrote: >> Hi Alex, >> >> A few comments here that also apply for the double_t patch. >> Could you revise please? >> >> On 9/25/20 9:31 AM, Alejandro Colomar wrote: >>> +The implementation's most efficient floating type at least as wide as >>> +.IR float . >> >> The C standard is rather terse here. Perhaps we could make the >> reader's life a little easier. How about something like: >> >> [[ >> This a type that is intended to be the implementation's >> most efficient floating type that is at least as wide as >> .IR float . >> ]] > > I removed the "intended" part to simplify it a bit. Do you prefer to > keep it? Well, as long as you are going to lift the detail about "most efficient" from the C standard, I'd be inclined to keep the word "intended" from the standard as well. But I do not feel strongly about it. >>> +Its type depends on the value of the macro >>> +.BR FLT_EVAL_METHOD : >>> +.RS >>> +.IP * >>> +0; >>> +.I float_t >>> +is >>> +.IR float . >>> +.IP * >>> +1; >>> +.I float_t >>> +is >>> +.IR double . >>> +.IP * >>> +2; >>> +.I float_t >>> +is >>> +.IR "long double" . >>> +.IP * >>> +Other implementation-defined values. >>> +.RE >> >> I think we can format this better as a hanging list. >> Something like this: >> >> [[ >> .TP >> 0 >> .I float_t >> is >> .IR float . >> .TP >> 1 >> .I float_t >> is >> .IR double . >> .TP >> 2 >> .I float_t >> is >> .IR "long double" . >> .IP >> For other values of >> .BR FLT_EVAL_METHOD , >> the type of >> .I float_t >> is implementation-defined. >> ] > Yes, I wasn't convinced by my formatting. Thanks! > > I'll fix this patch, and the srcfix that depends on this too. Okay. > BTW, I'll also add a note that FLT_EVAL_METHOD is defined in <float.h> > Would you add that to "Notes", or as part of the description? As part of the description I think. (And I don't mind if it's repeated in the double_t description.) Cheers, Michael
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index b04457bbf..238b9593b 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -147,6 +147,42 @@ Conforming to: C99 and later; POSIX.1-2001 and later. .IP See also: .BR fenv (3) +.\"------------------------------------- float_t ----------------------/ +.TP +.I float_t +.IP +Include: +.IR <math.h> . +.IP +The implementation's most efficient floating type at least as wide as +.IR float . +Its type depends on the value of the macro +.BR FLT_EVAL_METHOD : +.RS +.IP * +0; +.I float_t +is +.IR float . +.IP * +1; +.I float_t +is +.IR double . +.IP * +2; +.I float_t +is +.IR "long double" . +.IP * +Other implementation-defined values. +.RE +.IP +Conforming to: C99 and later; POSIX.1-2001 and later. +.IP +See also the +.I double_t +type in this page. .\"------------------------------------- gid_t ------------------------/ .TP .I gid_t