Re: Alignment in structs
Re: Alignment in structs
- Subject: Re: Alignment in structs
- From: Steve Christensen <email@hidden>
- Date: Mon, 17 Jul 2006 13:57:33 -0700
On Jul 17, 2006, at 12:59 PM, Rush Manbert wrote:
Steve Christensen wrote:
On Jul 17, 2006, at 11:29 AM, Rush Manbert wrote:
Laurence Harris wrote:
Okay, this is weird. I took out the __attribute__((__packed__))
when I got the error. Then I put it back and was going to use
your suggestion, but I don't get the error now. I wonder if
there was some kind of compiler error the first time.
From what I've read, it appears that gcc would not complain if
the calling argument were a const reference. It seems that read
only access of packed data members is fine, but write access
through a reference is not. If the calling argument is a pointer
to UInt32, that will be okay with the compiler too. I don't
really understand why references are restricted in this way, but
I assume there's a good (if obscure) reason.
Unaligned accesses can cause a crash on some processors so gcc
may just be generalizing for that case. Thus, calling
void foo(UInt32 x);
would be fine for all cases since the compiler could generate the
appropriate instructions to gather up all the pieces for x and
pass a UInt32 value into foo. Calling
void foo(UInt32& x);
would be problematic because foo doesn't know that x is
potentially misaligned.
I'm not looking to start a debate, but I don't believe that
explains why calling
void foo (UInt32 *p);
doesn't generate a warning. The hardware memory access is the same
in either case.
Did I miss that bit. Yep, I would assume that a UInt32& and a UInt32*
would be treated the same.
I'm still curious about Larry's real use case...
I can't speak to Larry's case, but just look at all the Carbon
headers. You see
#pragma options align=mac68k
or
#pragma pack(2)
all over the place. They're just making sure that various compilers
(and per-architecture builds) pack structures the "same way it's
always been done."
steve
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden