Peter Flass wrote:
> Walter Bushell wrote:
>> In article <2...@eircom.net>,
>>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
>>
>>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
>>> Quadibloc <j...@ecn.ab.ca> wrote:
>>>
>>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net>
wrote:
>>>>
>>>>> Â  Â  Â  Â  No, he's saying that C doesn't really implement an 
>>>>> array type,
>>>>> the var[offset] syntax is just syntactic sugar for *(var + offset)
>>>>> which is why things like 3[x] work the same as x[3] in C.
>>>> Um, no.
>>>>
>>>> x = y + 3 ;
>>>>
>>>> in a C program will _not_ store in x the value of y plus the contents
>>>> of memory location 3.
>>>     No but x = *(y + 3) will store in x the contents of the memory
>>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>>> which is what I stated. You missed out the all important * and ()s.
>>
>> No, that will compare x and the right val.
>>
>> = is a comparasion operator in c.
>>
> 
> '=' is assignment, '==' is comparison.

I think there is *not* a single C programmer who has *not* had his 
hand slapped by making the mistake of using "=" when he meant 
"==". Thus the avalanche of replies...   :-)

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

In comp.arch.fpga Rick
<r...@gmail.com> wrote:
(snip)
 
> One of the other old processors from my stone knives and bear skin
> days was the RCA1802. It had IMHO a great feature for the calling
> subroutines. Anyone of the 16 general purpose registers could be made
> the program counter with a single instruction.

The OS/360 (and successor) calling mechanism isn't so different.

The BALR instruction branches to the address in a specified
register, while storing the address of the next instruction
in a register.  It is even allowed for both registers to be 
the same!  I have seen that used for coroutines, where an
appropriate BALR switches between routines using only one 
register to store the address in the other routine.

--glen

Quadibloc <j...@ecn.ab.ca> writes:
>
> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.

I don't have my copy handy, but I think it was documented that way back
in the original C language Bell Labs tech report.
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Charles Richmond <f...@tx.rr.com>
writes:

> Peter Flass wrote:
> > Walter Bushell wrote:
> >> In article <2...@eircom.net>,
> >>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
> >>
> >>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
> >>> Quadibloc <j...@ecn.ab.ca> wrote:
> >>>
> >>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net>
wrote:
> >>>>
> >>>>> Â  Â  Â  Â  No, he's saying that C doesn't really implement an 
> >>>>> array type,
> >>>>> the var[offset] syntax is just syntactic sugar for *(var +
offset)
> >>>>> which is why things like 3[x] work the same as x[3] in C.
> >>>> Um, no.
> >>>>
> >>>> x = y + 3 ;
> >>>>
> >>>> in a C program will _not_ store in x the value of y plus the
contents
> >>>> of memory location 3.
> >>>     No but x = *(y + 3) will store in x the contents of the memory
> >>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
> >>> which is what I stated. You missed out the all important * and ()s.
> >>
> >> No, that will compare x and the right val.
> >>
> >> = is a comparasion operator in c.
> >>
> > 
> > '=' is assignment, '==' is comparison.
> 
> I think there is *not* a single C programmer who has *not* had his 
> hand slapped by making the mistake of using "=" when he meant 
> "==". 

More than once...

-- Patrick

"Quadibloc" <j...@ecn.ab.ca> wrote in message 
news:9...@33g2000yqj.googlegroups.com...

> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.

> Evidently there is some discrepancy between C and FORTRAN.

Yes, it really does work as described, and was indeed documented
in the earliest C, and for that matter B and BCPL manuals.
C and Fortran are discrepant here.

  Dennis

Quadibloc schrieb:
> On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> #include <stdio.h>
>> int main()
>> {
>>     int a[4];
>>
>>     printf("a[2] at 0x%8x\n", &(a[2]));
>>     printf("2[a] at 0x%8x\n", &(2[a]));
>>     printf("(a+2) is 0x%8x\n", a+2);
>>     printf("(2+a) is 0x%8x\n", 2+a);
>>
>> }
>>
>> [pfeiffer@snowball ~/temp]# ./awry
>> a[2] at 0xbfff97b8
>> 2[a] at 0xbfff97b8
>> (a+2) is 0xbfff97b8
>> (2+a) is 0xbfff97b8
> 
> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.

You can think of the "a" in "a[4]" as a named numerical (integer)
constant (alias), giving the address of the memory block that was
allocated by the definition.

So there is no difference, between using that (named) constant or an
explicit numerical constant.

The only differences between:
   (1)   int a[4];
and:
   (2)   int * a = malloc( 4 * sizeof(int));
is the place where the memory is allocated and the value in (2) may be
changed later. (And the amount of typing, ofcourse!)

In both cases you can use "a[1]" or "*(a+1)" for access.

> Evidently there is some discrepancy between C and FORTRAN.
Only "a tiny bit"! ;-)

Grüße,
Uwe

On Sat, 06 Mar 2010 15:03:52 -0500
Walter Bushell <p...@panix.com> wrote:

> No, that will compare x and the right val.
> 
> = is a comparasion operator in c.

	Bzzzt wrong!

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <j...@ecn.ab.ca> wrote:

> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> 
> >         No but x = *(y + 3) will store in x the contents of the memory
> > location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
> > which is what I stated. You missed out the all important * and ()s.
> 
> Intentionally. My point was that, while there is _some_ truth to the
> claim that C arrays tread rather lightly on the ground of hardware
> addressing, the claim that C doesn't have arrays at all, and the C
> array subscript operator does nothing at all but add two addresses
> together... is not *quite* true.

	The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather important.
The validity of constructs like 2[a] and *(2+a) make this clear - as does
the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.

	C does have good support for pointers and adding integers to
pointers and for declaring blocks of storage with an array like syntax.

> If C doesn't have "real" arrays, it at least makes a rather good

	Arrays are not a real type in C if they were they would be passed
by value in function calls instead of being passed by reference and it
would be necessary to use a construct like &(a[0]) to pass the address of
the first element of the array instead of just a.

> attempt to simulate them. Unless one's standards are such that FORTRAN
> doesn't quite have "real" arrays either, and you need to go to Pascal
> for real arrays, there isn't that much to complain about in the case
> of C.

	I am not saying that the C arrays are not useful as they are, just
that they fall short of being a type in the sense that int, char, long,
pointer and struct are.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Quadibloc <j...@ecn.ab.ca> wrote:

> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.

	Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a]
is the same as a[2] is the same as *(a+2) and the rules for adding pointers
and integers are well defined in C. This is the heart of my original point,
array notation in C is syntactic sugar for pointer arithmetic (and also
for allocation which I neglected to mention in my original post).

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Ahem A Rivet's Shot <s...@eircom.net> writes:

> On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
> Quadibloc <j...@ecn.ab.ca> wrote:
>
>> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> 
>> >         No but x = *(y + 3) will store in x the contents of the memory
>> > location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>> > which is what I stated. You missed out the all important * and ()s.
>> 
>> Intentionally. My point was that, while there is _some_ truth to the
>> claim that C arrays tread rather lightly on the ground of hardware
>> addressing, the claim that C doesn't have arrays at all, and the C
>> array subscript operator does nothing at all but add two addresses
>> together... is not *quite* true.
>
> 	The C subscript operator does do nothing other than adding two
> numbers and dereferencing the result, that last action is rather important.
> The validity of constructs like 2[a] and *(2+a) make this clear - as does
> the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.

Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.

Gregm