> I am posting this before somebody will jump to a conclusion that
> "because egcs may have problems on Intel this implies that it will
> have the same trouble on Alpha, or other processor, as well".
>
[SNIPPED]
The problem with 'endian-ness` and other incompatibilities where
packets have to be assembled (such as networking), was addressed
using macros such as htons, htonl, etc.
According to my interpretation of the current 'C' standard, members
in structures can only be addressed by using the member name. No
assumption may be made about the actual location of a particular
member, nor the physical size of the object in memory. Note, in
the following discussion, the word 'object' means "a specific
addressable item". It has nothing to do with C++.
struct {
char one;
short two;
long three;
double four;
} foo;
foo.one != (*(char *)&foo);
To preserve alignment, the compiler could put member 'four' first.
I have never seen one that does, but it could, based upon the requirement
that members are accessible only via their member names.
Unions are only guaranteed to provide memory allocation necessary to
contain the largest object. Some particular alignment is not guaranteed
except that the objects are "properly" aligned to be addressable
on the target machine.
union{
struct {
char a[4];
} st;
long b;
} foo;
foo.b != *((long *) &foo.st.a[0]);
Dereferencing a pointer to an object of a different type than the
initial allocation may not provide the required results either.
Even character arrays are not intrinsically safe:
char foo[]={1,2,3,4,5,6,7,8};
Might be an array of shorts. If fact, as internationalization of
character sets becomes more commonplace, such allocations may become
more likely. Bit-fields have the same problem.
Fortunately, the writers of 'C' compilers allow programmers to make
certain assumptions even though the 'C' standard does not.
Therefore, to address specific memory objects, macros have to be defined
that are specific to a particular compiler and platform. Any code that
makes assumptions about the physical layout of objects existing in
memory is not portable. However, we need such code. Therefore, portable
code can be written using machine-specific and/or compiler-specific
macros. The macros are used to resolve the portability problems.
In the subject case, a macro is broken.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/