Hi,
On Sun, 10 Jan 2010, Dave Korn wrote:
Ok. So if I had four ints, and I wanted to cast the pointers to char
and compare them as 16 chars, that would be OK, because the chars would
alias the ints; but in this case, where they started as chars and I cast
them to ints, those ints don't
On Sun, 2010-01-10 at 15:46 +0100, Eric Botcazou wrote:
The aliasing rules treat char specially because char is a bit like a
poor main's void.
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
BTW in Ada if one uses address clause
BTW in Ada if one uses address clause to overlay a 16 character string
and a 4 4-byte integer array (both aliased) which is then accessed what
can we expect GCC-wise? Are we safe from aliasing related optimizations?
Yes, we use a big hammer to make sure 'Address is immune to these issues.
--
Dave Korn dave.korn.cyg...@googlemail.com writes:
Is that really right? The type of the pointer (in6-__s6_addr) that we're
casting is unsigned char *, so shouldn't it already alias everything anyway
and dereferencing it be allowed, like it is for the casted (a)? I'll file a
PR if so. (I
On 01/10/2010 10:30 AM, Andreas Schwab wrote:
Dave Korn dave.korn.cyg...@googlemail.com writes:
Is that really right? The type of the pointer (in6-__s6_addr) that we're
casting is unsigned char *, so shouldn't it already alias everything anyway
and dereferencing it be allowed, like it is
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it. That is
clearly the
Andrew Haley a...@redhat.com writes:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I
...
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it.
In which way does it make a difference? For aliasing consideration,
only the type of access matters.
The aliasing rules treat char specially because
...
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t *)(a))[0]
== ((const uint32_t *)(in6-__s6_addr))[0]
The aliasing rules treat char specially because char is a bit like a
poor main's void.
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
--
Eric Botcazou
On 01/10/2010 02:39 PM, Paul Koning wrote:
...
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t *)(a))[0]
==
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I
On 01/10/2010 04:58 PM, Patrick Horgan wrote:
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless
On Sun, 10 Jan 2010, Patrick Horgan wrote:
But in the new compilers it's an integer type, not a character type--from the
spec:
signed char is a signed integer type, and unsigned char is an unsigned
integer type. (char is neither, although it behaves the same as one of
signed char and
Patrick Horgan wrote:
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a
Andrew Haley wrote:
On 01/10/2010 02:39 PM, Paul Koning wrote:
...
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t
On Sun, Jan 10, 2010 at 08:58:47AM -0800, Patrick Horgan wrote:
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as
Eric Botcazou wrote:
The aliasing rules treat char specially because char is a bit like a
poor main's void.
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
Ok. So if I had four ints, and I wanted to cast the pointers to char
Dave Korn dave.korn.cyg...@googlemail.com writes:
Andreas, you wrote: Aliasing is not symmetric. To be precise, we're
saying it's not commutative here; that (A aliases B) does not imply (B aliases
A)? I don't think I've ever heard it expressed that explicitly before.
Aliasing is not an
Andreas Schwab wrote:
Dave Korn dave.korn.cyg...@googlemail writes:
Andreas, you wrote: Aliasing is not symmetric. To be precise, we're
saying it's not commutative here; that (A aliases B) does not imply (B
aliases
A)? I don't think I've ever heard it expressed that explicitly before.
Yes, fair enough; but properties can commute just as much as operators
can (although it's perhaps less intuitively surprising when they don't).
To be picky, binary operators are commutative (or not), binary relations are
symmetric (or not).
--
Eric Botcazou
Eric Botcazou wrote:
Yes, fair enough; but properties can commute just as much as operators
can (although it's perhaps less intuitively surprising when they don't).
To be picky, binary operators are commutative (or not), binary relations are
symmetric (or not).
Ah, I wasn't aware of
On Sun, Jan 10, 2010 at 06:24:14PM +, Dave Korn wrote:
Eric Botcazou wrote:
The aliasing rules treat char specially because char is a bit like a
poor main's void.
Not symmetrically though, only for the type of the lvalue expression used
to
access the object (C99 6.5.7).
24 matches
Mail list logo
