Why C has Pointers.

[curixinfotech]

hi
my Q is on the c language tell me now why c has pointers.
parshant


--
curixinfotech
------------------------------------------------------------------------
curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319

[Malcolm McLean]

On Dec 7, 2:22 pm, curixinfotech <curixinfotech.54d...@no-

mx.forums.yourdomain.com.au> wrote:
> hi
> my Q is on the c language tell me now why c has pointers.
>

Writing to an address is a fundamental assembly-language operation.
The designers of C chose to make this transparent to the programmer.

There are many good reasons for designing a language without pointers.
C is not that language.
--
Malcolm's website
http://www.malcolmmclean.site11.com/www

[Eric Sosman]

On 12/7/2011 7:22 AM, curixinfotech wrote:
>
> my Q is on the c language tell me now why c has pointers.

To point at things, of course.

Do you ever use pronouns when you speak or write a natural
language? That is, do you ever refer to some person or thing
without using a name? Do you say "Parshant went to Rajiv's
birthday party, and Parshant gave Rajiv a gift along with best
wishes from Parshant's mother," or do you say "*I* went to
*his* birthday party, and *I* gave *him* a gift along with
best wishes from *my* mother"?

The analogy is far from perfect, but that, in a way, is
what pointers allow you to do: To write code that refers to
objects without using names. This means you can get the code
to do something with variable X, and then use the exact same
code to work with variable Y, and then use it again to work
with variable Z, all by writing the code to use "that variable
over there" and giving it a pointer to X this time, Y the next
time, and Z the time after that.

--
Eric Sosman
eso...@ieee-dot-org.invalid

[Mike Manilone]

In short, Dennis Ritchie thinks pointers can confuse you!


--
Best Regards,
Mike Manilone.

[Vincenzo Mercuri]

Il 07/12/2011 13:22, curixinfotech ha scritto:
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
>

Hi,

here is a short article that can give you a clue as to why and how:
http://duramecho.com/ComputerInformation/WhyCPointers.html

A similar question has been posted here some time ago, you may find
the answers very interesting. Here is my favourite one:

OP: "Why use pointers at all??"

Richard Heathfield: "No reason at all, if you don't want to.
So don't bother, until a need for them arises."

http://bytes.com/topic/c/answers/538974-why-pointers

--
Vincenzo Mercuri | www.backbox.org

[August Karlstrom]

On 2011-12-07 13:22, curixinfotech wrote:
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
>

All programs store and use references to different memory locations
(addresses). In a language like PHP for instance, these references are
mostly handled behind the scenes. In C we have precise control over
memory usage and the memory references are exposed to the programmer as
pointers.

The main reason for needing pointers is due to the fact that we cannot
store a new value between two adjacent memory locations; so if a data
structure (without a fixed capacity) needs to grow it has to do so in a
fragmented fashion or be relocated at a different place in memory. The
former approach makes its data scattered around in memory.


August

[Keith Thompson]

Vincenzo Mercuri <vincenzo...@hotmail.it> writes:
> Il 07/12/2011 13:22, curixinfotech ha scritto:
>> my Q is on the c language tell me now why c has pointers.
>

> here is a short article that can give you a clue as to why and how:
> http://duramecho.com/ComputerInformation/WhyCPointers.html

Do you know of another article that doesn't falsely claim that arrays
are pointers?

In C, an array variable is just a pointer to a chunk of memory
where the elements are stored in order

Arrays *are not* pointers. See section 6 of the comp.lang.c FAQ
<http://c-faq.com>.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Vincenzo Mercuri]

Keith Thompson ha scritto:

> Vincenzo Mercuri<vincenzo...@hotmail.it> writes:
>> Il 07/12/2011 13:22, curixinfotech ha scritto:
>>> my Q is on the c language tell me now why c has pointers.
>>
>> here is a short article that can give you a clue as to why and how:
>> http://duramecho.com/ComputerInformation/WhyCPointers.html
>
> Do you know of another article that doesn't falsely claim that arrays
> are pointers?
>
> In C, an array variable is just a pointer to a chunk of memory
> where the elements are stored in order
>

Good catch! I must have missed that part.

> Arrays *are not* pointers. [...]

Of course.

--
Vincenzo Mercuri | www.backbox.org

[Brian]

On Wed, 07 Dec 2011 11:01:04 -0800, Keith Thompson wrote:
> Vincenzo Mercuri <vincenzo...@hotmail.it> writes:
>> Il 07/12/2011 13:22, curixinfotech ha scritto:
>>> my Q is on the c language tell me now why c has pointers.
>>
>> here is a short article that can give you a clue as to why and how:
>> http://duramecho.com/ComputerInformation/WhyCPointers.html
>
> Do you know of another article that doesn't falsely claim that arrays
> are pointers?
>
> In C, an array variable is just a pointer to a chunk of memory where
> the elements are stored in order
>
> Arrays *are not* pointers. See section 6 of the comp.lang.c FAQ
> <http://c-faq.com>.

You are wrong about that, an array access like a[5] actually translates
into *(a+5) - pointer operation.

Cheers Brian

[James Kuyper]

On 12/07/2011 03:00 PM, Brian wrote:
> On Wed, 07 Dec 2011 11:01:04 -0800, Keith Thompson wrote:

...

>> Arrays *are not* pointers. See section 6 of the comp.lang.c FAQ
>> <http://c-faq.com>.
>
> You are wrong about that, an array access like a[5] actually translates
> into *(a+5) - pointer operation.

Did you bother following that link? Before asserting that arrays are
pointers, try comparing sizeof(a) with sizeof(&a[0]); if they happen to
be equal, double the length of the array, and try it again. Also, please
explain why the following does NOT work:

int a[10];
int **p = &a;

[88888 Dihedral]

How a multi-dimensional array in C is implemented? The pointer stores an
address. What a void pointer variable stores( just an address) and points to a value type which can be different in C.

[Kaz Kylheku]

On 2011-12-07, Vincenzo Mercuri <vincenzo...@hotmail.it> wrote:
> Il 07/12/2011 13:22, curixinfotech ha scritto:
>> hi
>> my Q is on the c language tell me now why c has pointers.
>> parshant
>>
>
> Hi,
>
> here is a short article that can give you a clue as to why and how:
> http://duramecho.com/ComputerInformation/WhyCPointers.html

This article claims to be about C, but then recommends the use of C++ features
new and delete instead of malloc and free.

I.e. this is about the C-like subset within C++ and not about C.

Also, it teaches the casting of the malloc return value. This is required
in C++, but not in C. It's not a bad idea in C, but you have to remember to
#include <stdlib.h> (not mentioned anywhere in the article), which you might
not unless your C compiler is configured to warn about the use of undeclared
functions. (Whenever possible, find out how to get this warning if it's not
there by default.) Without a prior declaration of malloc,
int *x = (int *) malloc(42) means "call the function int malloc(int)"
and not "call the function void *malloc(size_t)". The cast suppresses the
diagnostic about the int to (int *) conversion which would otherwise occur.

C++ does not permit calls to undeclared functions, and does not permit
conversions from void * without a cast: good features, but they are not present
in C.

[Vincenzo Mercuri]

Kaz Kylheku ha scritto:

> On 2011-12-07, Vincenzo Mercuri<vincenzo...@hotmail.it> wrote:
>> Il 07/12/2011 13:22, curixinfotech ha scritto:
>>> hi
>>> my Q is on the c language tell me now why c has pointers.
>>> parshant
>>>
>>
>> Hi,
>>
>> here is a short article that can give you a clue as to why and how:
>> http://duramecho.com/ComputerInformation/WhyCPointers.html
>
> This article claims to be about C, but then recommends the use of C++ features
> new and delete instead of malloc and free.
>
> I.e. this is about the C-like subset within C++ and not about C.

...

I believe I completely missed the point posting that link.
My intention was to give some useful hint to the OP
but I must recognize that the article turns out to be
a "dangerouse" reading for learners. My mistake, I was
supposed to read it carefully.

--
Vincenzo Mercuri | www.backbox.org

[Keith Thompson]

88888 Dihedral <dihedr...@googlemail.com> writes:
> On Thursday, December 8, 2011 4:30:58 AM UTC+8, James Kuyper wrote:
>> On 12/07/2011 03:00 PM, Brian wrote:
>> > On Wed, 07 Dec 2011 11:01:04 -0800, Keith Thompson wrote:
>> ...
>> >> Arrays *are not* pointers. See section 6 of the comp.lang.c FAQ
>> >> <http://c-faq.com>.
>> >
>> > You are wrong about that, an array access like a[5] actually translates
>> > into *(a+5) - pointer operation.
>>
>> Did you bother following that link? Before asserting that arrays are
>> pointers, try comparing sizeof(a) with sizeof(&a[0]); if they happen to
>> be equal, double the length of the array, and try it again. Also, please
>> explain why the following does NOT work:
>>
>> int a[10];
>> int **p = &a;
>
> How a multi-dimensional array in C is implemented?

[...]

A multi-dimensional array is simply an array of arrays.

There are data structure that behave like multidimensional arrays using
arrays of pointers. For example, you can have an array of double*
elements, where each element points to the first element of an array of
double. The syntax for accessing an element (a[x][y]) is similar, but
it's not a multidimensional array in the sense that the C standard uses
the term. Implementations using pointers are much more flexible, but
require more housekeeping work to allocate and deallocate memory.

Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, is an excellent
resource.

[Borax Man]

curixinfotech wrote:

> parshant
I can't believe how many people responded to this spam.

[Nick Keighley]

On Dec 7, 12:22 pm, curixinfotech <curixinfotech.54d...@no-

mx.forums.yourdomain.com.au> wrote:

> my Q is on the c language tell me now why c has pointers.

why not?

[Nick Keighley]

in what sense is it spam? Is it widely posted? Is it off-topic? Is it
cross posted? Has it been repeatedly posted? Does it originate from a
bank employee in Bukino Fasu?

[André Gillibert]

It's troll, not spam.

--
André Gillibert

[Bill Reid]

On Dec 7, 5:15 am, Mike Manilone <zht...@gmail.com> wrote:
> > > On 12/7/2011 7:22 AM, curixinfotech wrote:
>
> >> my Q is on the c language tell me now why c has pointers.
>

> In short, Dennis Ritchie thinks pointers can confuse you!
>

EXACTLY!!!

