[9fans] NaN, +Inf, and -Inf, constants?

[9fans] NaN, +Inf, and -Inf, constants?

[Tristan Plumb]

I'm porting PROJ4.3.3 (the cleanest version of proj I could find), and
it's a little ugly.

One thing leading to another, I am currently centralizing constants, and
found that enums can hold doubles (which is quite nice), but I have no
way of defining NaN or Inf as a constant, is there such a way?

Or is there a way to evaluate constant functions at compile time (eep)?

Or I could just use #define (much safer than the above).

enjoy,
tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] NaN, +Inf, and -Inf, constants?

[erik quanstrom]

> One thing leading to another, I am currently centralizing constants, and
> found that enums can hold doubles (which is quite nice), but I have no
> way of defining NaN or Inf as a constant, is there such a way?
>
> Or is there a way to evaluate constant functions at compile time (eep)?

NaN(2) and Inf(2) are not constant functions.  the result depends on the
settings of the fcr (getfcr(2)).

- erik

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Tristan Plumb]

> NaN(2) and Inf(2) are not constant functions.  the result depends on
> the settings of the fcr (getfcr(2)).
Really? My reading of /sys/src/libc/port/nan.c makes me think NaN(2)
returns a uvlong value of 0x7ff0000000000001, miss I something?

On the other hand, the assignment of NaN to a double depends on the fcr.
(And on my machine, curiously changes 0x7ff0...1 to 0x7ff8...1).

So if I think of enum definitions as assignment, it makes sense, mostly.

thanks,
tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Russ Cox]

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

On Sat, Feb 6, 2010 at 7:38 AM, Tristan Plumb <9p-st@imu.li> wrote:

> enums can hold doubles (which is quite nice)
>

Umm, no they can't.

Russ

[-- Attachment #2: Type: text/html, Size: 429 bytes --]

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Charles Forsyth]

h% cat en.c
enum{
	Fred= 1.5
};
double f = Fred;
h% 8c -S en.c
	DATA	f+0(SB)/8,$(1.50000000000000000e+00)
	GLOBL	f+0(SB),$8
	END	,

bug or quirk?
what do you think?

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Charles Forsyth]

i didn't even think to check earlier. even better:

enum{
	Fred= 1.5,
	Sam,
};
double f = Fred;
double g = Sam;

h% 8c -S en.c
	DATA	f+0(SB)/8,$(1.50000000000000000e+00)
	DATA	g+0(SB)/8,$(2.50000000000000000e+00)
	GLOBL	f+0(SB),$8
	GLOBL	g+0(SB),$8
	END	,

sound!

Re: [9fans] NaN, +Inf, and -Inf, constants?

[erik quanstrom]

> On the other hand, the assignment of NaN to a double depends on the fcr.
> (And on my machine, curiously changes 0x7ff0...1 to 0x7ff8...1).

http://en.wikipedia.org/wiki/NaN explains the difference between
a signaling nan and a quiet nan (the latter).

> So if I think of enum definitions as assignment, it makes sense, mostly.

how does a non-constant enum make sense?

more to the point, in porting code, you're going to have to work
out how to deal with NaNs.  plan 9 defaults to using signaling
nans, unless you manually change the fcr.  this is good because
it avoids bad conversions.  on the other hand, your application
may require and depend on the ability to pass around nan and
±inf.

- erik

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Russ Cox]

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

On Sun, Feb 7, 2010 at 2:46 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> h% cat en.c
> enum{
>        Fred= 1.5
> };
> double f = Fred;
> h% 8c -S en.c
>        DATA    f+0(SB)/8,$(1.50000000000000000e+00)
>        GLOBL   f+0(SB),$8
>        END     ,
>
> bug or quirk?
> what do you think?
>

i swear i tested this before i replied...

