Michael Wojcik said:
One way to avoid the const "fall-through" Andrey described, which is
what's giving x-pander trouble, would be to make quad_t a structure
rather than an array.
i was also thinking of making this type:
typedef struct {
int word[4];
} quad2_t;
which would work as excpected, but it felt rather artificial to me to
encapsulate an array inside a struct.
It may feel artificial to you, but remember that "struct" is the C
keyword for creating new types; "typedef" only creates an alias. If
you want a type that behaves like a type, use struct. (Personally,
I'd use struct and skip the typedef; I think typedef is rarely
actually useful. But opinions differ on this question.)
You can always set an int* to the .word member inside each function
if you don't want to qualify every access:
void foo(const quad2_t *quad)
{
int *qdata;
if (! quad) return;
qdata = quad->word;
...
}
however I think i'm going to use that, one question i have:
am i guaranteed that quad2_t type has exactly same memory representation as
quad_t, so that:
sizeof(quad2_t) == sizeof(quad_t) == 4*sizeof(int)
and the alignment is the same:
quad2_t m;
(*(quad_t *)&m)[0] = 0; /* is this valid ? */
Hmm. There can't be padding before the first member of a structure,
and you only have one member here. There *can* be padding at the end
of a structure, and in fact there must be if any would be needed
between items in an array of that structure. In this case, though,
any reasonable implementation ought to be aligning an array of quad2_t
just as it would align an array of int, since that's all that quad2_t
contains.
that is exactly the problem.
it's a real shame that in C "pointer-to-array-of-four-int" is an not
compatible with "pointer-to-array-of-four-const-int".
could someone explain me the rationale behind this incompatibility?
I suspect the committee felt that it was an unreasonable burden to
impose more complex const-conversion rules on implementors. (This is
actually a conversion rule, not a compatibility rule.) The one we
have - pointer to T can be converted to pointer to const T - is
pretty simple and easy for implementors to get right.
The conversion you want - from pointer-to-array-of-T to pointer-to-
array-of-const-T - requires "pushing" the const conversion one step
further. If they allowed that, they'd probably have to allow things
like pointer-to-struct-containing-T to pointer-to-struct-containing-
const-T, and clearly things are getting much more complicated when
the implementation has to figure out if any consts are being added
anywhere in the conversion process.
also how exactly does the c99 standard explicitly states that?
I don't have a copy of C99 (must remember to get it from the ANSI
store...), just a copy of the final draft. C90 says:
[#2] For any qualifier q, a pointer to a non-q-qualified
type may be converted to a pointer to the q-qualified
version of the type; the values stored in the original and
converted pointers shall compare equal. (n869 6.3.2.3)
That says that the conversion is allowed. What makes it happen
automatically is:
-- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to
by the left has all the qualifiers of the type pointed
to by the right; (n869 6.5.16.1 #1)
This is part of the "simple assignment" rules, which (AIUI) apply in
this case. Note that the destination must have all the qualifiers of
the source, but not vice versa.
And 6.5.4 says that any pointer conversion not covered by 6.5.16.1
requires an explicit cast.
--
Michael Wojcik (e-mail address removed)
This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation
