Re: pointer to array of const objects

From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 01/31/05 

Date: 31 Jan 2005 16:40:45 GMT

In article <ct9pr5$28ng$1@mamut1.aster.pl>, "x-pander" <ngclc@pitek.eu.org> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:ct8vua0b37@news1.newsguy.com...
> > In article <ajnev0dt0jpcc47ospsc6biu5rihroaob7@4ax.com>, Nick Austin
> > <see_reply_to_in_headers@nospam.com> writes:
> >> On Wed, 26 Jan 2005 02:29:33 +0100, "x-pander" <ngclc@pitek.eu.org>
> >> wrote:
> >>
> > 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.

> > The real issue isn't that the
> > array "itself" can't be const-qualified; it's that such a type isn't
> > compatible with pointer-to-array-of-four-int, which is what he wants
> > to pass.
>
> 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                  michael.wojcik@microfocus.com
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

Relevant Pages

  • Re: Errors with typedefs
    ... a series of variable declarations, ... C's "typedef" does not define types at all. ... It does this by requiring the "struct" keyword each time. ... Note that the "value" of an array is a pointer to its first element, ...
    (comp.lang.c)
  • Re: Array Manipln
    ... If you stick with MFC, ... If you have a typedef that defines the record format, an array of these, or an array of ... It just depends on whether you want to store the struct or a pointer to the ...
    (microsoft.public.vc.mfc)
  • Re: How to assign memory dynamically to a array of structures
    ... Your struct tag "hom_id" is the same as the name of one of your struct ... If you insist on using a typedef for your structure, ... I want to know how to assign memory to this array of structure at ... You can either use mallocto allocate an array, ...
    (comp.lang.c)
  • Re: compiling error
    ... As far as I was aware, array rvalues are never converted to pointers in ... C90, and that conversion is one of the changes C99 made. ... I vaguely remember a case involving a function returning a struct ...
    (comp.lang.c)
  • Re: contiguity of arrays
    ... pointer to the above struct, to a pointer to an array of 3 ints. ... and in this case there is a conversion from a pointer-to-struct ...
    (comp.lang.c)