hex and octal constants in various languages

[Guest]

I am collecting a sort of phrase books with equivalent "things" in
various languages.

I am now considering the indication of constants as hex, oct or binary
constants. I have considered fortran, C, Java, IDL and (my)sql. I have a
question on the first three.

As a reference I started in Fortran with cases like these (I did also
byte, short and 64bit integers, not shown) :

integer j
j=somevalue
write(*,3)j,j,j,j
3 format(I11.10,1X,B32.32,1X,O11.11,1X,Z8.8)

real r
r=somevalue
write(*,4)r,r,r,r
4 format(G13.7 ,1X,B32.32,1X,O11.11,1X,Z8.8)

character*4 s
equivalence (j,s)
s=somestring
write(*,5)s,s,s,s
5 format(A4 ,1X,B32.32,1X,O11.11,1X,Z8.8)

I tried first with some explicit values (1, -1, 32767, 1.0, 2.0,
huge(0.0), tiny(0.0), "ABCD") and obtained perfectly meaningful binary,
oct and hex values. Then I replaced the assignment using bin, oct or hex
constants

j=z'7FFE' ! gives 32866
j=o'37777777776' ! give -2
j=b'11111111111111111111111111111110'
r=z'80800000' ! gives tiny
j=z'44434241' ! gives "ABCD"

Everything works perfectly. I can assign directly a binary
representation to an integer and to a real, and I can even assign it to
a string if this is in equivalence with an appropriate integer.

I then moved to C, I tried statements like

short i ;
i=somevalue;
printf("%6.5d %6.6o %4.4X %d \n",i,i,i,sizeof(i)) ;

int j ;
j=somevalue ;
printf("%11.10d %11.11o %8.8X %d \n",j,j,j,sizeof(j)) ;

float f ;
f=somevalue ;
printf("%13.7g %11.11o %8.8X %d \n",f,f,f,sizeof(f)) ;

Here I find two problems, a minor and a major one

The minor one is that a positive short is displayed OK
But a negative short is displayed with too many oct and hex digits
i=32767 ; /* 32767 077777 7FFF */
i=-1; /* -00001 37777777777 FFFFFFFF */

although a sizeof says that i is 2 bytes

The major problem is that an assignment to a float gives an
unexpected result (no compile or runtime error)

f=0X40800000; /* should return 4.0 */
f=0X80800000; /* should return tiny */

For instance the latter returns 2.155872e+09, the former 2.155872e+09
and BOTH THE SAME 00000000000 as octal and 41E01000 as hex (different
from the one I assigned)

In Java I tried

int i ;
System.out.format("i is: %11d %11o %8x %n", i,i,i);

float f ;
System.out.format("f is: %e %n", f );

Here format does not support the o and x descriptors for float argument.

Anyhow I tested assignments for integer and they do work

i=037777777776 ; /* -2 */
i=0X7FFE ; /* 32766 */

while assignment for real do not work (as in C)

f=0X3F800000; /* should be 1.0 */
f=0X40800000; /* should be 4.0 */
f=0X80800000; /* should by tiny */

