[llvm-dev] double to unsigned char cast

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Fri May 25 01:37:39 PDT 2018


On Tue, May 22, 2018 at 6:17 PM, Jay K via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> This seems disappointing.
>
> Casting any value to an integral type should yield a value within the range
> of that integral type.

As Tim pointed out, that's not what the standard says though.

Trunk Clang (I'm not sure what version your Xcode Clang is based on)
has a flag to disable this optimization:
-fno-strict-float-cast-overflow

 - Hans


> The value can be anything, but it should be within range.
>
> i.e. it should be as if I anded it with (type)~(type)0.
>
>
> i.e. int i = (signed char)x;
>
> assert(i >= -128 && i <= 127);
>
>
> int i = (unsigned char)x;
>
> assert(i >= 0 && i <= 255);
>
>
> seem very reasonable, assuming there is no "trap"  before the assert.
>
>  - Jay
>
>
>
> ________________________________
> From: Tim Northover <t.p.northover at gmail.com>
> Sent: Thursday, April 5, 2018 4:41 PM
> To: Jay K
> Cc: llvm-dev at lists.llvm.org; lewurm at gmail.com
> Subject: Re: [llvm-dev] double to unsigned char cast
>
> Hi Jay,
>
> On 5 April 2018 at 07:49, Jay K via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
>> wrt
>>
>> https://github.com/mono/mono/commit/fb91fce5d339bb9ffe507588f5bc1d8d6f244d9b
>
>>
>>
>> This doesn't seem right to me.
>
> Nevertheless, it's what the standard says. C99 6.3.1.4: When a finite
> value of real floating type is converted to an integer type other than
> _Bool, the fractional part is discarded (i.e. the value is truncated
> toward zero). If the value of the integral part cannot be represented
> by the integer type, the behavior is undefined.
>
> By definition any double you're allowed to convert to an unsigned char
> doesn't need the "and".
>
> Cheers.
>
> Tim.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


More information about the llvm-dev mailing list