lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 Apr 2015 05:37:20 +0300
From: Alexander Cherepanov <>
Subject: Re: [PHC] On type aliasing and similar issues

On 2015-04-07 15:49, Thomas Pornin wrote:
>> A solution here is to use a union type containing all of the integer
>> and SIMD types.  The called function may cast the pointer to a pointer
>> to such union type, then access the fields of its desired type.  The
>> compiler will then know that they might alias those other listed
>> types.
> In fact, even with a union, the aliasing rules (as per the C standard)
> forbid such trans-type access.

I'm not sure what exactly is proposed by Solar above. Probably the 
forbidden step is dereferencing casted pointer, not accessing the 
union's member. But your example below seems to be allowed by the C 

> If you have this:
>      union {
>          uint32_t x[2];
>          uint64_t y;
>      } *v;
>      (...)
>      v->x[0] = 17;
>      v->y = 42;
>      printf("%u\n", (unsigned)v->x[0]);
> then the compiler may still "legally" print out '17', i.e. considering
> that the access to 'y' did not impact the values that can be accessed
> through 'x', because of the distinct types (there again, there are
> special rules for 'char' and 'unsigned char'). While the union guarantees
> identity of storage ((void *)&v->x == (void *)&v->y), it still does not
> allow seemless transtyping.

AFACT this is implementation-defined in C89 ( and fully defined 
in C99 and C11 (

Alexander Cherepanov

Powered by blists - more mailing lists