(the compiler does not complain, there are no runtime exceptions, but
the result is not what expected

for instance the latter returns -2.139095e+09 and the one for 4.0
returns 1.082130e+09

I haven't tested assignment of hex or oct constants to strings in
neither of the two latter languages (I guess Java will be using unicode,
not plain ascii)

 

[Richard Maine]

Then I replaced the assignment using bin, oct or hex constants

j=z'7FFE' ! gives 32866
j=o'37777777776' ! give -2
j=b'11111111111111111111111111111110'
r=z'80800000' ! gives tiny
j=z'44434241' ! gives "ABCD"

Everything works perfectly.

None of these are standard Fortran. The fact that some particular
compiler might happen to accept them is another matter; they are not
Fortran. In fact, because these violate a constraint (C410 in F2003 or
an even more stringent one in f95), the compiler is required to be able
to diagnose their usage. Have you tried the compiler switch to warn
about nonstandard forms? If you did so and the compiler failed to give
you a message about these, then the compiler violates the standard.

I can assign directly a binary
representation to an integer and to a real,

The ones assigning directly to a real are particularly nonportable. Even
among compilers that accept the nonstandard syntax, you will find
differences in interpretation of this. Indeed, the most "natural"
extension of the standard would not give the result you expect.

and I can even assign it to
a string if this is in equivalence with an appropriate integer.

Such an equivalence is also nonstandard.

It appears that you are not actually comparing the Fortran language to
other languges, but instead comparing a particular Fortran compiler.
That's not the same thing.

 

[jameskuyper]

LC's No-Spam Newsreading account wrote:
....

short i ;
i=somevalue;
printf("%6.5d %6.6o %4.4X %d \n",i,i,i,sizeof(i)) ;

The '%o" and "%X" format specifiers require an unsigned int argument,
'i' doesn't qualify. The "%d" format specifier require an int. This is
OK for the first "%d", because 'i' is automatically promoted to an
'int'. It is not OK for the final %d, because sizeof expressions have
a value of type size_t, which is not only unsigned, but on many
platforms is larger than an int.

int j ;
j=somevalue ;
printf("%11.10d %11.11o %8.8X %d \n",j,j,j,sizeof(j)) ;

Exactly the same issues apply here.

float f ;
f=somevalue ;
printf("%13.7g %11.11o %8.8X %d \n",f,f,f,sizeof(f)) ;

The problems with the "%o" and "%X" format specifiers in this case are
technically exactly the same as in the previous two cases. However,
while there are many systems where they will work as you might expect
them to with a signed int value, there's very few, if any, systems
where they'll work with floating point values.

Here I find two problems, a minor and a major one

The minor one is that a positive short is displayed OK
But a negative short is displayed with too many oct and hex digits
i=32767 ; /* 32767 077777 7FFF */
i=-1; /* -00001 37777777777 FFFFFFFF */

although a sizeof says that i is 2 bytes

'i' is promoted to an int before being passed to printf(), and you
printed it using a format specifier for an unsigned int. Why do you
think that sizeof(short) has anything to do with the result that you
get?

The major problem is that an assignment to a float gives an
unexpected result (no compile or runtime error)

No, the major problem is that you expected any particular result. The
standard does not provide any support for any such expectations. If
printf() had decided to print out "You have no idea what you're
doing.", it would have been both fully conforming and fairly accurate.

f=0X40800000; /* should return 4.0 */

0x40800000 is a hex constant with a value of 1082130432. Assigning it
to a float object causes it to be converted to one of the two values
representable as a float that are closest to 1082130432.0, which will
usually be1082130432.0 itself, except in the unlikely (but legal) case
where FLT_RADIX is something other than a small power of 2 . Why would
expect the result to be 4.0?

f=0X80800000; /* should return tiny */

I don't believe that a value of 2155872256.0 counts as tiny, though
astronomers might disagree.

For instance the latter returns 2.155872e+09, the former 2.155872e+09
and BOTH THE SAME 00000000000 as octal and 41E01000 as hex (different
from the one I assigned)

Well, when you ask printf() to print an unsigned integer, and you give
it a floating point value instead, you really can have no justified
grounds for complaint, regardless of what it prints.

 

[James Van Buskirk]

j=z'7FFE' ! gives 32866
j=o'37777777776' ! give -2
j=b'11111111111111111111111111111110'
r=z'80800000' ! gives tiny
j=z'44434241' ! gives "ABCD"

A problem here is that the above isn't legal Fortran, not even F08. The
key ambiguity lies in the assignment:

r = z'80800000'

which is supposed to yield -tiny(0.0). It is controversial what a
compiler should do here: should it interpret z'80800000' as a
Hollerith constant and assign as if via TRANSFER (with result -tiny(0.0))
or should it be treated as an integer constant, thus -2139095040?
F08 allows different conpilers to interpret this differently, even
when couched as a DATA statement by disallowing the assignment form
entirely and only permitting the DATA statement form when the
corresponding data-stmt-object is of type integer. The result is that
compilers can accept their traditional form as an extension and users
of a given compiler don't have to change their hoary code because the
compiler wasn't required to changed its behavior by the standard.

F08 does have a form where the programmer is required to specify
which interpretation he wants:

r = INT(z'80800000') ! r = -2139095040
r = REAL(z'80800000') ! r = -tiny(0.0)

I then moved to C, I tried statements like

short i ;
i=somevalue;
printf("%6.5d %6.6o %4.4X %d \n",i,i,i,sizeof(i)) ;

int j ;
j=somevalue ;
printf("%11.10d %11.11o %8.8X %d \n",j,j,j,sizeof(j)) ;

float f ;
f=somevalue ;
printf("%13.7g %11.11o %8.8X %d \n",f,f,f,sizeof(f)) ;

Here I find two problems, a minor and a major one

The minor one is that a positive short is displayed OK
But a negative short is displayed with too many oct and hex digits
i=32767 ; /* 32767 077777 7FFF */
i=-1; /* -00001 37777777777 FFFFFFFF */

although a sizeof says that i is 2 bytes

In the above, i was printed with the %o format. The mechanism for
passing i to printf means that there is no way for the printf
function to distinguish it from an int, so the calling program
has to convert to type int via sign extension (so that it could
print (short)(-1) as -1 with a %d format) and printf doesn't know
that it started life as a short so you get what you get. If you
don't like it, you can always change the format to "%6.6ho".

The major problem is that an assignment to a float gives an unexpected
result (no compile or runtime error)

f=0X40800000; /* should return 4.0 */
f=0X80800000; /* should return tiny */

For instance the latter returns 2.155872e+09, the former 2.155872e+09 and
BOTH THE SAME 00000000000 as octal and 41E01000 as hex (different from the
one I assigned)

C defines hex constants as being unsigned ints, maybe unsigned long ints,
I'm not clear on the fine points, but you should definitely get the big
numbers you are getting. I haven't thought about the octal and hex
outputs you report above. That's a different problem.

 

[markspace]

for instance the latter returns -2.139095e+09 and the one for 4.0
returns 1.082130e+09

Huh. Mine seems fine. What hardware do you run on and what Java
compiler do you use? SSCCE?

<code>
/** Java float test */
public class FloatTest {

public static void main(String[] args) {
float f = 1.0f;
int fi = Float.floatToRawIntBits(f);
f = Float.intBitsToFloat( 0x3f800000 );
System.out.printf("%x\n", fi );
System.out.printf("%g\n", f );
}
}

</code>

<output>

run:
3f800000
1.00000
BUILD SUCCESSFUL (total time: 0 seconds)

</output>

 

[glen herrmannsfeldt]

(snip)

< As a reference I started in Fortran with cases like these (I did also
< byte, short and 64bit integers, not shown) :

< integer j
< j=somevalue
< write(*,3)j,j,j,j
< 3 format(I11.10,1X,B32.32,1X,O11.11,1X,Z8.8)

I believe this is right, though I am not so srue about the
part after the decimal point.

< real r
< r=somevalue
< write(*,4)r,r,r,r
< 4 format(G13.7 ,1X,B32.32,1X,O11.11,1X,Z8.8)

This is non-standard, and likely won't work with some systems.
As default real and default integer are supposed to be the same
size, it should work with TRANSFER (and likely also with
EQUIVALENCE).

< character*4 s
< equivalence (j,s)
< s=somestring
< write(*,5)s,s,s,s
< 5 format(A4 ,1X,B32.32,1X,O11.11,1X,Z8.8)

Even less likely to work than REAL. Again TRANSFER is
a good solution. Though there is no guarantee that a default
integer is four characters long.

< I tried first with some explicit values (1, -1, 32767, 1.0, 2.0,
< huge(0.0), tiny(0.0), "ABCD") and obtained perfectly meaningful binary,
< oct and hex values. Then I replaced the assignment using bin, oct or hex
< constants

< j=z'7FFE' ! gives 32866
< j=o'37777777776' ! give -2
< j=b'11111111111111111111111111111110'
< r=z'80800000' ! gives tiny
< j=z'44434241' ! gives "ABCD"

< Everything works perfectly. I can assign directly a binary
< representation to an integer and to a real, and I can even assign it to
< a string if this is in equivalence with an appropriate integer.

That seems likely not to work on many systems. Fortran 2003 suggest
that the REAL function should work in the REAL case. I suppose
TRANSFER for the string case.

< I then moved to C, I tried statements like

< short i ;
< i=somevalue;
< printf("%6.5d %6.6o %4.4X %d \n",i,i,i,sizeof(i)) ;

< int j ;
< j=somevalue ;
< printf("%11.10d %11.11o %8.8X %d \n",j,j,j,sizeof(j)) ;

< float f ;
< f=somevalue ;
< printf("%13.7g %11.11o %8.8X %d \n",f,f,f,sizeof(f)) ;

< Here I find two problems, a minor and a major one

< The minor one is that a positive short is displayed OK
< But a negative short is displayed with too many oct and hex digits
< i=32767 ; /* 32767 077777 7FFF */
< i=-1; /* -00001 37777777777 FFFFFFFF */

You can't printf short values. They are converted to int before
they are passed to printf. Bitwise AND (&) with the appropriate
constant, such as 0xffff first.

< although a sizeof says that i is 2 bytes

< The major problem is that an assignment to a float gives an
< unexpected result (no compile or runtime error)

< f=0X40800000; /* should return 4.0 */
< f=0X80800000; /* should return tiny */

The hex constant is just an ordinary unsigned int and is converted
as usual. The usual way to do this, though non standard, is with
the use of pointers.

< For instance the latter returns 2.155872e+09, the former 2.155872e+09
< and BOTH THE SAME 00000000000 as octal and 41E01000 as hex (different
< from the one I assigned)

< In Java I tried

< int i ;
< System.out.format("i is: %11d %11o %8x %n", i,i,i);

< float f ;
< System.out.format("f is: %e %n", f );

Look at the FloatToIntBits and IntToFloatBits functions.
(I might have the names slightly wrong.) Also you might
like the DoubleToLongBits and LongToDoubleBits functions.
(oops, static methods.)

< Here format does not support the o and x descriptors for float argument.

< Anyhow I tested assignments for integer and they do work

< i=037777777776 ; /* -2 */
< i=0X7FFE ; /* 32766 */

< while assignment for real do not work (as in C)

< f=0X3F800000; /* should be 1.0 */
< f=0X40800000; /* should be 4.0 */
< f=0X80800000; /* should by tiny */

< (the compiler does not complain, there are no runtime exceptions, but
< the result is not what expected

Why is the result not expected? You are assigning an integer
constant to a float variable. Though as Java requires IEEE
floating point and supplies the conversion functions it should
work if done right.

< for instance the latter returns -2.139095e+09 and the one for 4.0
< returns 1.082130e+09

< I haven't tested assignment of hex or oct constants to strings in
< neither of the two latter languages (I guess Java will be using unicode,
< not plain ascii)

-- glen

 

[Ben Bacarisse]

I am collecting a sort of phrase books with equivalent "things" in
various languages.

The major problem is that an assignment to a float gives an unexpected
result (no compile or runtime error)

f=0X40800000; /* should return 4.0 */
f=0X80800000; /* should return tiny */

You've had this explained, so I will just add that C99 does allow you
to specify a floating point constant in hexadecimal. They look like
this:

float x = 0x3.f8p-2f;

The exponent is decimal -- the trailing f simply marks this as a float
(rather than a double) and is not a digit in the exponent. All of the
letters that are used in these constants can be in either case.

<snip>

 

[Lew]

for instance the latter returns -2.139095e+09 and the one for 4.0
returns 1.082130e+09

Huh.  Mine seems fine.  What hardware do you run on and what Java
compiler do you use?  SSCCE?

<code>
/** Java float test */
public class FloatTest {

     public static void main(String[] args) {
         float f = 1.0f;
         int fi = Float.floatToRawIntBits(f);
         f = Float.intBitsToFloat( 0x3f800000 );
         System.out.printf("%x\n", fi );
         System.out.printf("%g\n", f );
     }

}

</code>

<output>

run:
3f800000
1.00000
BUILD SUCCESSFUL (total time: 0 seconds)

</output>

The OP didn't use Float.intBitsToFloat(), but directly assigned the
int value to the float. Naturally that invoked the usual int-to-float
conversion, which was not what the OP wanted, but it is what the Java
language promises to do.

 

[markspace]

The OP didn't use Float.intBitsToFloat(), but directly assigned the
int value to the float. Naturally that invoked the usual int-to-float
conversion, which was not what the OP wanted, but it is what the Java
language promises to do.

Ah, ok. "Pilot error."

 

[Richard Maine]

On Jun 15, 1:06 pm, markspace <[email protected]> wrote:

The OP didn't use Float.intBitsToFloat(), but directly assigned the
int value to the float. Naturally that invoked the usual int-to-float
conversion, which was not what the OP wanted, but it is what the Java
language promises to do.

It is also what some Fortran compilers are likely to do with the OP's
original nonstandard "Fortran" code. There appears to be an element of
commonality across the languages here. I'd say that the most significant
element of commonality is the unsupported nature of the OP's
expectations.

 

[Joshua Cranmer]

while assignment for real do not work (as in C)

f=0X3F800000; /* should be 1.0 */
f=0X40800000; /* should be 4.0 */
f=0X80800000; /* should by tiny */

(the compiler does not complain, there are no runtime exceptions, but
the result is not what expected

Actually, according to the JLS, this is very much expected. The
hexadecimal literals are, of course, integers, and assigning an integer
to a float converts the integer into the closest representation in the
float value set.

I haven't tested assignment of hex or oct constants to strings in
neither of the two latter languages (I guess Java will be using unicode,
not plain ascii)

In Java, the conversion of constants would be via StringBuffer's
toString(int) method, which would just print out the number in nominal
decimal format. Strings are internally stored in Java as UTF-16, but
conversion to bytes is often handled as UTF-8 or the platform default
encoding, which is almost always backwards-compatible with ASCII (I
think pretty much everything but multiple-bit fixed-width encodings and
EBCDIC).

 

[Roedy Green]

while assignment for real do not work (as in C)

f=0X3F800000; /* should be 1.0 */

Why SHOULD it work the same as C?

For heaven's sake read up on the syntax rather than trying to guess
it.

See http://mindprod.com/jgloss/literal.html
http://mindprod.com/jgloss/cast.html
http://mindprod.com/jgloss/floatingpoint.html especially
longBitsToDouble
--
Roedy Green Canadian Mind Products
http://mindprod.com

If everyone lived the way people do in Vancouver, we would need three more entire planets to support us.
~ Guy Dauncey

 

[jameskuyper]

Why SHOULD it work the same as C?

Keep in mind that LC's expected results for C are just as incorrect as
they are for java. Does the above code not work essentially the same
as in C? I'm no Java expert, but I thought that this was an area where
java is consistent with C.

 

[glen herrmannsfeldt]

<> > f=0X3F800000; /* should be 1.0 */
< Keep in mind that LC's expected results for C are just as incorrect as
< they are for java. Does the above code not work essentially the same
< as in C? I'm no Java expert, but I thought that this was an area where
< java is consistent with C.

As integer constants, yes, the results will be pretty much
the same in Java and C. As Java doesn't have the unsigned types
that C has, there might be some sign related effect.

Java has the conversion functions that allow one to copy bit
patterns into floating point variables. In C you can do it
using pointers to unsigned char, if you know the length.

Java requires IEEE floating point, in C you get whatever floating
point is used on your system, possibly with an unusual endianness.
(Especially VAX where integers are little endian, and floating
point is not big or little endian.)

-- glen

 

[Phil Carmody]

Why SHOULD it work the same as C?

Because the language was designed to share the same syntax
as C for such things?

For heaven's sake read up on the syntax rather than trying to guess
it.

And what have you done about the syntax of C? It appears that you've
ascribed meaning to, and thence trusted, three of the words in a post
by someone who was demonstrably entirely ignorant about the subject
matter he was addressing. A foolish move.

Phil

 

[Guest]

I am now considering the indication of constants as hex, oct or binary
constants. I have considered fortran, C, Java, IDL and (my)sql. I have a
question on the first three.

[examples snipped]

Thanks to everybody for the replies, which I can summarize as follows (I
will reply separately on specific questions).

- some of the features I used are non-standard
- in some languages a format specification (or edit
descriptor,whatever you call it) implies
or requires a particular data type (and may cause an implicit
conversion). In particular in C "'%o' and "%X' format specifiers
require an unsigned int"
- in some languages (or all ? definitely C and Java) hex or oct
constants are integer. There may be means to store an hex constant
into a float like Float.intBitsToFloat in Java

- it is not obvious to find the relevant information in the
documentation :-(

 

[Guest]

None of these are standard Fortran.

I must say I never used hex/oct/bin constants (hex for short in the
remainder of this post) in the past because they weren't standard. If I
needed to force a particular binary representation I used bit
manipulation (let's say that since at least 10 years with the demises of
the Vaxes, one can reasonably assume, but for the endianness,
2-complement integers and IEEE floating points).

But reading Metcalf, Reid and Cohen (Fortran 95/2003 explained) I got
the impression they were standardized NOW.

What is exactly non standard in my usage ?

- usage of hex constants in assignments instead of DATA ?
- usage of hex constants for non-integers ?
- usage of hex edit descriptor for non-integers ?

Have you tried the compiler switch to warn about nonstandard forms? If
you did so and the compiler failed to give you a message about these,
then the compiler violates the standard.

It does (so far testing with ifort).

The ones assigning directly to a real are particularly nonportable.
Even among compilers that accept the nonstandard syntax, you will find
differences in interpretation of this.

OK. Point taken.
I'd better revert to my old usages and consider hex constants as
something to avoid.

It appears that you are not actually comparing the Fortran language to
other languges, but instead comparing a particular Fortran compiler.

Well, unless one has access to The Standard Itself, the only way one can
gain experience is testing with specific compilers, and with the ones
one has at hand. In the past (with f77) I developed an idea of "the
common and reasonable extensions to the standard" working with HP, IBM,
VAX, Sun, DEC Alpha ... but that because I got exposed to such hardware
and OS. Nowadays our environment is essentially a Linux/Intel one.

 

[Ben Bacarisse]

I am now considering the indication of constants as hex, oct or
binary constants. I have considered fortran, C, Java, IDL and
(my)sql. I have a question on the first three.

[examples snipped]

Thanks to everybody for the replies, which I can summarize as follows
(I will reply separately on specific questions).

- some of the features I used are non-standard
- in some languages a format specification (or edit
descriptor,whatever you call it) implies
or requires a particular data type (and may cause an implicit
conversion). In particular in C "'%o' and "%X' format specifiers
require an unsigned int"
- in some languages (or all ? definitely C and Java) hex or oct
constants are integer. There may be means to store an hex constant
into a float like Float.intBitsToFloat in Java

- C has hex floating point constants.

- it is not obvious to find the relevant information in the
documentation :-(

What is "the documenation"? What I mean is you may simply be looking
in the wrong place.

 

[Guest]

LC's No-Spam Newsreading account wrote:

The '%o" and "%X" format specifiers require an unsigned int argument,

I thought they were "universal" like O and Z in Fortran.

'i' is promoted to an int before being passed to printf(), and you

I wasn't aware of this. See above.

printed it using a format specifier for an unsigned int. Why do you
think that sizeof(short) has anything to do with the result that you
get?

Expecting an universal edit descriptor, I expected that a 2-byte
quantity resulted in 4 hex digits.

Why would expect the result to be 4.0?

because that's the internal representation of the float 4.0 in IEEE
(just re-checked with my old Excel spreadsheet which gives the internal
representation of IEEE and VAX floats). I assumed that an "hex constant"
was just a bit pattern, with no type implied.

I realize now that, at least in C, hex constants are integer constants
(is this implicit or documented ?)

 

[James Kuyper]

I am now considering the indication of constants as hex, oct or binary
constants. I have considered fortran, C, Java, IDL and (my)sql. I have
a question on the first three.

[examples snipped]

Thanks to everybody for the replies, which I can summarize as follows (I
will reply separately on specific questions).

- some of the features I used are non-standard
- in some languages a format specification (or edit
descriptor,whatever you call it) implies
or requires a particular data type ...

Correct so far.

... (and may cause an implicit
conversion). ...

Incorrect, at least with regard to printf() in C. The implicit
conversions we told you about are the default argument promotions that
occur as the result of passing an unprototyped argument to a function,
they have no direct connection to the format specifiers. While there is
a prototype in <stdio.h> for printf(), only the first two arguments have
explicit types - the remaining objects are subject to only the default
argument promotions. Note, in particular, that the implicit conversion
may result is a type different from that specified by the corresponding
format specifier: that's what causes the problems.

... In particular in C "'%o' and "%X' format specifiers
require an unsigned int"
- in some languages (or all ? definitely C and Java) hex or oct
constants are integer. There may be means to store an hex constant
into a float like Float.intBitsToFloat in Java

- it is not obvious to find the relevant information in the
documentation :-(

I can't address the quality of the documentation for whichever
implementation of the C standard library that you're using. However, the
C standard itself says this pretty clearly: "If any argument is not the
correct type for the corresponding conversion specification, the
behavior is undefined." (7.19.6.1p9), and the documentation for each
conversion specification identifies what the "correct type" is.

Any decent elementary C text should tell you that initializing an object
with a expression causes the expression's value to be converted to the
object's type and stored in the object. I can't really figure out why
you expected different behavior, but I doubt that it's the fault of your
text.