Also, it looks really cool and inscrutable the way you
can increment and dereference pointers, unlike the crystal
clear alternate method of array sub-scripting, which
winds up looking like something written in BASIC, for
cryin' out loud...

Sure, you could make a weak argument that you can
pass pointers around with a little more flexiblity,
but I'm sure the confusing coolness is what decided
the matter!

---
William Ernest Reid

[Vincenzo Mercuri]

Il 07/12/2011 21:30, James Kuyper ha scritto:
...
> ... Before asserting that arrays are

> pointers, try comparing sizeof(a) with sizeof(&a[0]); if they happen to

> be equal, double the length of the array, and try it again. ...

Okay:

#include <stdio.h>

int f(int a[])
{
return sizeof(a) == sizeof(&a[0]);
}

int main(void)
{
int a[3] = {10, 100, 1000};

printf("sizeof(a) == sizeof(&a[0]) is");

if (f(a))
puts(" true");
else
puts(" false");

return 0;
}

/* just kidding... :) */

--
Vincenzo Mercuri | www.backbox.org

[James Kuyper]

On 12/08/2011 01:39 PM, Vincenzo Mercuri wrote:
> Il 07/12/2011 21:30, James Kuyper ha scritto:
> ...
>> ... Before asserting that arrays are
>> pointers, try comparing sizeof(a) with sizeof(&a[0]); if they happen to
>> be equal, double the length of the array, and try it again. ...
>
> Okay:
>
> #include <stdio.h>
>
> int f(int a[])
> {
> return sizeof(a) == sizeof(&a[0]);
> }

...

> /* just kidding... :) */

For Brian's benefit, I'll point out that while, in this context, 'a' IS
a pointer, it's also NOT an array, appearances to the contrary
notwithstanding, so it doesn't provide support for his claims. I suspect
that those "appearances to the contrary" are part of the motivation for
such claims.

[Vincenzo Mercuri]

Indeed it doesn't absolutely provide support for his claims,
since an array is never passed to a function.

--
Vincenzo Mercuri | www.backbox.org

[Nick Keighley]

On Dec 8, 12:44 pm, André Gillibert <MetaEntropy.removeT...@gmail.com>
wrote:

> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> > > curixinfotech wrote:
> > > > parshant
>
> > > I can't believe how many people responded to this spam.
>
> > in what sense is it spam? Is it widely posted? Is it off-topic? Is it
> > cross posted? Has it been repeatedly posted? Does it originate from a
> > bank employee in Bukino Fasu?
>
> It's troll, not spam.

I'm not sure even that's true. he may genuinely wondering what
pointers are for. It smells like homework though.

[Kenny McCormack]

In article <68e27f18-0ad9-4309...@p16g2000yqd.googlegroups.com>,

I go with troll (and "good on him!").

The real truth to keep in mind here is that the obvious answer to the
question is: Because the inventors (and subsequent maintainers) of the
language put them in. I.e., the question is equivalent to "Why is the
background of the 'Mona Lisa' the color that it is?" It is that color
because the artist made it that way. That's really all there is to it.

The problem is that the question gets people's dander up - it incites them
to interpret the question as a criticism of the language. Now, maybe that
is really what the questioner has in mind, but the fact remains that "we"
shouldn't take the bait. We should just answer as above.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[Malcolm McLean]

On Dec 9, 4:59 pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>
> The problem is that the question gets people's dander up - it incites them
> to interpret the question as a criticism of the language.  Now, maybe that
> is really what the questioner has in mind, but the fact remains that "we"
> shouldn't take the bait.  We should just answer as above.
>

In the early days of C, you sometimes heard of programmers being told,
"You can program in C as long as you don't use pointers". That's
impractical, of course.

But pointers can cause terrible problems. Most languages hide them
from the programmer. C doesn't, and it's entirely legitimate to
discuss that design decision.
--
Basic Algorithms: how do JPEG files work?
http://www.malcommclean.site11.com/www

[Jorgen Grahn]

On Wed, 2011-12-07, Kaz Kylheku wrote:
> On 2011-12-07, Vincenzo Mercuri <vincenzo...@hotmail.it> wrote:
>> Il 07/12/2011 13:22, curixinfotech ha scritto:
>>> hi
>>> my Q is on the c language tell me now why c has pointers.
>>> parshant
>>>
>>
>> Hi,
>>
>> here is a short article that can give you a clue as to why and how:
>> http://duramecho.com/ComputerInformation/WhyCPointers.html
>
> This article claims to be about C, but then recommends the use of C++ features
> new and delete instead of malloc and free.
>
> I.e. this is about the C-like subset within C++ and not about C.

To C++'s defense, it's not about proper C++ either -- it's almost
never a good idea to use new/delete to manage arrays like he does in
his examples.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Nick Keighley]

On Dec 9, 2:59 pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <68e27f18-0ad9-4309-b9e4-8386f4904...@p16g2000yqd.googlegroups.com>,

> Nick Keighley  <nick_keighley_nos...@hotmail.com> wrote:
> >On Dec 8, 12:44 pm, André Gillibert <MetaEntropy.removeT...@gmail.com>
> >wrote:
> >> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >> > On Dec 8, 7:32 am, Borax Man <rotfl...@hotmail.com> wrote:
> >> > > curixinfotech wrote:
> >> > > > parshant


> >> > > I can't believe how many people responded to this spam.
>
> >> > in what sense is it spam? Is it widely posted? Is it off-topic? Is it
> >> > cross posted? Has it been repeatedly posted? Does it originate from a
> >> > bank employee in Bukino Fasu?
>
> >> It's troll, not spam.
>
> >I'm not sure even that's true. he may genuinely wondering what
> >pointers are for. It smells like homework though.
>
> I go with troll (and "good on him!").
>
> The real truth to keep in mind here is that the obvious answer to the
> question is: Because the inventors (and subsequent maintainers) of the
> language put them in.

not sure that's completly, or usefully, true. A programming languages
is designed (or intended to be) to be useful in expressing solutions
to certain classes of problem. I suspect Richie put some thought into
his pointers. He based them on BCPL but with subtle twists in both
syntax and semantics. In short I don't think C pointer are an
accident.

> I.e., the question is equivalent to "Why is the
> background of the 'Mona Lisa' the color that it is?"  It is that color
> because the artist made it that way.  That's really all there is to it.

again I suspect there were contraits on the colours Leonardo
considered. Magnolia or rainbow stripes were probably unlikely.

> The problem is that the question gets people's dander up - it incites them
> to interpret the question as a criticism of the language.  Now, maybe that
> is really what the questioner has in mind, but the fact remains that "we"
> shouldn't take the bait.  We should just answer as above.

I'm not the one saying the OP's a troll

[Cong Wang]

On 2011-12-07, curixinfotech <curixinfot...@no-mx.forums.yourdomain.com.au> wrote:
>
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
>
>

Because C is designed like this, to operate on memory.

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[88888 Dihedral]

On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> hi
> my Q is on the c language tell me now why c has pointers.
> parshant
>
>

> --
> curixinfotech
> ------------------------------------------------------------------------
> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319

OK, I'll explain how to use a pointer in C without any knowledge in the
hardware or assembly here.
//
int i;
int a[3]={ 1,2,3} ; // an array of 3 integers
int* ptr1; // Note the star should be right after int, not initialize
int* ptr2; // not initialized

ptr1=a; // Read this as to make ptr1 to be an alias of a.

for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
//This is a shadow copy.
ptr1[0]=6; ptr2[1]=6;
for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
// a[0]=? a[1]=?

//Deep copy is different.
ptr2=malloc(3*sizeof(int)); // get another array from the heap
// if (ptr2==NULL) then raise an error!!!
memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
ptr2[0]=-6; *(ptr+2)=-6;

for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

[Barry Schwarz]

On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
<dihedr...@googlemail.com> wrote:

>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>> hi
>> my Q is on the c language tell me now why c has pointers.
>> parshant
>>
>>
>> --
>> curixinfotech
>> ------------------------------------------------------------------------
>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
>
>OK, I'll explain how to use a pointer in C without any knowledge in the
>hardware or assembly here.
>//
>int i;
>int a[3]={ 1,2,3} ; // an array of 3 integers
>int* ptr1; // Note the star should be right after int, not initialize
>int* ptr2; // not initialized
>
>ptr1=a; // Read this as to make ptr1 to be an alias of a.

If that were true, the sizeof(a) and sizeof(ptr1) would be equal
which, in the general case, they are not. ptr1 is simply a pointer
that points to the start of a. Even though they share some
similarities in the language syntax, a pointer is a completely
different type than an array. Calling one an alias of the other just
breeds unnecessary confusion.

>
>for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
>for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
>//This is a shadow copy.
>ptr1[0]=6; ptr2[1]=6;

Since ptr2 was never initialized or assigned a value, the second
statement invokes undefined behavior. It is probably a typo and ptr1
was intended.

ptr1 points to a. There is no copy. a[0] and ptr1[0] refer to the
exact same object.

>for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
>// a[0]=? a[1]=?
>
>//Deep copy is different.
>ptr2=malloc(3*sizeof(int)); // get another array from the heap
>// if (ptr2==NULL) then raise an error!!!
>memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
>ptr2[0]=-6; *(ptr+2)=-6;

Since there is no variable ptr, this cannot compile. Was *(ptr2+2)
intended?

>
>for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
>for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
>for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

a[i] and ptr1[i] still point to the same object. ptr2 points to a
different area of memory which at one time had a copy of a but has
since been assigned at least one different value.

--
Remove del for email

[Skybuck Flying]

From what I have read and vaguely remember:

C was once designed to be a "value language" this can still be seen today as
C misses "call by reference" instead pointers need to be used.

Java attempted a similar idea but also failed and eventually
pointers/references were added to Java.

So just like Java the C language designer ultimately came to the conclusion
that C needs pointers too ! ;)

C# (sharp) attempted something like no pointers as well, ultimately it also
needed some kind of pointer...

Bye,
Skybuck :)

[Skybuck Flying]

So to completely answer your question.

Pointer support is a basic language requirement for any serious language as
data is stored in memory cells.

Without being able to address those memory cells, data could never be copied
from cell to cell, a requirement which most computer programs have.

There might be a way around pointers by introducing instructions which read
different memory cells, for example one above, one below or above and below
the current instruction or data item.