seems like a bug to me.  the spec is pretty clear:

       6.7.2.2  Enumeration specifiers

       Syntax

       [#1]

               enum-specifier:
                       enum identifier-opt { enumerator-list }
                       enum identifier-opt { enumerator-list , }
                       enum identifier

               enumerator-list:
                       enumerator
                       enumerator-list , enumerator

               enumerator:
                       enumeration-constant
                       enumeration-constant = constant-expression

       Constraints

       [#2] The expression that defines the value of an enumeration
       constant shall be an integer constant expression that has  a
       value representable as an int.

russ

[-- Attachment #2: Type: text/html, Size: 1909 bytes --]

Re: [9fans] NaN, +Inf, and -Inf, constants?

[erik quanstrom]

>        [#2] The expression that defines the value of an enumeration
>        constant shall be an integer constant expression that has  a
>        value representable as an int.

the spec also doesn't allow vlong enumerations.
should we remove that ability, too?

- erik

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Charles Forsyth]

>seems like a bug to me.  the spec is pretty clear:

it's quite deliberate, having looked at the code.
i suspect the rationale was that, finally, C provided a way
outside the preprocessor to give symbolic names to constants.
why restrict that to int?
you can't easily get the same effect by adding #define names
to the output symbol table, because those are arbitrary text,
not guaranteed either to be constants, or to be safe for substitution
(without surrounding ())

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> i suspect the rationale was that, finally, C provided a way
> outside the preprocessor to give symbolic names to constants.
> why restrict that to int?

Because enum's have been int's since their inception?

I'm sympathetic to the underlying need, but making a fundamental
type of the language suddenly become variable does not seem to
be the right way of going about this.

E.g., what is the type of:

enum {
	a = 1,
	b = 2.44000000000000000000618549L,
	c = 2.44F,
	d = "this is weird",
	e = 1LL<<62,
} foo;

How on earth do you switch() on it? And what's its sizeof()?

--lyndon

Re: [9fans] NaN, +Inf, and -Inf, constants?

[erik quanstrom]

> enum {
> 	a = 1,
> 	b = 2.44000000000000000000618549L,
> 	c = 2.44F,
> 	d = "this is weird",
> 	e = 1LL<<62,
> } foo;
>
> How on earth do you switch() on it? And what's its sizeof()?

why does being able to switch on any enum trump
the ability to define constants without #define?

if you try, sizeof(foo)==4, but you'll need to remove
'd' since you can't have a string.  you can't switch on
a vlong or float.  would be nice, though.

the plan 9 style is never to typedef or name enums.
(though i saw one creep into the source recently.)
so the sizeof problem would naturally never come up.
if it were an error to name or typedef an enum
containing non-int members, there would be no
problem.

- erik

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Bakul Shah]

On Sun, 07 Feb 2010 15:19:58 MST "Lyndon Nerenberg (VE6BBM/VE7TFX)" <lyndon@orthanc.ca>  wrote:
> > i suspect the rationale was that, finally, C provided a way
> > outside the preprocessor to give symbolic names to constants.
> > why restrict that to int?
>
> Because enum's have been int's since their inception?
>
> I'm sympathetic to the underlying need, but making a fundamental
> type of the language suddenly become variable does not seem to
> be the right way of going about this.
>
> E.g., what is the type of:
>
> enum {
> 	a = 1,
> 	b = 2.44000000000000000000618549L,
> 	c = 2.44F,
> 	d = "this is weird",
> 	e = 1LL<<62,
> } foo;

The cleanest solution would be to treat C's _static const_
"variables" as as compile time constants. I wish the standard
dictated this.

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> why does being able to switch on any enum trump
> the ability to define constants without #define?

Because enum's legacy is that of a 'first class' int-like
object, which can be subject to the usual set of int-like
operations. switch() is one of those. #define isn't.

> if you try, sizeof(foo)==4, but you'll need to remove
> 'd' since you can't have a string.  you can't switch on
> a vlong or float.  would be nice, though.

Why not a string? If you can extend an enum to include floats,
why not an integer representation of a pointer?

And yes, I also think switching on vlongs would be useful.

> the plan 9 style is never to typedef or name enums.

It may not be the style for the Labs, but that's not the case for
everyone.  The compile time type checking named enums provide isn't
something I'd want to lose.

> if it were an error to name or typedef an enum
> containing non-int members, there would be no
> problem.

This could work. But I have to agree with Bakul: 'static const'
is a much better fit for the language.

--lyndon

Re: [9fans] NaN, +Inf, and -Inf, constants?

[Russ Cox]

we could spend a lot of time debating proposed
changes, but i think it's fine to leave as is.
there appears to be a good, justifiable reason
for it, and it's already implemented.

russ