>Having said that, one occasion where people might be surprised by gcc (this
>might be a known issue, though) is: typedef + __attribute__; it ignores
>__attribute__. For example,
>#include <stdio.h>
>
>struct foo_16 {
> char xxx[3];
> short yyy;
>} __attribute__ ((aligned (16)));
>
>typedef struct bar_16 {
> char xxx[3];
> short yyy;
>} bar_16_t __attribute__ ((aligned (16)));
This is a user error (sort of); you're supposed to write:
typedef struct bar_16 {
char xxx[3];
short yyy;
} __attribute__ ((aligned (16))) bar_16_t;
[The attribute modifies the original struct type, which gets then
assigned the typedef name. This is similar to the case where a
variable definition follows:
struct { ... } __attribute__() var;
vs.
struct { ... ] var __attribute__();
In the first case, the attribute modifies the struct type itself,
while in the second case the attribute applies only to the one
instance var.]
A warning would still be nice; we got bitten by that one a couple
of times ...
>In the kernel, there are several device drivers (ftape-bsm.h, e100.h, for
>example) are doing this kind of thing (i.e. typedef + attribute).
Well, I guess in those files the attribute((packed)) is a no-op
anyway as the structs are already packed according to the default
rules, so it doesn't really matter. It should probably still be
fixed ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/