How usefull such an instruction set would be remains to be seen, it's
probably more an attempt at obfuscate logic then anything that can be taken
seriously ;) and also rather limited ;)

Might as well use pointers instead.

Bye,
Skybuck.

[Keith Thompson]

88888 Dihedral <dihedr...@googlemail.com> writes:
> On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>> my Q is on the c language tell me now why c has pointers.
>> parshant
>

> OK, I'll explain how to use a pointer in C without any knowledge in the
> hardware or assembly here.
> //
> int i;
> int a[3]={ 1,2,3} ; // an array of 3 integers
> int* ptr1; // Note the star should be right after int, not initialize

Why should the * be adjacent to "int"? My own preferred style (and, I
think, that of most C programmers) is:

int *ptr1;

The syntax of declarations in C follows (more or less) the syntax of
expressions; "declaration follows use". So "int *ptr;" says that *ptr
is an int -- from which it follows that ptr is a pointer to an int,
i.e., an int*.

This layout follows the grammar more closely, and makes an (admittedly
unwise) declaration like this:

int *pointer, not_a_pointer;

easier to understand.

But there is a school of thought that prefers to put the * next to the
type name. That seems to be the usual convention in C++. That's ok if
you avoid declaring multiple variables in one declaration (which you
should probably do anyway).

Note that the same principle might suggest:

int[3] arr;

which is of course a syntax error.

> int* ptr2; // not initialized
>
> ptr1=a; // Read this as to make ptr1 to be an alias of a.

That's not necessarily a good way to think of it. Since "a" is an array
object the expression consisting of its name decays to a pointer to its
first element. That pointer value is then stored in ptr1. ptr1 points
to the first element of a. To show that it's not a true alias, consider
sizeof a vs. sizeof ptr1.

> for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
> for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
> //This is a shadow copy.
> ptr1[0]=6; ptr2[1]=6;
> for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
> // a[0]=? a[1]=?
>
> //Deep copy is different.
> ptr2=malloc(3*sizeof(int)); // get another array from the heap
> // if (ptr2==NULL) then raise an error!!!
> memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy
> ptr2[0]=-6; *(ptr+2)=-6;
>
> for(i=0;i<3;i++) printf("The value of a[%d]=%d.\n", i, a[i]);
> for(i=0;i<3;i++) printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
> for(i=0;i<3;i++) printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

Read section 6 of the comp.lang.c FAQ, <http://c-faq.com>.

[ralph]

On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schw...@dqel.com>
wrote:

I agree.

I have trouble understanding the constant confusion between arrays and
pointers. Way back when (and we are talking many moons ago <g>) when I
started out in C my mentor explained it very simply in these terms in
the first couple of days.

1) There is a difference between declarations and definitions.
Remember which you are dealing with and when.
2) A pointer is a "variable", an array is a "constant"
3) The array name evaluates to the address of the first element in the
array.
4) A pointer is a variable that holds the address of another variable
or an array.
5) All pointers must be intialized before you use them.
6) Since an array name is an address it can be used as a pointer that
is initialized to point to the first element in the array.
7) *variable means the contents of the variable.
8) &variable means the address of the variable.
9) The array operator evaluates to a storage map equation, eg.
type ar[i] := *(a + (i * sizeof(type))
10) In all "pointer" operations you are either chewing on an address
or the contents (value) at that address. Simple deconstrution of the
even the most complex expression will quickly reveal which it is.

I've since learned how to restate the above in fancier terminology,
but those simple rules have stuck and served me well from my second
week in C to today - thirty plus years later.

-ralph

[ralph]

On Sat, 17 Dec 2011 14:28:14 -0600, ralph <nt_cons...@yahoo.net>
wrote:
I should probably amplify #1 ...

>
>1) There is a difference between declarations and definitions.
>Remember which you are dealing with and when.

1.5) C operators are overloaded to some extent and often a different
meaning in a declaration opposed to a definition or expression. For
example:
*v means the contents (value) of the variable pointed to by v in an
expression, but
char* v means declare a pointer that holds the address of a
variable that holds a char in a declaration.

...

-ralph

[Keith Thompson]

ralph <nt_cons...@yahoo.net> writes:
[...]

> I have trouble understanding the constant confusion between arrays and
> pointers. Way back when (and we are talking many moons ago <g>) when I
> started out in C my mentor explained it very simply in these terms in
> the first couple of days.
>
> 1) There is a difference between declarations and definitions.
> Remember which you are dealing with and when.
> 2) A pointer is a "variable", an array is a "constant"

That doesn't really make sense. An array variable is not a constant:

int arr[10];
arr[5] = 42;

I suppose what it means is that an array name, when it appears in an
expression (in most but not all context) decays to a pointer to the
array's first element, and that pointer value cannot be modified. But I
think that saying an array is a constant just reinforces the confusion
between arrays and pointers.

> 3) The array name evaluates to the address of the first element in the
> array.

This applies to any expression of array type, not just the name of a
declared array object. But it doesn't apply in all contexts.
Specifically, an expression of array type is converted to a pointer to
the array object's first element *unless* it's:

The operand of a unary "sizeof" operator (sizeof arr gives you the
same of the array, not of a pointer);

The operand of a unary "&" operator (&arr gives you the address of
the array object; it's the same memory location as the address of
its first element, but it's of a different type);

A string literal in an initializer used to initialize an array
object. In
char arr[6] = "hello";
the *value* of "hello" is copied into arr.

> 4) A pointer is a variable that holds the address of another variable
> or an array.

The distinction between variables an arrays is unnecessary. Variables
can be of any object type: integer, floating-point, struct, union,
array, pointer. There's nothing special about arrays in that particular
context.

An array object is an object whose value consists of the values of its
elements, just as a struct object is an object whose value consists of
the values of its members.

> 5) All pointers must be intialized before you use them.

The same applies to any object.

> 6) Since an array name is an address it can be used as a pointer that
> is initialized to point to the first element in the array.

In most contexts; see above. It would be clearer to say that an array
name *decays to* an address (or pointer value). And I wouldn't use the
word "initialized".

> 7) *variable means the contents of the variable.

No, it means the contents of the object to which "variable" points (and
is valid only if "variable" is of pointer type).

> 8) &variable means the address of the variable.
> 9) The array operator evaluates to a storage map equation, eg.
> type ar[i] := *(a + (i * sizeof(type))

I'm not sure what syntax you're using. What does "type" mean here? And
C pointer arithmetic is already scaled by the size of the pointed-to
type.

arr[i] is by definition equivalent to *(arr + i).

> 10) In all "pointer" operations you are either chewing on an address
> or the contents (value) at that address. Simple deconstrution of the
> even the most complex expression will quickly reveal which it is.
>
> I've since learned how to restate the above in fancier terminology,
> but those simple rules have stuck and served me well from my second
> week in C to today - thirty plus years later.

Section 6 of the comp.lang.c FAQ, <http://c-faq.com>, has an excellent
explanation of the relationship between arrays and pointers.

A digression: The rule that an array expression decays into a pointer to
the array object's first element leads to an interesting little hole in
the language. It assumes that there is an array *object* to which you
can point. This is usually the case, but not always. For example:

#include <stdio.h>

struct foo {
int arr[3];
};

struct foo func(void) {
struct foo result = { { 10, 20, 30 } };
return result;
}

int main(void) {
int *ptr = func().arr;
printf("*ptr = %d\n", *ptr);
return 0;
}

func() returns a *value* of type struct foo; it doesn't refer to any
object ("result" ceases to exist when the function returns). So we have
an array value, a member of the struct value returned by func(), that is
not the value of any array object.

C201X addresses this.

[88888 Dihedral]

On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:
> 88888 Dihedral <dihedr...@googlemail.com> writes:
> > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >
> > OK, I'll explain how to use a pointer in C without any knowledge in the
> > hardware or assembly here.
> > //
> > int i;
> > int a[3]={ 1,2,3} ; // an array of 3 integers
> > int* ptr1; // Note the star should be right after int, not initialize
>
> Why should the * be adjacent to "int"? My own preferred style (and, I
> think, that of most C programmers) is:
>
> int *ptr1;
>

int** (*methods[ ])() ;

How do you read this?

int* (*methods2[ ])() ;

int* (*methods3[ ])( int* (*functor)(), int* ) ;

methods, methods2, and methods3 are different arrays of functors.

It is easy to use functors to perform tricks in functional programming.

[88888 Dihedral]

*variable is easy to be miss-understood

*ptr_variable is different from ptr_variable

*variable if used for non-pointer variables, the compiler
will say something, thus you are right in the general sense in C,
but not clear enough for novices

[ralph]

On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <ks...@mib.org>
wrote:

>ralph <nt_cons...@yahoo.net> writes:
>[...]
>> I have trouble understanding the constant confusion between arrays and
>> pointers. Way back when (and we are talking many moons ago <g>) when I
>> started out in C my mentor explained it very simply in these terms in
>> the first couple of days.
>>
>> 1) There is a difference between declarations and definitions.
>> Remember which you are dealing with and when.
>> 2) A pointer is a "variable", an array is a "constant"
>
>That doesn't really make sense. An array variable is not a constant:
>
> int arr[10];
> arr[5] = 42;
>
>I suppose what it means is that an array name, when it appears in an
>expression (in most but not all context) decays to a pointer to the
>array's first element, and that pointer value cannot be modified. But I
>think that saying an array is a constant just reinforces the confusion
>between arrays and pointers.
>

I disagree.

Once the beginner gets it through his head that you can never do an
assignment to 'arr' you resolve a ton of the questions we get around
here. That as close to the definition of a "constant" as you can get.

-ralph

>> 3) The array name evaluates to the address of the first element in the
>> array.
>
>This applies to any expression of array type, not just the name of a
>declared array object. But it doesn't apply in all contexts.
>Specifically, an expression of array type is converted to a pointer to
>the array object's first element *unless* it's:
>
> The operand of a unary "sizeof" operator (sizeof arr gives you the
> same of the array, not of a pointer);
>
> The operand of a unary "&" operator (&arr gives you the address of
> the array object; it's the same memory location as the address of
> its first element, but it's of a different type);
>
> A string literal in an initializer used to initialize an array
> object. In
> char arr[6] = "hello";
> the *value* of "hello" is copied into arr.
>

Yep. But what's the big deal.

And of course I disagree that it actually matters to the beginner that
the address is of a "different type". Semantically and syntactically
it comes out the same. Plenty of time to get into vague language
later.

Actually in some implementations whether "hello" gets copied and when
if gets copied if it does depends on context. Again, why add
confusion?

[You can also create snippets that demonstrate that "hello" are
identical "constants" ...
"hello"[3]; \\ 'l'
arr[3]; \\ 'l'

>> 4) A pointer is a variable that holds the address of another variable
>> or an array.
>
>The distinction between variables an arrays is unnecessary. Variables
>can be of any object type: integer, floating-point, struct, union,
>array, pointer. There's nothing special about arrays in that particular
>context.
>
>An array object is an object whose value consists of the values of its
>elements, just as a struct object is an object whose value consists of
>the values of its members.
>
>> 5) All pointers must be intialized before you use them.
>
>The same applies to any object.
>
>> 6) Since an array name is an address it can be used as a pointer that
>> is initialized to point to the first element in the array.
>
>In most contexts; see above. It would be clearer to say that an array
>name *decays to* an address (or pointer value). And I wouldn't use the
>word "initialized".
>

I would. And again what does 'decay' meant to the beginner?
In code the name "arr" is changed to, or evaluates to, the address of
the first element.

>> 7) *variable means the contents of the variable.
>
>No, it means the contents of the object to which "variable" points (and
>is valid only if "variable" is of pointer type).
>
>> 8) &variable means the address of the variable.
>> 9) The array operator evaluates to a storage map equation, eg.
>> type ar[i] := *(a + (i * sizeof(type))
>
>I'm not sure what syntax you're using. What does "type" mean here? And
>C pointer arithmetic is already scaled by the size of the pointed-to
>type.
>
>arr[i] is by definition equivalent to *(arr + i).
>

Think about it.

You say that now, but you come back later in other response to point
out "sizes". That "already scaled" is because the compiler knows the
type, and he knows the type because you declared it.

[ralph]

On Sat, 17 Dec 2011 15:35:49 -0800 (PST), 88888 Dihedral

I disagree. (Naturally. <g>)

This ...

> *ptr_variable is different from ptr_variable

is all about context.

You only get an error or in trouble if you use *variable on a
NON-Address - whether constant or 'variable'.

I firmly believe, and several years of teaching C confirms for me,
that it is when ones starts straying from the simple that confusion is
introduced.

-ralph

[Ben Bacarisse]

ralph <nt_cons...@yahoo.net> writes:

> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>
>>ralph <nt_cons...@yahoo.net> writes:
>>[...]
>>> I have trouble understanding the constant confusion between arrays and
>>> pointers. Way back when (and we are talking many moons ago <g>) when I
>>> started out in C my mentor explained it very simply in these terms in
>>> the first couple of days.
>>>
>>> 1) There is a difference between declarations and definitions.
>>> Remember which you are dealing with and when.
>>> 2) A pointer is a "variable", an array is a "constant"
>>
>>That doesn't really make sense. An array variable is not a constant:
>>
>> int arr[10];
>> arr[5] = 42;
>>
>>I suppose what it means is that an array name, when it appears in an
>>expression (in most but not all context) decays to a pointer to the
>>array's first element, and that pointer value cannot be modified. But I
>>think that saying an array is a constant just reinforces the confusion
>>between arrays and pointers.
>>
>
> I disagree.
>
> Once the beginner gets it through his head that you can never do an
> assignment to 'arr' you resolve a ton of the questions we get around
> here. That as close to the definition of a "constant" as you can get.

I'd say that "unchanging" or "immutable" were closer definitions, and
arrays can be changed.

What you call a constant, I'd call a value, and I'd explain that
array-valued expressions are (usually) converted automatically to
pointer values.

Most people learning programming quickly get the idea of variables and
values. Variables can be assigned to, but values can't. This avoids
calling arrays "constant". It's also a start towards some more
technical matters such as why

int x;
x = 0;

is ok, but

(int)x = 0;

is not.

>>> 3) The array name evaluates to the address of the first element in the
>>> array.
>>
>>This applies to any expression of array type, not just the name of a
>>declared array object. But it doesn't apply in all contexts.
>>Specifically, an expression of array type is converted to a pointer to
>>the array object's first element *unless* it's:
>>
>> The operand of a unary "sizeof" operator (sizeof arr gives you the
>> same of the array, not of a pointer);
>>
>> The operand of a unary "&" operator (&arr gives you the address of
>> the array object; it's the same memory location as the address of
>> its first element, but it's of a different type);
>>
>> A string literal in an initializer used to initialize an array
>> object. In
>> char arr[6] = "hello";
>> the *value* of "hello" is copied into arr.
>>
>
> Yep. But what's the big deal.
>
> And of course I disagree that it actually matters to the beginner that
> the address is of a "different type". Semantically and syntactically
> it comes out the same. Plenty of time to get into vague language
> later.

I agree about putting this off, but 'arr' and '&arr' are not the same
semantically. If they were,

arr + 1

and

&arr + 1

would have the same value but they don't. (I'm using arr as defined
above.)

<snip>

>>In most contexts; see above. It would be clearer to say that an array
>>name *decays to* an address (or pointer value). And I wouldn't use the
>>word "initialized".
>
> I would. And again what does 'decay' meant to the beginner?
> In code the name "arr" is changed to, or evaluates to, the address of
> the first element.

I'd just say "converted". C has lots of automatic conversions and,
sooner or later, these need to be explains. The array to pointer
conversion fits into this general pattern.

<snip>

>>> 9) The array operator evaluates to a storage map equation, eg.
>>> type ar[i] := *(a + (i * sizeof(type))
>>
>>I'm not sure what syntax you're using. What does "type" mean here? And
>>C pointer arithmetic is already scaled by the size of the pointed-to
>>type.
>>
>>arr[i] is by definition equivalent to *(arr + i).
>
> Think about it.
>
> You say that now, but you come back later in other response to point
> out "sizes". That "already scaled" is because the compiler knows the
> type, and he knows the type because you declared it.

It's not easy to explain the lower-level arithmetic without reference to
some particular machine. For example, on a machine with, say, byte and
word addresses, you can't describe it as you have done. By all means,
take a simple architecture and explain what a[0] means on one particular
system using addresses and size calculations, but you will also have to
explain, eventually, that arr[i] is, by definition, *(arr + i).

<snip>
--
Ben.

[ralph]

Sure it is because it ain't *(arr + i). It is ...

*(arr + ( i * sizeof(datatype)))

So for int arr[10];
arr[5] is *(arr + (5 * sizeof(int)))
byte arr[10];
arr[5] is *(arr + (5 * sizeof(byte)))

You don't care what platform you are using because the sizeof takes
care of it. sizeof and size of datatypes are defined for each compiler
(which is platform specific by default). That's how pointer arithmetic
works. That's how the C language achieves platform independence and
compilers can be implemented for any specific architecture.

[88888 Dihedral]

In C there is no boundary checking in the index of an array in a read
or write operation to the array.

[Seebs]

On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> In C there is no boundary checking in the index of an array in a read
> or write operation to the array.

This is a vast oversimplification. It's undefined behavior to access
outside the object. Whether or not there is bounds checking is up to the
implementation; some real implementations have done it.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[88888 Dihedral]

On Sunday, December 18, 2011 12:56:07 PM UTC+8, Seebs wrote:
> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> > In C there is no boundary checking in the index of an array in a read
> > or write operation to the array.
>
> This is a vast oversimplification. It's undefined behavior to access
> outside the object. Whether or not there is bounds checking is up to the
> implementation; some real implementations have done it.
>
> -s
> --

In the language design C is easy to be mixed with assembly.

If one needs boundary checking of an array, other higher level programming
languages are better options.

[Seebs]

On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> In the language design C is easy to be mixed with assembly.

That, too, is an oversimplification.

> If one needs boundary checking of an array, other higher level programming
> languages are better options.

Could be, but the fact is, there are bounds-checking implementations. The
claim that there's no bounds-checking in C is not really generally true.

[Philip Lantz]

On Sat, 17 Dec 2011, ralph wrote:
> On Sun, 18 Dec 2011, Ben Bacarisse wrote:
>> ... arr[i] is, by definition, *(arr + i).
>>
>
> ... it ain't *(arr + i). It is ...

>
> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))
>
> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works. That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.

Ralph, could you do me a favor, please, and run the following program,
and let us know what its output is for you?


#include <stdio.h>

int main(void)
{
int arr[20] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11,12,13,14,15,16,17,18,19,20 };

printf("%d\n", arr[2]);
printf("%d\n", *(arr + (2 * sizeof(int))));
printf("%d\n", *(arr + 2));

return 0;
}


Thanks.

Philip

P.S. I get:
3
17
3

[superpollo]

Philip Lantz ha scritto:

i get:

3
9
3

bye

--
- La verdad amigo, es que en tu sangre, tienes mierda!
- Es posible, pero la mierda viva es mejor que la mierda muerta...
- Amigo... la mierda, siempre mierda es!!

[Ben Bacarisse]

ralph <nt_cons...@yahoo.net> writes:

> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>ralph <nt_cons...@yahoo.net> writes:
>>
>>> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <ks...@mib.org>

<snip>

>>>>arr[i] is by definition equivalent to *(arr + i).
>>>
>>> Think about it.
>>>
>>> You say that now, but you come back later in other response to point
>>> out "sizes". That "already scaled" is because the compiler knows the
>>> type, and he knows the type because you declared it.
>>
>>It's not easy to explain the lower-level arithmetic without reference to
>>some particular machine. For example, on a machine with, say, byte and
>>word addresses, you can't describe it as you have done. By all means,
>>take a simple architecture and explain what a[0] means on one particular
>>system using addresses and size calculations, but you will also have to
>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>
>
> Sure it is because it ain't *(arr + i). It is ...
>
> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

That's wrong, if what you are writing there are C expressions. arr[5]
is defined to be the same as *(arr + 5). Can you clear this up? Do you
agree that

arr[5] == *(arr + 5)

and

&arr[5] == arr + 5

are C expressions that always evaluate to 1? (Let's assume arr[5] has
been assigned some non-trap representation!)

You may be trying to explain arr[5] using a confusingly C-like
notation. If so, that's a very confusing thing to do. If I wanted to
explain what a compiler has to do, I'd use some entirely un-C-like
notation to avoid any possible misunderstanding.

> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works.

