On Thu, 08 Feb 2007 19:20:39 +
Phil Endecott [EMAIL PROTECTED] wrote:
From a
higher-level (source code) point of view, the alignment doesn't affect the
set of operations which can be applied to the data type.
It affects whether you can legally use to take its address.
Grrr... pet
Oleg Verych wrote:
Your intro pseudo-code:
| g() {
| char c;
| struct S s; /* packed or not */
| (s.intfield)++;
| f(s);
| }
Due to `c', `s' gets to be unaligned, i.e. light turned before you've
touched a switch: layout of `c' is independed, it's a byte, not
From a
higher-level (source code) point of view, the alignment doesn't affect the
set of operations which can be applied to the data type.
It affects whether you can legally use to take its address.
Phil.
-
Using
On Thu, 8 Feb 2007, Phil Endecott wrote:
From a
higher-level (source code) point of view, the alignment doesn't affect the
set of operations which can be applied to the data type.
It affects whether you can legally use to take its address.
Are you sure about that? I would think that
Alan Stern wrote:
On Thu, 8 Feb 2007, Phil Endecott wrote:
From a
higher-level (source code) point of view, the alignment doesn't affect the
set of operations which can be applied to the data type.
It affects whether you can legally use to take its address.
Are you sure about that?
On Thu, 8 Feb 2007, Phil Endecott wrote:
Alan Stern wrote:
On Thu, 8 Feb 2007, Phil Endecott wrote:
From a
higher-level (source code) point of view, the alignment doesn't affect
the
set of operations which can be applied to the data type.
It affects whether you can legally
I won't pretend to understand all the subtleties of
__attribute__((packed)), but I did learn something about it when I
hacked USB/IP to run on ARM, for the NSLU2, last year. The issue
boiled down to this:
struct S {
int intfield;
char charfield;
} /* maybe add: __attribute__((packed))
On Wednesday 07 February 2007 3:04 am, Phil Endecott wrote:
I won't pretend to understand all the subtleties of
__attribute__((packed)), but I did learn something about it when I
hacked USB/IP to run on ARM, for the NSLU2, last year. The issue
boiled down to this:
struct S {
int
David Brownell wrote:
On Wednesday 07 February 2007 3:04 am, Phil Endecott wrote:
I won't pretend to understand all the subtleties of
__attribute__((packed)), but I did learn something about it when I
hacked USB/IP to run on ARM, for the NSLU2, last year. The issue
boiled down to this:
On Wednesday 07 February 2007 10:41 am, Phil Endecott wr
Err, maybe my example was over-simplified then, sorry. Try another
level of indirection:
void inc(int* i) {
(*i)++;
}
void f(struct S* s) {
inc((s-intfield);
One would expect that to generate a warning ... that you're
Just to throw one other factor into the discussion: if you add
something like __attribute__((packed)) to the definition of a struct in
an include file (e.g. ch9.h), it will affect third-party user-land code
that happens to #include it. People writing such code probably don't
get any benefit
David Brownell wrote:
On Wednesday 07 February 2007 10:41 am, Phil Endecott wr
void inc(int* i) {
(*i)++;
}
here's a quote from Paul Brook
(http://gcc.gnu.org/ml/gcc-help/2006-12/msg00115.html):
the compiler is allowed to assume that the low 2 bits of an int*
are zero.
Unless
From: Phil Endecott [EMAIL PROTECTED]
Newsgroups: gmane.linux.usb.devel
Subject: Re: usb: descriptor structures have to be packed
Date: Wed, 07 Feb 2007 22:14:47 +
Just question.
void inc(int __attribute__((aligned(1))) * i)
void inc(int * __attribute__((aligned(1))) i)
void inc(int *
On Wednesday 07 February 2007 2:14 pm, Phil Endecott wrote:
David Brownell wrote:
On Wednesday 07 February 2007 10:41 am, Phil Endecott wr
void inc(int* i) {
(*i)++;
}
here's a quote from Paul Brook
(http://gcc.gnu.org/ml/gcc-help/2006-12/msg00115.html):
the compiler is
Oleg Verych wrote:
From: Phil Endecott [EMAIL PROTECTED]
Just question.
void inc(int __attribute__((aligned(1))) * i)
void inc(int * __attribute__((aligned(1))) i)
void inc(int * i __attribute__((aligned(1
Why 1, and not 2?
1 is the worst unalignment.
If I specify 2 I get the same
On Wednesday 07 February 2007 12:37 pm, Phil Endecott wrote:
If you can avoid adding an
attribute and instead deal with the issues at the point of use, life
would be easier for such people.
And you're volunteering to audit all the code, in kernel and userspace,
and merge patches
On Wed, Feb 07, 2007 at 10:58:17PM +, Phil Endecott wrote:
[]
This patch is:
Prevent an unaligned exception to occur. (GCC 4.1) tmp is defined as char
pointer while it is later accessed as short.
This is, in a sense, the opposite of what we're looking at. There they
have added
17 matches
Mail list logo
