Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

[Joseph Myers]

On Tue, 15 Jul 2025, Alejandro Colomar wrote:

> Rationale
> 	Since 'exp' is a library function, it is a reserved identifier,
> 	which should not be used as a variable / parameter name.

It's only reserved with external linkage and file scope, and as a macro 
name.  (It might still be less confusing to avoid usage in these other 
contexts.)

> 	7.1.3p1 says
> 
> 		All potentially reserved identifiers (...) that are
> 		provided by an implementation with an external
> 		definition are reserved for any use.

It's not "potentially reserved", but indeed "any use" seems too broad in 
that wording compared to the wording for actually reserved identifiers, 
which is more specific depending on the precise nature of how the 
identifier is defined.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

[Vincent Lefevre]

On 2025-07-24 18:33:47 +0000, Joseph Myers wrote:
> On Tue, 15 Jul 2025, Alejandro Colomar wrote:
> 
> > Rationale
> > 	Since 'exp' is a library function, it is a reserved identifier,
> > 	which should not be used as a variable / parameter name.
> 
> It's only reserved with external linkage and file scope, and as a macro 
> name.  (It might still be less confusing to avoid usage in these other 
> contexts.)

The important point is:

> > 	7.1.3p1 says
> > 
> > 		All potentially reserved identifiers (...) that are
> > 		provided by an implementation with an external
> > 		definition are reserved for any use.
> 
> It's not "potentially reserved", but indeed "any use" seems too broad in 
> that wording compared to the wording for actually reserved identifiers, 
> which is more specific depending on the precise nature of how the 
> identifier is defined.

It is not too broad. A compiler may define the identifier as
a builtin. For instance... GCC! The following program fails
to compile (note that I do not even include <math.h>):

static int exp (void)
{
  return 1;
}

int foo (void)
{
  return exp ();
}

tst.c:1:12: warning: conflicting types for built-in function ‘exp’; expected ‘double(double)’ [-Wbuiltin-declaration-mismatch]
    1 | static int exp (void)
      |            ^~~
tst.c:1:1: note: ‘exp’ is declared in header ‘<math.h>’
  +++ |+#include <math.h>
    1 | static int exp (void)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

[Just forwarding to the committee list]

On Thu, Jul 24, 2025 at 09:10:11PM +0200, Vincent Lefevre wrote:
> On 2025-07-24 18:33:47 +0000, Joseph Myers wrote:
> > On Tue, 15 Jul 2025, Alejandro Colomar wrote:
> > 
> > > Rationale
> > > 	Since 'exp' is a library function, it is a reserved identifier,
> > > 	which should not be used as a variable / parameter name.
> > 
> > It's only reserved with external linkage and file scope, and as a macro 
> > name.  (It might still be less confusing to avoid usage in these other 
> > contexts.)
> 
> The important point is:
> 
> > > 	7.1.3p1 says
> > > 
> > > 		All potentially reserved identifiers (...) that are
> > > 		provided by an implementation with an external
> > > 		definition are reserved for any use.
> > 
> > It's not "potentially reserved", but indeed "any use" seems too broad in 
> > that wording compared to the wording for actually reserved identifiers, 
> > which is more specific depending on the precise nature of how the 
> > identifier is defined.
> 
> It is not too broad. A compiler may define the identifier as
> a builtin. For instance... GCC! The following program fails
> to compile (note that I do not even include <math.h>):
> 
> static int exp (void)
> {
>   return 1;
> }
> 
> int foo (void)
> {
>   return exp ();
> }
> 
> tst.c:1:12: warning: conflicting types for built-in function ‘exp’; expected ‘double(double)’ [-Wbuiltin-declaration-mismatch]
>     1 | static int exp (void)
>       |            ^~~
> tst.c:1:1: note: ‘exp’ is declared in header ‘<math.h>’
>   +++ |+#include <math.h>
>     1 | static int exp (void)
> 
> -- 
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [SC22WG14.32615] alx-0051r0 - don't misuse reserved identifier 'exp'

[Joseph Myers]

On Thu, 24 Jul 2025, Alejandro Colomar wrote:

> > It is not too broad. A compiler may define the identifier as
> > a builtin. For instance... GCC! The following program fails
> > to compile (note that I do not even include <math.h>):
> > 
> > static int exp (void)
> > {
> >   return 1;
> > }

That's file scope, which is a context in which exp is reserved.  The 
proposed change was about function prototype scope, in which it's not 
reserved.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: [SC22WG14.32615] alx-0051r0 - don't misuse reserved identifier 'exp'

[Vincent Lefevre]

On 2025-07-24 21:59:48 +0000, Joseph Myers wrote:
> On Thu, 24 Jul 2025, Alejandro Colomar wrote:
> 
> > > It is not too broad. A compiler may define the identifier as
> > > a builtin. For instance... GCC! The following program fails
> > > to compile (note that I do not even include <math.h>):
> > > 
> > > static int exp (void)
> > > {
> > >   return 1;
> > > }
> 
> That's file scope, which is a context in which exp is reserved.  The 
> proposed change was about function prototype scope, in which it's not 
> reserved.