Not always. It's not sizeof that takes care of it, it's the compiler.
A C compiler must ensure that arr[i] and *(arr + i) have the same
meaning. To do that, it must do something with machine addresses that
involves the size of the array elements, but it's not always as simple
as you suggest. For example, I've used a machine where sizeof(int) is 2
but arr[5] (where arr is your int array from above) is implemented by
adding 5 (yes, 5, not 2*5) to the address of the array's first element.

> That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.

It's more subtle than that. The address arithmetic is related to the
size but it need not be exactly as you describe.

--
Ben.

[pete]

Ben Bacarisse is right.
ralph is wrong.

ISO/IEC 9899

6.5.2.1 Array subscripting

Semantics

2 The definition of the subscript operator []
is that E1[E2] is identical to (*((E1)+(E2))).

--
pete

[88888 Dihedral]

On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> > In the language design C is easy to be mixed with assembly.
>
> That, too, is an oversimplification.
>
> > If one needs boundary checking of an array, other higher level programming
> > languages are better options.
>
> Could be, but the fact is, there are bounds-checking implementations. The
> claim that there's no bounds-checking in C is not really generally true.
>
> -s

If there is any boundary checking on a machine,
what does that mean in the execution speed?

Happy programming?

[Robert Wessel]

Nothing or anything... Totally implementation dependent.

Nor does bounds checking have to be anything like exact. Consider
segments as used my large data model x86 16 bit protected mode
programs. Accessing just outside of an object may hit an adjacent
object, with the usual overwrite behavior, but far enough outside may
run off the segment boundary triggering a fault. As that's checked in
hardware, there's no direct performance penalty. Where segments have
high overhead in x86 is in changing the currently loaded set.

Alternatively, a limited form of bounds checking is implemented by
many C compilers that adds sentinels to critical items on the stack
(particularly the stack frame chain data and return address), but this
is only checked at selected times (for example at the return from a
function).

In environments where much of the bounds checking is done in software,
there has been a fair bit of work on techniques to minimize the cost,
and at least some of those techniques would be usable by a C compiler.

That being said, C's memory model makes bounds checking fairly simply
(if not necessarily efficient) for entire objects, but generally
checking for overflows between items within an object is much more
difficult.

[James Kuyper]

On 12/17/2011 11:34 PM, ralph wrote:
...

> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))

Other people have told you that this is wrong, and have cited the
relevant parts of the standard to prove it. If your compiler implements
a[i] as meaning anything other than *(a+i), it's not a conforming
implementation of C (or C++, or any of several other C-like languages).

However, a couple of casts would make it correct:

arr[5] == *(int*)((char*)arr + (5 * sizeof(int)));

When you understand precisely why the casts make a difference, you'll
have a much better understanding of C arrays and pointers than you
currently appear to have.

> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

You haven't provided a typedef for 'byte', but is seems likely, given
the name, that sizeof(byte) == 1. If that's true, than so is your
statement above. Otherwise, it's false.
--
James Kuyper

[88888 Dihedral]

Yes, you do know how C's pointer works.

It is just my personal style to separate the declaration of a pointer
and an assignment of a pointer by the RHS in another line clearly.

[88888 Dihedral]

It is simple in the math that the number of bits can represent is more powerful
when the number of bits grow with the implementation in the electronics industry.

Passing by an address of a fixed number of bits is more efficient than a deep
copy proved.

[Seebs]

On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> If there is any boundary checking on a machine,
> what does that mean in the execution speed?

This varies widely, from "you can't detect it" to "noticeable slowdown".

> Happy programming?

They exist because there's a market for them.

[Keith Thompson]

ralph <nt_cons...@yahoo.net> writes:
> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>
>>ralph <nt_cons...@yahoo.net> writes:
>>[...]
>>> I have trouble understanding the constant confusion between arrays and
>>> pointers. Way back when (and we are talking many moons ago <g>) when I
>>> started out in C my mentor explained it very simply in these terms in
>>> the first couple of days.
>>>
>>> 1) There is a difference between declarations and definitions.
>>> Remember which you are dealing with and when.
>>> 2) A pointer is a "variable", an array is a "constant"
>>
>>That doesn't really make sense. An array variable is not a constant:
>>
>> int arr[10];
>> arr[5] = 42;
>>
>>I suppose what it means is that an array name, when it appears in an
>>expression (in most but not all context) decays to a pointer to the
>>array's first element, and that pointer value cannot be modified. But I
>>think that saying an array is a constant just reinforces the confusion
>>between arrays and pointers.
>>
>
> I disagree.
>
> Once the beginner gets it through his head that you can never do an
> assignment to 'arr' you resolve a ton of the questions we get around
> here. That as close to the definition of a "constant" as you can get.

That's not what the word "constant" means, though. It's a bit closer to
what "const" means ("constant" and "const" are very different concepts
in C).

It's true that you can't assign to an array, and just saying that is
probably enough for a beginner. But eventually you're going to want to
understand *why* you can't assign to an array -- and the reason is that
the array name is converted to a pointer to the first element. That
pointer is a *value*, not an object/variable, and so you can't assign to
the pointer either, any more than you can do "42 = 43;".

>>> 3) The array name evaluates to the address of the first element in the
>>> array.
>>
>>This applies to any expression of array type, not just the name of a
>>declared array object. But it doesn't apply in all contexts.
>>Specifically, an expression of array type is converted to a pointer to
>>the array object's first element *unless* it's:
>>
>> The operand of a unary "sizeof" operator (sizeof arr gives you the
>> same of the array, not of a pointer);
>>
>> The operand of a unary "&" operator (&arr gives you the address of
>> the array object; it's the same memory location as the address of
>> its first element, but it's of a different type);
>>
>> A string literal in an initializer used to initialize an array
>> object. In
>> char arr[6] = "hello";
>> the *value* of "hello" is copied into arr.
>>
>
> Yep. But what's the big deal.

The big deal is that that's how the language works. And the big deal is
that it's important to understand that "sizeof arr" gives you the size
of the array itself. Your explanation that "The array name evaluates to
the address of the first element in the array" implies that "sizeof arr"
would yield the size of a pointer.

> And of course I disagree that it actually matters to the beginner that
> the address is of a "different type". Semantically and syntactically
> it comes out the same. Plenty of time to get into vague language
> later.

It *should* matter. The difference in type between a pointer to an int
and a pointer to an array of int might not be the first thing you need
to learn, but you certainly should learn it at some point.

> Actually in some implementations whether "hello" gets copied and when
> if gets copied if it does depends on context. Again, why add
> confusion?

I'm trying to add understanding. The underlying concepts are actually
fairly straightforward, but there are special-case rules involving
arrays and pointers (the decay of array expressions and the adjustment
of array parameters to pointer parameters) that, while convenient, cause
confusion. IMHO, trying to each arrays and pointers in terms of the way
those special-case rules make them *look*, plants the seeds of further
confusion down the line.

I've seen far too many people saying that arrays are "really" just
pointers.

[...]

>>> 6) Since an array name is an address it can be used as a pointer that
>>> is initialized to point to the first element in the array.
>>
>>In most contexts; see above. It would be clearer to say that an array
>>name *decays to* an address (or pointer value). And I wouldn't use the
>>word "initialized".
>>
>
> I would. And again what does 'decay' meant to the beginner?
> In code the name "arr" is changed to, or evaluates to, the address of
> the first element.

Ok, so don't use the word "decay". The standard doesn't; it describes
it as a conversion (and perhaps I should have as well). The term
"decay" is commonly used to describe the process, though.

[...]

>>> 9) The array operator evaluates to a storage map equation, eg.
>>> type ar[i] := *(a + (i * sizeof(type))
>>
>>I'm not sure what syntax you're using. What does "type" mean here? And
>>C pointer arithmetic is already scaled by the size of the pointed-to
>>type.
>>
>>arr[i] is by definition equivalent to *(arr + i).
>>
>
> Think about it.

I have, at great length.

Again, can you explain what you mean by "type"? The equation makes more
sense without it.

Most of your equation, apart from the ":=", is valid C syntax:

ar[i] := *(a + (i * sizeof(type))

which tends to imply that you're using the "+" operator as defined by C.
But in fact, you're using a "+" operator that adds a specified number of
*bytes* to a pointer value; that's not how C's "+" operator works.

It's certainly worth explaining that the addition is scaled by the size
of the pointed-to type, but using a C expression that doesn't have the
semantics you're assuming is not a good way to do it.

> You say that now, but you come back later in other response to point
> out "sizes". That "already scaled" is because the compiler knows the
> type, and he knows the type because you declared it.

I'm not aware that I've written anything that contradicts what I'm
saying here. If I have, please point it out.

[snip]

Incidentally, when posting a followup, please feel free to snip any
quoted material that you're not responding to.

[Keith Thompson]

ralph <nt_cons...@yahoo.net> writes:
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:

[...]

>>It's not easy to explain the lower-level arithmetic without reference to
>>some particular machine. For example, on a machine with, say, byte and
>>word addresses, you can't describe it as you have done. By all means,
>>take a simple architecture and explain what a[0] means on one particular
>>system using addresses and size calculations, but you will also have to
>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>
>
> Sure it is because it ain't *(arr + i). It is ...

Yes, it is. C99 6.5.2.1p2:

The definition of the subscript operator [] is that E1[E2] is
identical to (*((E1)+(E2))).

> *(arr + ( i * sizeof(datatype)))
>
> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))

You are using your own invented "+" operator that works in units of
byte, rather than the actual C "+" operator that works in units of the
size of the pointed-to type. That's fine, but only if you explicitly
state that "+" doesn't mean what it means in C.

[io_x]

"Keith Thompson" <ks...@mib.org> ha scritto nel messaggio
news:lnaa6p4...@nuthaus.mib.org...

