Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #19904

Re: Cast from double to int64_t/uint64_t : +/- inf handling ?

Show all headers | View raw

On 04/25/2012 10:17 AM, Xavier Roche wrote:
> Hi folks,
> 
> Are there any rules regarding cast result from double to 
> int64_t/uint64_t for positive/negative infinity, or is the result 
> totally undefined ?

6.3.1.4p1 defines the behavior when a finite value of real floating type
is converted to an integer type; the behavior is undefined if the value
cannot be represented in the integer type. Nothing defines the result
when infinite values are converted, so the behavior is undefined "by
omission of any explicit definition of behavior" (4p2). The same
argument applies to NaNs.

This fits into the general scheme of C conversions; they are
value-preserving, to the extent that they can be, when the value being
converted is within the representable range of the destination type, and
usually have undefined behavior when it is not. The special handling of
_Bool, and the modulo results when converting from integer values to
unsigned types are the two main exceptions to that rule.

C integer types don't have representations of infinities or NaNs (though
it would be perfectly feasible to implement an integer-like type which did).

> Typically, playing with cast on x86-64 arch (Linux/gcc) leads to the 
> following observations:
> 	(uint64_t) -inf == 9223372036854775808 (8000000000000000)
> 	(uint64_t) inf == 0 (0)
> 	(int64_t)  -inf == -9223372036854775808 (8000000000000000)
> 	(int64_t)  inf == -9223372036854775808 (8000000000000000)
> 
> (I was expecting (uint64_t) inf to give 0xffffffffffffffff for example)
> 
> [ I could play with finite()/isinf(), but I was wondering if a fast 
> method would be available/documented. ]

To avoid undefined behavior, it is necessary to avoid converting any
value that is greater than [U]INT64_MAX, or less than INT64_MIN (or less
than 0 for uint64_t). Infinities will be captured by such checks, so
there's no need for a separate check of isfinite() or isinf(). On the
other hand, if NaNs are a possibility, you will need to check isnan().

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Cast from double to int64_t/uint64_t : +/- inf handling ? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2012-04-25 16:17 +0200
  Re: Cast from double to int64_t/uint64_t : +/- inf handling ? James Kuyper <jameskuyper@verizon.net> - 2012-04-25 11:37 -0400
    Re: Cast from double to int64_t/uint64_t : +/- inf handling ? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2012-04-26 10:54 +0200
    Re: Cast from double to int64_t/uint64_t : +/- inf handling ? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-04-26 06:09 -0700
    Re: Cast from double to int64_t/uint64_t : +/- inf handling ? Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-07 16:46 -0700
  Re: Cast from double to int64_t/uint64_t : +/- inf handling ? "Fred J. Tydeman" <tydeman.consulting@sbcglobal.net> - 2012-04-26 14:49 +0000

csiph-web