From: Alejandro Colomar <une+c@alejandro-colomar.es>
To: Mark Harris <mark.hsj@gmail.com>
Cc: C Committee <sc22wg14@open-std.org>,
Vincent Lefevre <vincent@vinc17.net>,
linux-man@vger.kernel.org, alx@kernel.org
Subject: Re: Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes
Date: Sat, 17 Jan 2026 23:43:54 +0100 [thread overview]
Message-ID: <aWwQkGdkzseNNBiv@devuan> (raw)
In-Reply-To: <aWwO1siDJcQ7aUI-@devuan>
[-- Attachment #1: Type: text/plain, Size: 7597 bytes --]
On Sat, Jan 17, 2026 at 11:37:08PM +0100, Alejandro Colomar wrote:
> Hi Mark,
>
> On Sat, Jan 17, 2026 at 02:23:39PM -0800, Mark Harris wrote:
> > "e" seems like a particularly poor choice, given that it is used in
> > documentation with the well-established meaning of the base of the
> > natural logarithm (e.g., in exp(3)).
>
> I don't expect anyone to confuse a variable 'e' with the base of the
> natural logarithm (M_E from <math.h>), since the base of the natural
> logarithm is not something variable, and thus it wouldn't make sense to
> pass it as a function argument.
>
> Maybe a second of wondering, and reading the documentation carefully,
> but nothing important. Once the base of the natural logarithm is
> discarded the meaning is then clear. On the other hand, I would
> consistently wonder what 'p' is, as it has no mnemonics.
One may argue that 'ex' might be even better than any of exp/e/p.
>
> > - Mark
>
>
> Have a lovely night!
> Alex
>
> > Alejandro Colomar wrote:
> > >
> > > Hi!
> > >
> > >
> > > I see n3704 attempts to fix the issues reported by Vincent; that's good.
> > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3704.pdf>
> > >
> > > However, the paper renames the pointer to 'p', which doesn't seem to
> > > have good mnemonics nor relate to what it is. 'p' seems to just be
> > > for 'pointer'? We can and should do better.
> > >
> > > I think alx-0051 was better, in using a parameter name that relates to
> > > what the parameter means: 'e' for exponent. Names matter.
> > >
> > > I think we should discuss the name in the meeting. Also, I think n3704
> > > should have included a rationaly for the name; especially, when a better
> > > name has been proposed, and for some reason the proposal decided to use
> > > a different one; that should certainly have been discussed.
> > >
> > > I think we can discuss the name in meeting without having to officially
> > > present alx-0051 with an N-document number. Please let me know if I
> > > should formally present alx-0051 for the next meeting.
> > >
> > >
> > > Have a lovely night!
> > > Alex
> > >
> > > On Tue, Jul 15, 2025 at 12:24:29AM +0200, Alejandro Colomar wrote:
> > > > Hi!
> > > >
> > > > Vincent reported this issue to me in the Linux man-pages mailing list
> > > > (as the manual pages also had the same issue, so he reported the issue
> > > > in both the manual pages and the ISO C standard). I think this can be
> > > > fixed editorially without going through an official N-document. Please
> > > > find the proposal below.
> > > >
> > > >
> > > > Have a lovely night!
> > > > Alex
> > > >
> > > > ---
> > > > Name
> > > > alx-0051r0 - don't misuse reserved identifier 'exp'
> > > >
> > > > Category
> > > > Editorial.
> > > >
> > > > Author
> > > > Reported-by: Vincent Lefevre <vincent@vinc17.net>
> > > > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > > >
> > > > History
> > > > <https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0051.git/>
> > > >
> > > > r0 (2025-07-15):
> > > > - Initial draft.
> > > >
> > > > Rationale
> > > > Since 'exp' is a library function, it is a reserved identifier,
> > > > which should not be used as a variable / parameter name.
> > > >
> > > > 7.1.3p1 says
> > > >
> > > > All potentially reserved identifiers (...) that are
> > > > provided by an implementation with an external
> > > > definition are reserved for any use.
> > > >
> > > > Proposed wording
> > > > Based on N3550.
> > > >
> > > > 7.17.7.5 The atomic_compare_exchange generic functions
> > > > @@ Description, p7 EXAMPLE
> > > > - exp = atomic_load(&cur);
> > > > + e = atomic_load(&cur);
> > > > do {
> > > > - des = function(exp);
> > > > + des = function(e);
> > > > - } while (!atomic_compare_exchange_weak(&cur, &exp, des));
> > > > + } while (!atomic_compare_exchange_weak(&cur, &e, des));
> > > >
> > > > B.11 Mathematics <math.h>
> > > > @@
> > > > ...
> > > > -_FloatN frexpfN(_FloatN value, int *exp);
> > > > -_FloatNx frexpfNx(_FloatNx value, int *exp);
> > > > -_DecimalN frexpdN(_DecimalN value, int *exp);
> > > > -_DecimalNx frexpdNx(_DecimalNx value, int *exp);
> > > > +_FloatN frexpfN(_FloatN value, int *e);
> > > > +_FloatNx frexpfNx(_FloatNx value, int *e);
> > > > +_DecimalN frexpdN(_DecimalN value, int *e);
> > > > +_DecimalNx frexpdNx(_DecimalNx value, int *e);
> > > > ...
> > > >
> > > > @@
> > > > ...
> > > > -_FloatN ldexpfN(_FloatN value, int *exp);
> > > > -_FloatNx ldexpfNx(_FloatNx value, int *exp);
> > > > -_DecimalN ldexpdN(_DecimalN value, int *exp);
> > > > -_DecimalNx ldexpdNx(_DecimalNx value, int *exp);
> > > > +_FloatN ldexpfN(_FloatN value, int *e);
> > > > +_FloatNx ldexpfNx(_FloatNx value, int *e);
> > > > +_DecimalN ldexpdN(_DecimalN value, int *e);
> > > > +_DecimalNx ldexpdNx(_DecimalNx value, int *e);
> > > > ...
> > > >
> > > > @@
> > > > ...
> > > > -_FloatN scalbnfN(_FloatN value, int *exp);
> > > > -_FloatNx scalbnfNx(_FloatNx value, int *exp);
> > > > -_DecimalN scalbndN(_DecimalN value, int *exp);
> > > > -_DecimalNx scalbndNx(_DecimalNx value, int *exp);
> > > > +_FloatN scalbnfN(_FloatN value, int *e);
> > > > +_FloatNx scalbnfNx(_FloatNx value, int *e);
> > > > +_DecimalN scalbndN(_DecimalN value, int *e);
> > > > +_DecimalNx scalbndNx(_DecimalNx value, int *e);
> > > > -_FloatN scalblnfN(_FloatN value, int *exp);
> > > > -_FloatNx scalblnfNx(_FloatNx value, int *exp);
> > > > -_DecimalN scalblndN(_DecimalN value, int *exp);
> > > > -_DecimalNx scalblndNx(_DecimalNx value, int *exp);
> > > > +_FloatN scalblnfN(_FloatN value, int *e);
> > > > +_FloatNx scalblnfNx(_FloatNx value, int *e);
> > > > +_DecimalN scalblndN(_DecimalN value, int *e);
> > > > +_DecimalNx scalblndNx(_DecimalNx value, int *e);
> > > > ...
> > > >
> > > > F.10.4.9 The ldexp functions
> > > > @@ p1
> > > > On a binary system,
> > > > -ldexp(x, exp)
> > > > +ldexp(x, e)
> > > > is equivalent to
> > > > -scalbn(x, exp).
> > > > +scalbn(x, e).
> > > >
> > > > ## And remove bold from 'exp' in the paragraph above. This is
> > > > ## probably present due to exp being considered as a reserved
> > > > ## identifier by some script, which is part of the consequences
> > > > ## of undefined behavior: UB might format your standard! :)
> > > >
> > > > H.11.3 Functions
> > > > @@ 7.12.7 Exponential and logarithmic functions
> > > > ## Apply same changes as in B.11 (see above).
> > > >
> > > > @@ F.10.14 Payload functions, p2
> > > > ...
> > > > the exponent is an integral power of 2 and,
> > > > when applicable,
> > > > -value equals x × 2*exp.
> > > > +value equals x × 2*e.
> > > >
> > > > --
> > > > <https://www.alejandro-colomar.es/>
> > >
> > >
> > >
> > > --
> > > <https://www.alejandro-colomar.es>
>
> --
> <https://www.alejandro-colomar.es>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-01-17 22:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250714222434.4D926356820@www.open-std.org>
2025-07-24 18:33 ` [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp' Joseph Myers
2025-07-24 19:10 ` Vincent Lefevre
2025-07-24 20:19 ` Alejandro Colomar
[not found] ` <20250724201957.0D806356A06@www.open-std.org>
2025-07-24 21:59 ` [SC22WG14.32615] " Joseph Myers
2025-07-25 0:40 ` Vincent Lefevre
2025-07-25 5:32 ` Alejandro Colomar
2025-09-02 14:03 ` [SC22WG14.32341] " Alejandro Colomar
2025-09-02 14:03 ` Alejandro Colomar
2026-01-17 20:57 ` Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes Alejandro Colomar
2026-01-17 22:23 ` Mark Harris
2026-01-17 22:36 ` Alejandro Colomar
2026-01-17 22:43 ` Alejandro Colomar [this message]
2026-01-17 22:44 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWwQkGdkzseNNBiv@devuan \
--to=une+c@alejandro-colomar.es \
--cc=alx@kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mark.hsj@gmail.com \
--cc=sc22wg14@open-std.org \
--cc=vincent@vinc17.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.