> ralph <nt_cons...@yahoo.net> writes:
> Again, can you explain what you mean by "type"? The equation makes more
> sense without it.
>
> Most of your equation, apart from the ":=", is valid C syntax:
>
> ar[i] := *(a + (i * sizeof(type))
>
> which tends to imply that you're using the "+" operator as defined by C.
> But in fact, you're using a "+" operator that adds a specified number of
> *bytes* to a pointer value; that's not how C's "+" operator works.

type *a;

a[i] should be *((type*)((char*)a+(i*sizeof(type))) right?

[Nick Keighley]

On Dec 18, 7:05 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

Haiku?

[Nick Keighley]

On Dec 17, 6:19 pm, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:

> So to completely answer your question.
>
> Pointer support is a basic language requirement for any serious language as
> data is stored in memory cells.

nonsense. many "serious" langauges manage without pointers.

> Without being able to address those memory cells, data could never be copied
> from cell to cell, a requirement which most computer programs have.

nonsense. Any lanaguage that supports assignment can copy data from
one "cell" to another. No pointers necessary.

You are confusing language with implementation in a manner that throws
away 50 years of programming experience. Why not just progarm in
assembler if you want access to the underlying hardware?

> There might be a way around pointers by introducing instructions which read
> different memory cells, for example one above, one below or above and below
> the current instruction or data item.

go and look at a few other programming languages.

> How usefull such an instruction set would be remains to be seen, it's
> probably more an attempt at obfuscate logic then anything that can be taken
> seriously ;) and also rather limited ;)
>
> Might as well use pointers instead.

I don't understand why they got rid of plug boards. Any serious
computer needs a plugboard to specify the data paths.

[Nick Keighley]

On Dec 18, 4:08 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

the program runs slower

> Happy programming?

what makes you happier fast programs that crash or give wrong answers
or correct programs?

[John Bode]

On Saturday, December 17, 2011 2:28:14 PM UTC-6, ralph wrote:
> On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schw...@dqel.com>
> wrote:
>

> I have trouble understanding the constant confusion between arrays and
> pointers. Way back when (and we are talking many moons ago <g>) when I
> started out in C my mentor explained it very simply in these terms in
> the first couple of days.
>
> 1) There is a difference between declarations and definitions.
> Remember which you are dealing with and when.
> 2) A pointer is a "variable", an array is a "constant"

A pointer is a pointer, an array is an array. They are completely different animals with different behavior.

Array *expressions* may not be the target of an assignment, because the language definition says so. No need to invoke anything about "constants", which is annoyingly inaccurate.

> 3) The array name evaluates to the address of the first element in the
> array.

In most circumstances, an expression with type "N-element array of T" will be *replaced* with a pointer expression of type "pointer to T" that evaluates to the location of the first element in the array. The exceptions to this rule are when the array expression is an operand of either the sizeof or unary & operators, or when the array expression is a string literal that is being used to initialize another array in a declaration.

> 4) A pointer is a variable that holds the address of another variable
> or an array.
> 5) All pointers must be intialized before you use them.

> 6) Since an array name is an address it can be used as a pointer that
> is initialized to point to the first element in the array.

In most circumstances, an expression with type "N-element array of T" will be *replaced* with a pointer expression of type "pointer to T" that evaluates to the location of the first element in the array. The exceptions to this rule are when the array expression is an operand of either the sizeof or unary & operators, or when the array expression is a string literal that is being used to initialize another array in a declaration.

> 7) *variable means the contents of the variable.

> 8) &variable means the address of the variable.

> 9) The array operator evaluates to a storage map equation, eg.

> type ar[i] := *(a + (i * sizeof(type))

The subscript operation a[i] is *defined* as *(a + i); pointer arithmetic takes the type of the pointer into account, so you're always referring to the i'th *element* of the array.

> 10) In all "pointer" operations you are either chewing on an address
> or the contents (value) at that address. Simple deconstrution of the
> even the most complex expression will quickly reveal which it is.
>
> I've since learned how to restate the above in fancier terminology,
> but those simple rules have stuck and served me well from my second
> week in C to today - thirty plus years later.
>

> -ralph

Simple but imprecise. I've discovered over the last 20+ years that it's better to be precise at the expense of brevity if you want people to really understand how the C language behaves.

[88888 Dihedral]

On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:

In a virtual memory system of a descent OS,
there's no studpid checking in the ap level.

But if someone is writing AP in the real memory of some machine,
it is still no need to check in C in the release version by a professional
programmer.

[John Tsiombikas]

On 2011-12-19, 88888 Dihedral <dihedr...@googlemail.com> wrote:
>
> In a virtual memory system of a descent OS,
> there's no studpid checking in the ap level.

What is the ap level?
All virtual memory systems I'm aware of use page-level protection at
least. That is, invalid accesses to unmapped or protected pages are
trapped by the system and are used to either kill the application or
perform demand paging.

> But if someone is writing AP in the real memory of some machine,
> it is still no need to check in C in the release version by a professional
> programmer.

I don't see how writing code as a profession or as a hobby has anything
to do with this.

--
John Tsiombikas
http://nuclear.mutantstargoat.com/

[88888 Dihedral]

Writing code as a hobby is good toward a professional programmer.

Many engineers just write programs in the open source of sourceforge site
for fun.

[88888 Dihedral]

On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:

> 88888 Dihedral <dihedr...@googlemail.com> writes:
> > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >

> > OK, I'll explain how to use a pointer in C without any knowledge in the
> > hardware or assembly here.
> > //
> > int i;
> > int a[3]={ 1,2,3} ; // an array of 3 integers
> > int* ptr1; // Note the star should be right after int, not initialize
>

> Why should the * be adjacent to "int"? My own preferred style (and, I
> think, that of most C programmers) is:
>
> int *ptr1;
>
> The syntax of declarations in C follows (more or less) the syntax of
> expressions; "declaration follows use". So "int *ptr;" says that *ptr
> is an int -- from which it follows that ptr is a pointer to an int,
> i.e., an int*.
>
> This layout follows the grammar more closely, and makes an (admittedly
> unwise) declaration like this:
>
> int *pointer, not_a_pointer;
>
> easier to understand.
>
> But there is a school of thought that prefers to put the * next to the
> type name. That seems to be the usual convention in C++. That's ok if
> you avoid declaring multiple variables in one declaration (which you
> should probably do anyway).
>
> Note that the same principle might suggest:
>
> int[3] arr;
>
> which is of course a syntax error.

>
> > int* ptr2; // not initialized
> >
> > ptr1=a; // Read this as to make ptr1 to be an alias of a.
>

> That's not necessarily a good way to think of it. Since "a" is an array
> object the expression consisting of its name decays to a pointer to its
> first element. That pointer value is then stored in ptr1. ptr1 points
> to the first element of a. To show that it's not a true alias, consider
> sizeof a vs. sizeof ptr1.

I do not allocate arrays in the auto mode very often in C.
But for an example, I just have to show the silly array allocated in the
auto mode.

Normally I allocate a buffer from the heap by malloc.
Also I wrote functions that could return pointers and have to clean up
local buffers correctly before exiting the function.

[88888 Dihedral]

On Tuesday, December 20, 2011 6:10:24 AM UTC+8, 88888 Dihedral wrote:
> On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:

Also there's no need to free arrays on the stack of auto variables.
One just has to clean those buffers from the heap exactly without errors.

[Gordon Burditt]

>> Could be, but the fact is, there are bounds-checking implementations. The
>> claim that there's no bounds-checking in C is not really generally true.

Most any machine capable of generating a SIGSEGV has at least a
form of very loose bounds checking, with the checking done in
hardware. It may not always trigger if you go a *little* out of
bounds, but often will if you go *way* out of bounds. It's sort
of like GPS that warns you most of the time if you're on the wrong
continent.

> If there is any boundary checking on a machine,
> what does that mean in the execution speed?

Since the OS generally uses the same mechanism to prevent processes
from clobbering each other, and it won't let you turn it off unless
perhaps you install your code as a driver, there is no alternative
so you can't measure it.

[ralph]

On Sun, 18 Dec 2011 13:10:27 -0800, Keith Thompson <ks...@mib.org>
wrote:

>ralph <nt_cons...@yahoo.net> writes:
>> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
>> <ben.u...@bsb.me.uk> wrote:
>[...]
>>>It's not easy to explain the lower-level arithmetic without reference to
>>>some particular machine. For example, on a machine with, say, byte and
>>>word addresses, you can't describe it as you have done. By all means,
>>>take a simple architecture and explain what a[0] means on one particular
>>>system using addresses and size calculations, but you will also have to
>>>explain, eventually, that arr[i] is, by definition, *(arr + i).
>>>
>>
>> Sure it is because it ain't *(arr + i). It is ...
>
>Yes, it is. C99 6.5.2.1p2:
>
> The definition of the subscript operator [] is that E1[E2] is
> identical to (*((E1)+(E2))).
>
>> *(arr + ( i * sizeof(datatype)))
>>
>> So for int arr[10];
>> arr[5] is *(arr + (5 * sizeof(int)))
>> byte arr[10];
>> arr[5] is *(arr + (5 * sizeof(byte)))
>
>You are using your own invented "+" operator that works in units of
>byte, rather than the actual C "+" operator that works in units of the
>size of the pointed-to type. That's fine, but only if you explicitly
>state that "+" doesn't mean what it means in C.

[So an 'actual' unit of "size of the pointed-to-type" doesn't have the
same meaning as an 'invented' unit of "sizeof(<declared>type))". If
you look closer you will will see there is not a single pointer in my
statement nor in the Standard - there ain't NO "pointed-to-type" and
that is the whole point. <bg>]

Sry delay. The holidays...

This reply will have to serve for all of you. <g>

When I mentioned this phenomena as an aid for new programmers, I used
the term "storage map equation" which I assumed everyone understood as
an implementation context. My post that prompted this response was
made quickly because I seriously thought Ben was teasing me. Bad
assumption. You guys are serious.

Well that is pretty much what you get when you assume. lol

The concepts behind ...

datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))

... and understanding the difference between addresses and pointer
datatypes has served to untangle a ton of "pointer" questions. But
that's me, and my students, and it doesn't matter. ...

IF one is pitching something, and no one is catching, especially those
one definitely respects and believes to be quite competent (and not
assumed <g>) there is something fishy with the pitch. So I yield.
Consider item #9 deleted from my list.

Happy Holidays and Best Wishes for a Great New Year.

-ralph

[Barry Schwarz]

On Tue, 27 Dec 2011 16:03:35 -0600, ralph <nt_cons...@yahoo.net>
wrote:

snip

>[So an 'actual' unit of "size of the pointed-to-type" doesn't have the
>same meaning as an 'invented' unit of "sizeof(<declared>type))". If
>you look closer you will will see there is not a single pointer in my
>statement nor in the Standard - there ain't NO "pointed-to-type" and
>that is the whole point. <bg>]

