- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Tim Kelly <gtkelly_at_dialectronics.com>

Date: Wed, 08 Mar 2023 08:16:53 -0500

Hello,

Perhaps someone on the list with more access to the C99 standard and/or

experience can enlighten me on how

double ddb = 0x400921FB54442D18;

should be interpreted during parsing. At first glance, one would be

inclined to say the above is an integer, but in reading the draft of

C99, I can not rule out that it should be interpreted as an IEE-754

representation of a real number. If it was shorter, I would concur that

it is an integer, but it is of the correct length for a double.

Although not common, it might be possible the programmer already knows

the floating point representation of the number in question. The above

example is pi to 15 digits past the decimal. I can not recall precisely

where, but in one of cases when porting software to Minix 3.1.6, I have

came across some manually encoded floating point values.

From the standard, I can glean that hexadecimal representation is

completely legal, before and after the decimal point, but only base 10

numbers can be in the exponent (to avoid conflicting with the suffix 'F'

to denote single precision).

Beyond that, I am unable to find a specific statement saying hexadecimal

numbers must contain a decimal point, which means the above number is

ambiguous. However, I do not find the draft to be particularly succinct

in its discussions, and aspects appear to be contained in several

different sections.

Base 10 numbers are not required to have a decimal point when being

declared:

double ten = 10;

is perfectly legal, obviously. Therefore, I can infer neither is it a

requirement that base 16 representation requires a decimal point.

An argument could be made to follow what clang and/or pcc do, but at

least with clang, the method seems to be do what gcc does. I would

rather be compliant with the standard, and if there is ambiguity about

implementation, do the opposite of what gcc does (it's not really a

choice if all the options do the same thing).

I can say that clang and pcc appear to require a 'P' if the base 16

number contains a decimal point and interprets the number as an integer

if it is not present, but I am unable to find the specific clause

requiring this. If the decimal place and P are not required and P is

omitted, I would make the assumption that the exponent is 0, i.e.

double dec = 0x3FF3C28.F5C28F5C3;

would be interpreted as

double dec = 0x3FF3C28.F5C28F5C3P0;

As a result, if the decimal place is not required, the original example

of pi in IEEE-754 is ambiguous.

Does anyone know what the standard is requiring regarding the specific

format above?

Thank you,

tim

Date: Wed, 08 Mar 2023 08:16:53 -0500

Hello,

Perhaps someone on the list with more access to the C99 standard and/or

experience can enlighten me on how

double ddb = 0x400921FB54442D18;

should be interpreted during parsing. At first glance, one would be

inclined to say the above is an integer, but in reading the draft of

C99, I can not rule out that it should be interpreted as an IEE-754

representation of a real number. If it was shorter, I would concur that

it is an integer, but it is of the correct length for a double.

Although not common, it might be possible the programmer already knows

the floating point representation of the number in question. The above

example is pi to 15 digits past the decimal. I can not recall precisely

where, but in one of cases when porting software to Minix 3.1.6, I have

came across some manually encoded floating point values.

From the standard, I can glean that hexadecimal representation is

completely legal, before and after the decimal point, but only base 10

numbers can be in the exponent (to avoid conflicting with the suffix 'F'

to denote single precision).

Beyond that, I am unable to find a specific statement saying hexadecimal

numbers must contain a decimal point, which means the above number is

ambiguous. However, I do not find the draft to be particularly succinct

in its discussions, and aspects appear to be contained in several

different sections.

Base 10 numbers are not required to have a decimal point when being

declared:

double ten = 10;

is perfectly legal, obviously. Therefore, I can infer neither is it a

requirement that base 16 representation requires a decimal point.

An argument could be made to follow what clang and/or pcc do, but at

least with clang, the method seems to be do what gcc does. I would

rather be compliant with the standard, and if there is ambiguity about

implementation, do the opposite of what gcc does (it's not really a

choice if all the options do the same thing).

I can say that clang and pcc appear to require a 'P' if the base 16

number contains a decimal point and interprets the number as an integer

if it is not present, but I am unable to find the specific clause

requiring this. If the decimal place and P are not required and P is

omitted, I would make the assumption that the exponent is 0, i.e.

double dec = 0x3FF3C28.F5C28F5C3;

would be interpreted as

double dec = 0x3FF3C28.F5C28F5C3P0;

As a result, if the decimal place is not required, the original example

of pi in IEEE-754 is ambiguous.

Does anyone know what the standard is requiring regarding the specific

format above?

Thank you,

tim

-- "We believe that when you create a machine to do the work of a man, you take something away from the man." -- Sojef -- To unsubscribe send a mail to scc-dev+unsubscribe_at_simple-cc.orgReceived on Wed 08 Mar 2023 - 14:16:53 CET

*
This archive was generated by hypermail 2.3.0
: Fri 21 Apr 2023 - 16:20:39 CEST
*