Safe conversion from floating real to integer (and vice versa)

[rz0]

Hi all,

This is a question about both C89 and C99 and is based on my partial
reading of the standard drafts (one from before C89 but mainly
N1124). If appropriate, please give a separate answer for each version
of the language.

Let's consider the conversion from a given floating real type to a
specific integer type.

Given a value of floating real type Tf, unknown at compile-time. What
is the safest way to convert it to a value of integer type Ti (other
than _Bool), without invoking Undefined Behavior due to out of range
error? The standard says that whenever the value would not be
representable in the converted-to type, the result would be undefined.
Yet, how do I test for valid values?

I thought there would be a macro in limits.h or float.h or maybe
stdint.h, for C99, to indicate the valid range of floating-point
values of a given type that may be converted safely from but did not
find any. I thought about testing the macros defining maximal values
of integer types but then, the test itself would invoke UB if *_MAX
were out of range of representable values, for the double type.

I did find the lrint family of functions, which only have unspecified
results when the converted value is not representable. However, it is
only part of the C99 specifications as far as I know and I would
rather have a single solution for both versions.

I am also interested in conversions from int to double, the problem is
much the same. Besides, there is no lxdbl function that would do the
opposite of lrint.

Narrowing the problem to the conversions from double to int and vice
versa, when I started learning C some years ago (by the way, I'm still
learning), I was told that the range of double was always greater than
that of int. Yet, I am unable to find in my copy of the drafts a
section where this is stated. If it is indeed the case, then the
conversion from int to double cannot cause UB and the opposite could
easily be made safe by converting INT_MAX to double and comparing to
the value which is to be converted. Could you then point out the
relevant sections for me to check by myself?

There is probably something I have missed in my reading of the drafts
or that I have not thought about, so please give advice.

Thanks in advance.

 

[Walter Roberson]

This is a question about both C89 and C99

Let's consider the conversion from a given floating real type to a
specific integer type.

Given a value of floating real type Tf, unknown at compile-time. What
is the safest way to convert it to a value of integer type Ti (other
than _Bool), without invoking Undefined Behavior due to out of range
error?

But it is not *possible* to get a "real type Tf, unknown at compile-time".
The closest you could come would be to have some (specific) value,
take its address, convert the pointer to (void *) and then use the
pointer somehow without having passed along the history of what the
original type was. That would, however, be a fairly pointless thing
to do, as the only operation one could safely perform on the (void *)
would be to convert it to a pointer to a character and dereference
the first character.

Narrowing the problem to the conversions from double to int and vice
versa, when I started learning C some years ago (by the way, I'm still
learning), I was told that the range of double was always greater than
that of int. Yet, I am unable to find in my copy of the drafts a
section where this is stated. If it is indeed the case, then the
conversion from int to double cannot cause UB and the opposite could
easily be made safe by converting INT_MAX to double and comparing to
the value which is to be converted. Could you then point out the
relevant sections for me to check by myself?

You can compare DLB_MAX_10_EXP to the ceiling of log10 of the
number (i.e., the number of decimal digits in the integer part of the
number.)

Converting INT_MAX to double and comparing the value has the old
problem of round-off: the converted value might round upwards, and
then when converted back the result might be more than INT_MAX. And
you have the standard problems with exact comparisons of floating
point numbers.

 

[rz0]

On Wed, 1 Feb 2006 16:35:57 +0000 (UTC)

But it is not *possible* to get a "real type Tf, unknown at
compile-time".

Well, it wasn't clear from my post but I meant the value is unknown at
compile-time. Of course, types are known. My fault.

You can compare DLB_MAX_10_EXP to the ceiling of log10 of the
number (i.e., the number of decimal digits in the integer part of the
number.)

I see the point in doing this comparison. It won't help in finding the
greatest value representable in a int. DBL_MAX_10_EXP only gives information
about what values can be represented as a double, but not as an int so
I don't see how it relates to the problem of converting from double to int.
Please explain.

Converting INT_MAX to double and comparing the value has the old
problem of round-off: the converted value might round upwards, and
then when converted back the result might be more than INT_MAX. And
you have the standard problems with exact comparisons of floating
point numbers.

My question was not quite about that. In fact, if INT_MAX is not in
range of representable double values, the behaviour will be undefined as
specified in $6.3.1.4. That is why I am asking if it is said anywhere
in the standards that int values are all in range of double.

 

[Jordan Abel]

Please don't "justify" text. Fixed in quote.

Given a value of floating real type Tf, unknown at compile-time.

How is it unknown at compile-time?

What is the safest way to convert it to a value of integer type Ti
(other than _Bool), without invoking Undefined Behavior due to out of
range error? The standard says that whenever the value would not be
representable in the converted-to type, the result would be undefined.
Yet, how do I test for valid values?

The only way i can think of is to print it to a string with snprintf and
then read it with strtol.

I thought there would be a macro in limits.h or float.h or maybe
stdint.h, for C99, to indicate the valid range of floating-point
values of a given type that may be converted safely from but did not
find any.

You could check it against INT_MAX, but

I thought about testing the macros defining maximal values
of integer types but then, the test itself would invoke UB if *_MAX
were out of range of representable values, for the double type.

Are you sure that that invokes UB?

 

[rz0]

Please don't "justify" text. Fixed in quote.



How is it unknown at compile-time?

I'm sorry but there is no context. This is just a thought about
conversion, not a real-life situation. I just meant that it would be a
hypothetical situation where the compiler cannot predict in any way the
value and thus the conversion has to be done at run-time with no
warning/error/diagnostic given at compile-time. I am very sorry if it
is not clear but English is not my native language and I am not used to
Usenet posting; I was just trying to provide as many useful information
as possible.

The only way i can think of is to print it to a string with snprintf
and then read it with strtol.

I have somewhat thought about it but found that it would be uneffective,
but if you say it is, then I think using such a method is fine.

But what if the type is some user-defined type then. Consider I have no
control over the type being converted from and it happens to be a type
definition. Should I convert it by hand?

You could check it against INT_MAX, but


Are you sure that that invokes UB?

(ISO/IEC 9899:TC2 Committee Draft --- May 6, 2005 WG14/N1124) $6.3.1.4
says :
"When a value of integer type is converted to a real floating type, if
the value being converted can be represented exactly in the new type,
it is unchanged. If the value being converted is in the range of values
that can be represented but cannot be represented exactly, the result
is either the nearest higher or nearest lower representable value,
chosen in an implementation-defined manner. If the value being
^^^^^^^^^^^^^^^^^^^
converted is outside the range of values that can be represented, the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
behavior is undefined."
^^^^^^^^^^^^^^^^^^^^^^