A wonderfully absurd assertion since there are at least two sections
of the standard devoted to pointers (6.3.2.3 and 6.7.5.1) and the term
appears in more than a dozen other sections.

>
>Sry delay. The holidays...
>
>This reply will have to serve for all of you. <g>
>
>When I mentioned this phenomena as an aid for new programmers, I used
>the term "storage map equation" which I assumed everyone understood as
>an implementation context. My post that prompted this response was
>made quickly because I seriously thought Ben was teasing me. Bad
>assumption. You guys are serious.
>
>Well that is pretty much what you get when you assume. lol
>
>The concepts behind ...
>
> datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))

So your readers need only remember whether you are using or own
meaning for the symbols or the common meaning stated in the standard.
And of course you used a syntax nearly identical to C to help make
this unequivocally clear.

--
Remove del for email

[Keith Thompson]

I don't understand what you mean by that statement. The difference
I was pointing out was between your invented "+" operator, which
apparently operates in units of single bytes (thus the need to
explicitly scale it by sizeof(datatype)), vs. the actual C "+"
operator, which operates in terms of the size of the pointed-to type
(so explicit scaling would yield an incorrect result).

> If
> you look closer you will will see there is not a single pointer in my
> statement nor in the Standard - there ain't NO "pointed-to-type" and
> that is the whole point. <bg>]

"arr" is an expression of array type. In this context, it's implicitly
converted to a pointer to the array's first element. That's one pointer
right there.

When you add an integer value to a pointer, the result is another
pointer.

The pointed-to type is the element type of "arr", which you refer to as
"datatype".

The expression is a syntactically valid C expression. It uses
parentheses, names which presumably refer to C objects and type,
the unary and binary "*" operator, the "+" operator, and the
"sizeof" operator. It would be unreasonable, particularly in the
context of this newsgroup or a C class, to assume that it's *not*
intended to be a C expression with C semantics.

> Sry delay. The holidays...
>
> This reply will have to serve for all of you. <g>
>
> When I mentioned this phenomena as an aid for new programmers, I used
> the term "storage map equation" which I assumed everyone understood as
> an implementation context. My post that prompted this response was
> made quickly because I seriously thought Ben was teasing me. Bad
> assumption. You guys are serious.
>
> Well that is pretty much what you get when you assume. lol
>
> The concepts behind ...
>
> datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))
>
> ... and understanding the difference between addresses and pointer
> datatypes has served to untangle a ton of "pointer" questions. But
> that's me, and my students, and it doesn't matter. ...

The equation as you wrote it is probably easily understandable
*for someone who doesn't know how C pointer arithmetic works*.
That's what I find dangerous about it. If you teach this before
you teach C pointer arithmetic, a student who goes back and looks
at this equation is likely to be confused, and/or may misunderstand
the actual rules for C pointer arithmetic when encountering them.

It's possible to express the concept you're presenting (which is
a perfectly valid concept) without violating or ignoring C rules.
You can do in pure C by adding casts to and from char*, but that's
probably too confusing. Or perhaps you could define and use your
own special-purpose operators that don't look exactly like C's "+",
or you could describe it in English.

I'd actually be interested in seeing a good novice-friendly way of
doing that.

> IF one is pitching something, and no one is catching, especially those
> one definitely respects and believes to be quite competent (and not
> assumed <g>) there is something fishy with the pitch. So I yield.
> Consider item #9 deleted from my list.

I get the impression that you're yielding on this point because of the
number of people who disagree with you. I'd prefer to think that you
understand the argument we're making. (If you change your mind, we'll
*all* be right!)

Or maybe I'm just beating a dead horse.

> Happy Holidays and Best Wishes for a Great New Year.

Likewise.

[James Kuyper]

I can't tell whether those things have the same meaning, because I don't
know what you mean by those terms. In C, when adding an integer (like
5*sizeof(int)) to a pointer to some type (like arr), the integer is
interpreted as counting units of the pointed-at type. Therefore on an
implementation where sizeof(int) is 2, then the expression arr+10 will
point at the 11th 'int' in arr, which in this case is one past the end
of the array.

> ... If

> you look closer you will will see there is not a single pointer in my
> statement nor in the Standard - there ain't NO "pointed-to-type" and
> that is the whole point. <bg>]

There's lots of pointers in the Standard - it's just plain nonsense to
claim otherwise. I'm going to assume that you meant something else. My
best guess is that you meant "there is not a single pointer in my
statement as interpreted in accordance with the Standard". Please let me
know if that guess is incorrect.

Item 9 in your response to Barry Schwartz on 2011-12-17 used := as if it
were an operator. Therefore, it was pretty clear that you weren't using
C syntax, even if it wasn't clear what the syntax you were using was
supposed to mean. If you say that your statement doesn't contain any
pointers, I'll have to defer to your superior knowledge of the syntax
you were using.

However, in later messages you used or talked about the expressions
arr[i], and *(arr+i), and *(arr+5*sizeof(int)). These look exactly like
normal C expressions. In a message posted to a newsgroup devoted to C,
we're entitled to assume that they carry their normal C meaning.

According to that standard, "an expression that has type ‘‘array of
type’’ is converted to an expression with type ‘‘pointer to type’’ that
points to the initial element of the array object" (6.3.2.1p3). There
are exceptions to that rule, but none of the exceptions apply in any of
these three expressions. In all three of them, "arr" is an expression
that has the type "array of int", so there most definitely is a pointer
to int in each of those expressions, and also a pointed-to type: "int".

> When I mentioned this phenomena as an aid for new programmers, I used
> the term "storage map equation" which I assumed everyone understood as
> an implementation context.

I've never heard the term "storage map equation" before. My personal
guess was that your statement that

arr[5] is *(arr + (5 * sizeof(int)))

(which is false according to C syntax and semantics on any
implementation where sizeof(int)>1) corresponds the statement

arr[5] is *(int*)((char*)arr + 5*sizeof(char))

(which is guaranteed to be true on all implementations according to C
syntax and semantics). In a newsgroup associated with the C programming
language, it would have saved a lot of trouble if you'd actually written
it that way.

> The concepts behind ...
>
> datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))

Your use of '~==' as if it were an operator again clarifies that you're
not using C syntax and semantics. If you insist on using your own
made-up syntax, you should provide an explanation of what it means. This
statement looks very similar to an earlier one, except that "~=="
replaces ":=". What is the significance of that change?

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
[...]

> I've never heard the term "storage map equation" before. My personal
> guess was that your statement that
>
> arr[5] is *(arr + (5 * sizeof(int)))
>
> (which is false according to C syntax and semantics on any
> implementation where sizeof(int)>1) corresponds the statement
>
> arr[5] is *(int*)((char*)arr + 5*sizeof(char))

I think you mean:

arr[5] is *(int*)((char*)arr + 5*sizeof(int))

> (which is guaranteed to be true on all implementations according to C
> syntax and semantics). In a newsgroup associated with the C programming
> language, it would have saved a lot of trouble if you'd actually written
> it that way.

[...]

[James Kuyper]

On 12/27/2011 06:36 PM, Keith Thompson wrote:
> James Kuyper <james...@verizon.net> writes:
> [...]
>> I've never heard the term "storage map equation" before. My personal
>> guess was that your statement that
>>
>> arr[5] is *(arr + (5 * sizeof(int)))
>>
>> (which is false according to C syntax and semantics on any
>> implementation where sizeof(int)>1) corresponds the statement
>>
>> arr[5] is *(int*)((char*)arr + 5*sizeof(char))
>
> I think you mean:
>
> arr[5] is *(int*)((char*)arr + 5*sizeof(int))

You're right. My message went through MANY revisions. At one point it
referred to his use of sizeof(byte), which I translated as sizeof(char).
Later I changed it to refer to sizeof(int), but didn't carry through the
conversion completely. Sorry!

[ralph]

On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <ks...@mib.org>
wrote:


>

>I get the impression that you're yielding on this point because of the
>number of people who disagree with you. I'd prefer to think that you
>understand the argument we're making. (If you change your mind, we'll
>*all* be right!)
>
>Or maybe I'm just beating a dead horse.
>

For the moment yes, that is exactly what I'm (we're) doing. ha

I think I understand what you are trying to say, at least recognize
the "C-Legalese", but unable to distinguish the subtleties in
difference between what I'm saying and what you guys are saying.

[I mean, (among other things), as long as anyone refers to the "arr"
in an array declaration as a "pointer" when it is obviously a literal
constant - I'm likely to stay confused.]

I've always had trouble understanding code lawyers. C for me has been
mostly pragmatic, visual (yeah, I like to draw little memory boxes,
data sections, registers, and arrows <g>), and intuitive over the last
30 years. I know that we aren't that fundamentally different - since
we both likely write the same code. We just use different words to
describe what we wrote.

Well, I done just about everything else in C , have some time on my
hands, so perhaps it is time to really read the standard. That will
likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
that "arr" will turn into a pointer.

-ralph

[Keith Thompson]

ralph <nt_cons...@yahoo.net> writes:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>>I get the impression that you're yielding on this point because of the
>>number of people who disagree with you. I'd prefer to think that you
>>understand the argument we're making. (If you change your mind, we'll
>>*all* be right!)
>>
>>Or maybe I'm just beating a dead horse.
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.

In the particular case we're talking about, the difference is that
you're using a kind of pointer arithmetic that quite simply is not the
way pointer arithmetic works in C. Do you not understand that?

> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

Can you show a concrete example of C code that illustrates what you're
referring to here? There are a number of things that

the "arr" in an array declaration

could mean, and I honestly have no idea which one you're talking about.

> I've always had trouble understanding code lawyers. C for me has been
> mostly pragmatic, visual (yeah, I like to draw little memory boxes,
> data sections, registers, and arrows <g>), and intuitive over the last
> 30 years. I know that we aren't that fundamentally different - since
> we both likely write the same code. We just use different words to
> describe what we wrote.
>
> Well, I done just about everything else in C , have some time on my
> hands, so perhaps it is time to really read the standard. That will
> likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
> that "arr" will turn into a pointer.

I suggest reading section 6 of the comp.lang.c FAQ, <http://c-faq.com>.
It has the best explanation I've seen of the relationship between arrays
and pointers in C.

[Nick Keighley]

On Dec 19, 9:47 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

not if they take a "this is only a hobby so quality doesn't matter"
attitude. Pretty soon hobby attitudes leak through to professional
programs. What sort of hobby is it where you don't care?

