This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: array semantic query
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: dharmendra pandit <pandit dot dharmendra at gmail dot com>
- Cc: Andrew Haley <aph at redhat dot com>, gcc at gcc dot gnu dot org, gcc-help at gcc dot gnu dot org
- Date: Sat, 18 Jul 2009 14:26:34 +0200
- Subject: Re: array semantic query
- References: <6215dcff0907180232l1c7291eclbc006cabd02224a4@mail.gmail.com> <6215dcff0907180235g7b4e6b7bl18f151db959a989d@mail.gmail.com> <4A61A230.9000703@redhat.com> <6215dcff0907180518k3ddf4908ub29b36acc24f91f@mail.gmail.com>
On Sat, Jul 18, 2009 at 2:18 PM, dharmendra
pandit<pandit.dharmendra@gmail.com> wrote:
> According to 6.3.2.1 Para 3, the type conversion from "array of type"
> to "pointer to type" should
> happen irrespective of whether the operand is on right had side or the
> left hand side of assignment
> operator. But GCC is converting only the right side operator type to
> "pointer of type" while retaining the
> left hand side type to be "array of type".
An array is never a valid lvalue in C. The error is slightly misleading.
Richard.
> -Dharmendra
>
> On Sat, Jul 18, 2009 at 3:51 PM, Andrew Haley<aph@redhat.com> wrote:
>> On 07/18/2009 10:35 AM, dharmendra pandit wrote:
>>> Hi,
>>>
>>> I tried the following simple code segment in gcc and it gave the
>>> incompatible type error as mentioned below.
>>>
>>> int main() {
>>> ? ? int arr[10];
>>> ? ? arr = arr; ? // error: incompatible types when assigning to type
>>> ‘int[10]’ from type ‘int *’
>>> }
>>>
>>> Here it seems GCC is retaining the left hand side type of arr to be
>>> array of 10 ints whereas on the right hand side
>>> it has changed its type from array to pointer to integer. I tried
>>> searching the relevant sections in the standard ISO C
>>> document number WG14/N1124 justifying the above behaviour of GCC but
>>> failed to conclude it from the specifications.
>>> It would be of great help if someone can point me out the relevant
>>> sections from the specs.
>>
>> 6.3.2.1 Para 3.
>>
>> I'm surprised you ask, since this convention has been used since early
>> K&R C.
>>
>> Andrew.
>>
>>
>