On Mon, 27 Jun 2005, Chip Salzenberg wrote:
> 1. "union Parrot_Context" is not portable C.
>
> The C standard requires that all structure pointers be bitwise
> compatible - same size, layout, etc.[*] It doesn't require that of
> other pointers -- specifically char* in this case. So the union:
>
> typedef union Parrot_Context {
> struct parrot_regs_t *bp; /* register base pointer */
> struct Real_Context *rctx; /* realcontext is at rctx[-1] */
> char *as_charp; /* to simplify allocation */
> } parrot_context_t;
>
> isn't guaranteed to work like you think it does.
>
> There are two good approaches to what you're trying to do here that I
> can recommend.
>
> a. remove the as_charp member and do without it.
>
> b. replace the union with a single pointer of whatever type is
> convenient ... a structure or a void* or whatever ... and just
> cast the pointer as needed. This isn't C++ ... pointer casts
> are guaranteed to have zero runtime cost. It's just a macro.
>
> I recommend (b).
Well, I think there are already way too many pointer casts and related
games in the source. Perhaps more to the point, not all casts are going
to work.
In particular, the last time I checked with gcc on SPARC, I got over 7,000
warnings of the form 'cast increases required alignment of target type'.
At that time, one of them was leading to a core dump (which I have since
fixed). Assigning to pointers of the correct type automatically documents
what you are actually trying to do, gets rid of the warnings, and assures
that objects are indeed suitably aligned.
In the perl5 source, I can at least look at the ?v.h header files and see
which structures are supposed to match up with each other, and hence I can
deduce which casts are intended. I haven't yet figured out in the parrot
source which structures are supposed to be "equivalent".
> If you want to zero a structure, why go to the trouble of asking for
> the address of its first member? Just use the address of the structure
> as a whole. That's the real starting point for sizeof() anyway.
>
> Even worse, I'm not sure the usage of FIRST_CTX_VAR is sound WRT the C
> standard(s). Does anyone on the list know, given:
>
> typedef struct {
> whatever_t m;
> } S;
>
> ... whether offsetof(S,m) is guaranteed to be zero? I think it's not,
> and so the usage of FIRST_CTX_VAR for e.g. memset is not OK.
I don't know what the standard says about the specific case of the
first element in a structure. In general, of course, the compiler is
free to put in whatever padding it it deems appropriate, but it may be
that the first element is special and can't have padding before it.
More importantly, though I wonder if that particular micro-optimization
is important to do at this point in parrot's development.
--
Andy Dougherty [EMAIL PROTECTED]