> Many engineers just write programs in the open source of sourceforge site
> for fun.

and they write shit?

[88888 Dihedral]

Nick Keighley於 2011年12月28日星期三UTC+8下午6時58分40秒寫道：
> On Dec 19, 9:47 pm, 88888 Dihedral <dihedr...@googlemail.com>

> wrote:
> > On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:

> > > On 2011-12-19, 88888 Dihedral <dihe...@googlemail.com> wrote:
> >
> > > > In a virtual memory system of a descent OS,
> > > > there's no studpid checking in the ap level.
> >
> > > What is the ap level?
> > > All virtual memory systems I'm aware of use page-level protection at
> > > least. That is, invalid accesses to unmapped or protected pages are
> > > trapped by the system and are used to either kill the application or
> > > perform demand paging.
> >
> > > > But if someone is writing AP in the real memory of some machine,
> > > > it is still no need to check in C in the release version by a professional
> > > > programmer.
> >
> > > I don't see how writing code as a profession or as a hobby has anything
> > > to do with this.
> >
> > Writing code as a hobby is good toward a professional programmer.
>
> not if they take a "this is only a hobby so quality doesn't matter"
> attitude. Pretty soon hobby attitudes leak through to professional
> programs. What sort of hobby is it where you don't care?
>
> > Many engineers just write programs in the open source of sourceforge site
> > for fun.
>
> and they write shit?

Not really at all, some are experiments and some are excellent.

Nowadays programmers can sharpen their programming skills very fast in the
open source projects. I remembered in the old days of workstations and mainframes. One had to pay service fees for those vendors of trivial settings
from time to time after installing new software packages that conflicted
some packages installed.

[Nick Keighley]

On Dec 28, 2:09 am, ralph <nt_consultin...@yahoo.net> wrote:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <ks...@mib.org>

I think in your "equation" you're using '+' in the normal arithmetic
meaning. Which I don't think is a completly bad idea. But you *must*
be clear that normal arithmatic is *not* the same as C pointer
arithmatic.

> >I get the impression that you're yielding on this point because of the
> >number of people who disagree with you.  I'd prefer to think that you
> >understand the argument we're making.  (If you change your mind, we'll
> >*all* be right!)
>
> >Or maybe I'm just beating a dead horse.
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.
>
> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

it isn't a pointer, constant or otherwise. I personnally find these
sort of "explanations" confusing. I have similar problems when people
tell me C++ references are "constant pointers".

> I've always had trouble understanding code lawyers.

programming languages (usually) have formal definitions. To an extent
this depends how people think. I tend to prefer more formal
explanations, leavened with some solid concrete examples. I need to
see some sort of implementaion at some point, but once I've seen an
implementaion I don't need to have it there all the time. I have known
people who seemed to mentally translate everything into assembler. (or
worse! "it's all shift registers!"). I think it's better to ride a
little higher in the abstraction layers. But horses for courses.

> C for me has been
> mostly pragmatic, visual (yeah, I like to draw little memory boxes,
> data sections, registers, and arrows <g>),

I'd skip the data sections and registers. Way too chummy with the
implementation! I bet if you did Pascal you'd love those little
railway track diagrams that were fashionable to describe syntax.

> and intuitive over the last
> 30 years. I know that we aren't that fundamentally different - since
> we both likely write the same code. We just use different words to
> describe what we wrote.

I'm not so sure.

> Well, I done just about everything else in C , have some time on my
> hands, so perhaps it is time to really read the standard. That will
> likely take a few days. (ok a few weeks, ... months? <g>) Then maybe
> that "arr" will turn into a pointer.

days to read it. Much longer to understand. It's a formal document and
heavily cross-linked. There is little hand-holding. If the standard
says something it rarely says it twice. If you've read K&R you'll have
a flavour of the formallity. Expect the standard to be a step-up.

On the other hand the C standard is quite reasonable as these things
go. Do read the definitions near the beginning carefully. If you can
lay your hands on the Rationale for the ANSI 89 standard it give some
justifications for the decisions made and again is quite a good read.

[Ben Bacarisse]

ralph <nt_cons...@yahoo.net> writes:
<snip>

> The concepts behind ...
>
> datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))
>
> ... and understanding the difference between addresses and pointer
> datatypes has served to untangle a ton of "pointer" questions. But
> that's me, and my students, and it doesn't matter. ...

That suggests you've only had to untangle such questions in relatively
simple situations. As I pointed out before, i*sizeof(datatype) is
sometimes the wrong thing to add to the address. But you can explain
all of this without leaving the world of C's pointers:

arr[i] is *(arr + i)

which means (at a lower level)

(int *)((char *)arr + i * sizeof *arr)

As soon as you try to move beyond C's abstract pointers you need to
start talking about machine addresses and these can be more subtle than
your equation assumes them to be.

<snip>
--
Ben.

[James Kuyper]

On 12/27/2011 09:09 PM, ralph wrote:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>
>
>>
>> I get the impression that you're yielding on this point because of the
>> number of people who disagree with you. I'd prefer to think that you
>> understand the argument we're making. (If you change your mind, we'll
>> *all* be right!)
>>
>> Or maybe I'm just beating a dead horse.
>>
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.

It's not C legalese, and it's not subtle. It's a fundamental point about
how C pointer arithmetic works that must be properly understood by any C
programmer before he's competent to write any serious code.

> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

It's not a pointer in the declaration that we're talking about. However,
in most expressions involving the name of an array, it's name is
automatically converted to a pointer to the first element of the array.
--
James Kuyper

[John Bode]

On Saturday, December 17, 2011 10:34:20 PM UTC-6, ralph wrote:
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>

[snip]

> >
> >It's not easy to explain the lower-level arithmetic without reference to
> >some particular machine. For example, on a machine with, say, byte and
> >word addresses, you can't describe it as you have done. By all means,
> >take a simple architecture and explain what a[0] means on one particular
> >system using addresses and size calculations, but you will also have to
> >explain, eventually, that arr[i] is, by definition, *(arr + i).
> >
>
> Sure it is because it ain't *(arr + i). It is ...
>

> *(arr + ( i * sizeof(datatype)))
>

I suggest you try that with some real code:

int a[] = {0,1,2,3,4,5};
printf("a[1] = %d, *(a + 1) = %d, *(a + 1 * sizeof *a) = %d\n",
a[1], *(a + 1), *(a + 1 * sizeof *a));

*(a + i * sizeof *a) != a[i]

Pointer arithmetic is defined in terms of the size of the pointed-to type; For any object of type pointer to T, the expression *(p + i) yields the value of the i'th *element* of type T after p, not the i'th *byte*.

> So for int arr[10];

> arr[5] is *(arr + (5 * sizeof(int)))

> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))
>

Again, I suggest you write some code to test that assertion.

> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works. That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.


*EXACTLY*. You don't have to worry about the size of the data type, so you don't have to think in terms of *byte offsets*. You simply think in terms of *elements*.

[88888 Dihedral]

Barry Schwarz於 2011年12月18日星期日UTC+8上午2時10分09秒寫道：

> On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> <dihedr...@googlemail.com> wrote:
>
> >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:

> >> hi

> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >>
> >>

> >> --
> >> curixinfotech
> >> ------------------------------------------------------------------------
> >> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> >> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
> >

> >OK, I'll explain how to use a pointer in C without any knowledge in the
> >hardware or assembly here.
> >//
> >int i;
> >int a[3]={ 1,2,3} ; // an array of 3 integers
> >int* ptr1; // Note the star should be right after int, not initialize

> >int* ptr2; // not initialized
> >
> >ptr1=a; // Read this as to make ptr1 to be an alias of a.
>

> If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

Why do you care about the size of an array declared on the stack?

Everything on the stack is to be popped out in the exit of a function in C.

But a pointer allocated in the heap is different.

> which, in the general case, they are not. ptr1 is simply a pointer
> that points to the start of a. Even though they share some
> similarities in the language syntax, a pointer is a completely
> different type than an array. Calling one an alias of the other just
> breeds unnecessary confusion.

A pointer defines an alias to a variable. Don't you get it in C or assembly?

[Nick Keighley]

for some reason "Dihedral" has revived this ancient topic

On Jan 9, 11:48 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:

> Barry Schwarz於 2011年12月18日星期日UTC+8上午2時10分09秒寫道：
> > On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> > <dihedr...@googlemail.com> wrote:
> > >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:


> > >> my Q is on the c language tell me now why c has pointers.

you never explained why you wanted to know this or what sort answer
would satisfy you.

> > >OK, I'll explain how to use a pointer in C without any knowledge in the
> > >hardware or assembly here.

and then you plummet into implementaion specifics like a fish into
water...

> > >int i;
> > >int a[3]={ 1,2,3} ; // an array of 3 integers
> > >int* ptr1; // Note the star should be right after int, not initialize

this is an opinion not a fact. It is quite common (more common?) for C
programmers to do the opposite of what you suggest.

> > >int* ptr2; // not initialized
>
> > >ptr1=a; // Read this as  to make ptr1 to be an alias of a.

no. Not really.

> > If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

exactly. It also isn't an alias.

> Why do you care about the size of an array declared on the stack?

as usual dihedral inhabits a universe not co-terminus with our own.

becuase it might blow the stack? the point is 'ptr1' is NOT an alias
for 'a' because **they have different behaviour***

Also, how do you know these identifiers refer to automatic variables?
The indentation indicates otherwise.

> Everything on the stack is to be popped out in the exit of a function in C.

dihedral spouts irrelevence again

> But a pointer allocated in the heap is different.

why? The alias stuff nonsense no matter where they are allocated

> > which, in the general case, they are not.  ptr1 is simply a pointer
> > that points to the start of a.  Even though they share some
> > similarities in the language syntax, a pointer is a completely
> > different type than an array.  Calling one an alias of the other just
> > breeds unnecessary confusion.

yes

> A pointer defines an alias to a variable. Don't you get it in C or assembly?

just repeating nonsense doesn't make it true. Argument ad Goebbels

[88888 Dihedral]

Nick Keighley於 2012年1月10日星期二UTC+8下午4時21分05秒寫道：

> for some reason "Dihedral" has revived this ancient topic
>

> On Jan 9, 11:48 pm, 88888 Dihedral <dihedr...@googlemail.com>

I am not interested to argue with ASSEMBLY IDIOTS.