I don't see what you mean. But in any case the user's code will
be in files.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Re: [SC22WG14.32615] alx-0051r0 - don't misuse reserved identifier 'exp'

[Alejandro Colomar]

Hi Vincent,

On Fri, Jul 25, 2025 at 02:40:18AM +0200, Vincent Lefevre wrote:
> On 2025-07-24 21:59:48 +0000, Joseph Myers wrote:
> > On Thu, 24 Jul 2025, Alejandro Colomar wrote:
> > 
> > > > It is not too broad. A compiler may define the identifier as
> > > > a builtin. For instance... GCC! The following program fails
> > > > to compile (note that I do not even include <math.h>):
> > > > 
> > > > static int exp (void)
> > > > {
> > > >   return 1;
> > > > }
> > 
> > That's file scope, which is a context in which exp is reserved.  The 
> > proposed change was about function prototype scope, in which it's not 
> > reserved.
> 
> I don't see what you mean. But in any case the user's code will
> be in files.

'File scope' is specified in n3220 in 6.2.1p4:

	Every other identifier has scope determined by the placement of
	its declaration (in a declarator or type specifier).  If the
	declarator or type specifier that declares the identifier
	appears outside of any block or list of parameters, the
	identifier has file scope, which terminates at the end of the
	translation unit.  [...]

So file scope is mainly (non-nested) functions and global variables.

Joseph meant that 'exp' is reserved at file scope, so you can't create
a function named 'exp'.  However, 'exp' is used in the standard as a
name of function parameters, which is 'function prototype scope',
specified later in the same 6.2.1p4:

	[...]  If the declarator or type specifier that declares the
	identifier appears within the list of parameter declarations in
	a function prototype (not part of a function definition), the
	identifier has function prototype scope, which terminates at the
	end of the function declarator.

And 'exp' is not reserved for any use (it's not a potentially reserved
identifier.  It's a reserved identifier, which are only reserved for
certain purposes.  A 'potentially reserved' identifier is specified in
6.4.2.1p10:

	Some identifiers may be potentially reserved.  A potentially
	reserved identifier is an identifier which is not reserved
	unless made so by an implementation providing the identifier
	(7.1.3) but is anticipated to become reserved by an
	implementation or a future version of this document.  [...]

As we quoted, potentially reserved identifiers are reserved for any use,
and that would forbid use in function prototype scope.  However, 'exp'
is not a potentially reserved identifier.  It is a reserved identifier.
It is reserved by the text in 7.1.3p1, bullets 3 and 4 (I think):

	-- All identifiers with external linkage in any of the following
	subclauses (including the future library directions) and errno
	are always reserved for use as identifiers with external
	linkage.

	-- Each identifier with file scope listed in any of the
	following subclauses (including the future library directions)
	is reserved for use as a macro name and as an identifier with
	file scope in the same name space if any of its associated
	headers is included.

So, 'exp' is reserved for use in file scope and as an external
identifier, but not for other uses.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Hi Joseph, Jens,

On Thu, Jul 24, 2025 at 06:33:47PM +0000, Joseph Myers wrote:
> On Tue, 15 Jul 2025, Alejandro Colomar wrote:
> 
> > Rationale
> > 	Since 'exp' is a library function, it is a reserved identifier,
> > 	which should not be used as a variable / parameter name.
> 
> It's only reserved with external linkage and file scope, and as a macro 
> name.  (It might still be less confusing to avoid usage in these other 
> contexts.)

Can we please still apply it editorially, even if just for avoiding
confusion?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [SC22WG14.32341] alx-0051r0 - don't misuse reserved identifier 'exp'

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Tue, Sep 02, 2025 at 04:03:15PM +0200, Alejandro Colomar wrote:
> Hi Joseph, Jens,

Oops, s/Jens/JeanHeyd/

> 
> On Thu, Jul 24, 2025 at 06:33:47PM +0000, Joseph Myers wrote:
> > On Tue, 15 Jul 2025, Alejandro Colomar wrote:
> > 
> > > Rationale
> > > 	Since 'exp' is a library function, it is a reserved identifier,
> > > 	which should not be used as a variable / parameter name.
> > 
> > It's only reserved with external linkage and file scope, and as a macro 
> > name.  (It might still be less confusing to avoid usage in these other 
> > contexts.)
> 
> Can we please still apply it editorially, even if just for avoiding
> confusion?
> 
> 
> Have a lovely day!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>
> Use port 80 (that is, <...:80/>).



-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 5076 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes

[Mark Harris]

"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)).


 - Mark


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>

Re: Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 7043 bytes --]

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.

>  - 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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes

[Alejandro Colomar]

[-- 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 --]

Re: Feedback for n3704 - Clean up frexp, ldexp, and scalbn prototypes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 8175 bytes --]

On Sat, Jan 17, 2026 at 11:44:20PM +0100, Alejandro Colomar wrote:
> 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.

Actually, I see now that 'p' could stand for power.  Not too bad, then.

> 
> > 
> > >  - 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>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]