It is a lesson hard-learned over many programmer-years of coding that portability should be acquired as an innate reflex; that whenever you are about to sacrifice portability, you ask yourself "Why am I doing so, are there alternatives, and have I done at least a rudimentary cost/benefit analysis of this decision?"

What you don't do is throw away portability just because you happen to be using a particular machine right now. This is something quickly learned in comp.lang.c.

Incidentally, a better model than PK's might be:

typedef struct foo {int i} s;

s f;

Now what is 'f'? Is it an 's', is it a struct foo, or is it an int? And what about f.i? Both have the same address, casting either's address to any of the pointer types 's *', 'struct foo *' or 'int *' is valid; writing

*(int *)&f=1;

does just the same as f.i=1; quite possibly the compiler will generate the same code, because after all, the territory is the same. It's just that "f.i=1" is a higher-level map, which conveniently abstracts things out.

This is made more explicit by considering struct bar {int a; long b;} t; *(long *)(((char *)&bar)+offsetof(bar, b))=1; // same as bar.b=1

Of course, you could go to all the trouble of computing the offset pointer every time, since that's what happens on the "quark" (assembly language) level of the territory, but the higher-level 'struct' map is cognitively useful.