In article <SvIhHBAALcp4Ewwo@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <5h8p4.39434$ox5.10058265@tw11.nn.bcandid.com>, Will Darby
> <wdarby@acm.org> writes
> >I am perplexed by the warning that I receive from my compiler about
the
> >following piece of code:
> >
> >1: char a[4];
> >2: const char (*b)[] = &a;
>
> What is the type of b?  It seems to be a pointer to an array of const
> char.  But what kind of array?  Each size of array is distinct.
>
> Now let me look at the rhs.  What is the type of a?  Array of four
char.
> But by the rules this decays to a pointer to char and the & operator
> becomes redundant.  It does not matter how many &s you place in front
> the type will still be pointer to char if decay takes place or pointer
> to array of four chars if it does not.

I dont think so... &a is a pointer to array of 4 chars. It cannot decay
to anything. On the other hand "a" without the & is an array of 4 chars,
which is not compatible with pointer to array of 4 chars, but can decay
to a pointer to char (which is still not compatible with a pointer to an
array of 4 chars).

  char a[4];
  char (&b)[4] = a; // legal
  char (&b)[4] = &a; // illegal
  char (*c)[4] = a; // illegal
  char (*d)[4] = &a; // legal
  char *e = a; // legal
  char *f = &a; // illegal

The presence or absence of the & is crucial to the type of the rhs.

To answer the original question, I believe that "const char (*b)[4] =
&a;" (ie after inserting the 4) should be legal.

-------------
Mark Williams


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I am perplexed by the warning that I receive from my compiler about the
following piece of code:

1: char a[4];
2: const char (*b)[] = &a;

->  2: warning: initialization from incompatible pointer type

I read in the standard and FAQ about the issue converting T** to const T**,
but I could not find a specific account for the issue above. As it deals
with arrays, I believe the problems described in the FAQ are not applicable,
for example, translating the example from the FAQ:

1: const char     c = 'a';
2: char *p;
3: char (*pp)[] = &p;
4: const char (*ppc)[] = pp;
5: *ppc = &c;
6: *p = 'b';

Lines 3 and 5 are ill formed, which preserves the const safety.

Does the standard specifically address the case above?
Can someone provide an example of how type safety can be violated?

Thanks in advance.
Will Darby
wdarby@acm.org


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <5h8p4.39434$ox5.10058265@tw11.nn.bcandid.com>, Will Darby
<wdarby@acm.org> writes
>I am perplexed by the warning that I receive from my compiler about the
>following piece of code:
>
>1: char a[4];
>2: const char (*b)[] = &a;

What is the type of b?  It seems to be a pointer to an array of const
char.  But what kind of array?  Each size of array is distinct.

Now let me look at the rhs.  What is the type of a?  Array of four char.
But by the rules this decays to a pointer to char and the & operator
becomes redundant.  It does not matter how many &s you place in front
the type will still be pointer to char if decay takes place or pointer
to array of four chars if it does not.  Neither of these can match the
type of the lhs.

Now if you write

char const (*b)[4] = &a;

the analysis would be different and would depend on whether it is legal
to convert an array of four char to an array of four const char.

>
>->  2: warning: initialization from incompatible pointer type

Which I think is entirely correct.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]