Good Tutorials

[Amkcoder]

http://amkcoder.fileave.com/L_BitWise.zip
http://amkcoder.fileave.com/L_ptr2.zip

[Richard Heathfield]

Amkcoder said:

http://amkcoder.fileave.com/L_BitWise.zip
http://amkcoder.fileave.com/L_ptr2.zip

They really are tutorials. L_BitWise.zip contains one text file, 157 lines
long, which is indeed a tutorial on bitwise operators. L_ptr2.zip contains
one text file, L_ptr.txt, which is a 174-line tutorial on pointers.

I didn't look very closely at either of them, but the first paragraph of
the pointer tute does not look promising:

"A pointer in C is a variable which holds the address of another variable
in memory. They are useful for dynamicly allocated memory which may be
deallocated when nolonger needed,linked lists,writing to memory external to
the program,and allowing invoked functions to manipulate the data of
variables outside their scope. These have many uses and are necessary to
successfull programming in C."

Oh deary deary me.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Ben Bacarisse said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>>>"A pointer in C is a variable which holds the address of another
variable in memory. They are useful for dynamicly allocated memory
which may be deallocated when nolonger needed,linked lists,writing to
memory external to the program,and allowing invoked functions to
manipulate the data of variables outside their scope. These have many
uses and are necessary to successfull programming in C."

<snip>

>>
Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.

I count only 2 and half. Why not tell us your three[1]?

<snip>

>
[1] Mine are: a pointer is a value not a variable. They address
objects not variables (that, to me, is the half) and I don't like the
idea of "memory external to the program". If you have a pointer you
can write though, it is your data (even if the OS wishes it were
not!).

One of yours (the first one), and my second is a rather harsher take on the
same subject as your one-and-a-halfth point, because pointer values need
not even represent object addresses, let alone variable addresses - they
could be indeterminate, or null, or function pointers. My third rather
depends on what you mean by "variable", but if the last clc discussion on
the matter is anything to go by, the bit about scope is wrong too.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:3-*********************@bt.com...

Ben Bacarisse said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>Ignoring, if I may, the appalling wordsmithery, I count three errors of
fact in that first paragraph.

I count only 2 and half. Why not tell us your three[1]?

<snip>

>>
[1] Mine are: a pointer is a value not a variable. They address
objects not variables (that, to me, is the half) and I don't like the
idea of "memory external to the program". If you have a pointer you
can write though, it is your data (even if the OS wishes it were
not!).

One of yours (the first one), and my second is a rather harsher take on
the
same subject as your one-and-a-halfth point, because pointer values need
not even represent object addresses, let alone variable addresses - they
could be indeterminate, or null, or function pointers. My third rather
depends on what you mean by "variable", but if the last clc discussion on
the matter is anything to go by, the bit about scope is wrong too.

This is exactly the point MisterE was making.

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

--
Bartc

[vippstar]

On Sep 23, 6:09 pm, "Bartc" <[e-mail]:

<snip>

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

Message-ID: <Xz*******************@text.news.virginmedia.com >
Bartc said:

vippstar said:

>Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])

I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.

Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.

[Amkcoder]

On Sep 23, 8:33 am, [e-mail] wrote:

On Sep 23, 6:09 pm, "Bartc" <[e-mail]:

<snip>

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

Message-ID: <Xz*******************@text.news.virginmedia.com >
Bartc said:

vippstar said:

Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])

I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.

Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.

So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...

Go on and explain,
or you are no programmer.

Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.

[Amkcoder]

On Sep 23, 8:33 am, [e-mail] wrote:

On Sep 23, 6:09 pm, "Bartc" <[e-mail]:

<snip>

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

Message-ID: <Xz*******************@text.news.virginmedia.com >
Bartc said:

vippstar said:

Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])

I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.

Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.

So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...

Go on and explain,
or you are no programmer.

Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.

[Amkcoder]

On Sep 23, 8:33 am, [e-mail] wrote:

On Sep 23, 6:09 pm, "Bartc" <[e-mail]:

<snip>

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

Message-ID: <Xz*******************@text.news.virginmedia.com >
Bartc said:

vippstar said:

Given that p is char [4][2], you should immediately be able to tell
which type *p is, p[0][0], &p[0].
(answer: char [2], char, char (*)[2])

I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.

Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck. You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.

So you call Intel liars,
You call universities who use my same definition of pointers liars,
And then you say I have but a smattering of datatypes
when you don't even know what your saying...

Go on and explain,
or you are no programmer.

Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.

[Keith Thompson]

"Bartc" <[e-mail]:
[...]

I neither know nor care whether a pointer is a value, variable, type
or object. But that hasn't stopped me using them quite effectively.

But it could well stop you from communicating effectively about them.

And I think you overestimate your own ignorance. For example, given:

int x;
int *obj = &x;

I think you know that obj is an object (and a variable), &x is a
value, and int* is a type.

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

[jameskuyper]

Amkcoder wrote:
....

The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."

So, if we have

char greeting[] = "Hello, World!";
int seven = 7;

Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.

I consider this to be a serious defect in your definition of a
pointer.

....

Like I said, good tutorials...
Please only sincere students or real programmers comment,

I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.

[Amkcoder]

On Sep 23, 9:03 am, [e-mail] wrote:

Amkcoder wrote:

...

The definition you so waywardly complain about is repeated as a common
definition:
"A pointer is a variable that points at, or refers to, another
variable."

So, if we have

char greeting[] = "Hello, World!";
int seven = 7;

Then according to your definition, neither greeting+6 nor &seven are
pointers, because they are expressions, not variables. According to
your definition, neither (void*)0 nor malloc(256) is a pointer, both
because they aren't variables and because they don't point at
variables.

I consider this to be a serious defect in your definition of a
pointer.

...

Like I said, good tutorials...
Please only sincere students or real programmers comment,

I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.

Sorry,
when you declare a short int it allocates two bytes and associates the
beginning of the
address to the two bytes to your variable.
And I do understand that a pointer can be refered to space allocated
by a call to malloc,
It is in my tutorial.

short int *sint=malloc(2);
unsigned char *a=(unsigned char *)sint;
*a=154;
*(a+1)=2;
printf("%d",*sint);

Check out the value it prints out.
They must pay you minimum wage just to crank out code.
I am a real programmer, 14 years in the making.

[jellybean stonerfish]

On Tue, 23 Sep 2008 09:50:21 -0700, Amkcoder wrote:

The reason universities, who make real programmers, use the definition
that a pointer

I am not qualified to discuss this topic, but will point out that your
posts seem to be posted 2 or 3 times each.

sf

[Richard Heathfield]

Amkcoder said:

<snip>

The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.

You have been shown several counterexamples. Here are a few to refresh your
memory:

malloc(256)
myarray + offset
&integerobject
printf

None of these pointers is a variable that holds the address of another
variable. So now you have three choices:

1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.

1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.

This is because every time you declare a pointer it allocates enough
bytes to hold
a value,

Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:

extern int *p;

<snip>

So he's is an expert?
Then call me the professional.

Why? You have not yet convinced me that you have the slightest idea what
you're talking about.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Amkcoder]

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

Amkcoder said:

<snip>

The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.

You have been shown several counterexamples. Here are a few to refresh your
memory:

malloc(256)
myarray + offset
&integerobject
printf

None of these pointers is a variable that holds the address of another
variable. So now you have three choices:

1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.

1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.

This is because every time you declare a pointer it allocates enough
bytes to hold
a value,

Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:

extern int *p;

<snip>

So he's is an expert?
Then call me the professional.

Why? You have not yet convinced me that you have the slightest idea what
you're talking about.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

A byte, typicaly, as the most common systems I have used is 8-bits in
length.
As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.
This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386, or the newer ones:
http://www.cs.ucla.edu/~kohler/class...4/ref/i386.pdf
PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:

#include <stdio.h>

int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(short int));
system("pause");
}

[Amkcoder]

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

Amkcoder said:

<snip>

The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.

You have been shown several counterexamples. Here are a few to refresh your
memory:

malloc(256)
myarray + offset
&integerobject
printf

None of these pointers is a variable that holds the address of another
variable. So now you have three choices:

1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.

1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.

This is because every time you declare a pointer it allocates enough
bytes to hold
a value,

Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:

extern int *p;

<snip>

So he's is an expert?
Then call me the professional.

Why? You have not yet convinced me that you have the slightest idea what
you're talking about.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

A byte, typicaly, as the most common systems I have used is 8-bits in
length.
As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.
This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386, or the newer ones:
http://www.cs.ucla.edu/~kohler/class...4/ref/i386.pdf
PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:

#include <stdio.h>

int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(short int));
system("pause");
}

[Amkcoder]

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

Amkcoder said:

<snip>

The reason Universities, who make real programmers, say that a pointer
is a variable
that holds the address of another, it is.

You have been shown several counterexamples. Here are a few to refresh your
memory:

malloc(256)
myarray + offset
&integerobject
printf

None of these pointers is a variable that holds the address of another
variable. So now you have three choices:

1) accept that you're wrong;
2) explain why the counterexamples don't apply;
3) neither of the above.

1) and 2) are both honourable options, but 3) just suggests that you don't
know what you're talking about.

This is because every time you declare a pointer it allocates enough
bytes to hold
a value,

Not true. For example, here's a declaration of a pointer that doesn't
allocate any bytes at all:

extern int *p;

<snip>

So he's is an expert?
Then call me the professional.

Why? You have not yet convinced me that you have the slightest idea what
you're talking about.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

A byte, typicaly, as the most common systems I have used is 8-bits in
length.
As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.
This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386, or the newer ones:
http://www.cs.ucla.edu/~kohler/class...4/ref/i386.pdf
PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:

#include <stdio.h>

int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(short int));
system("pause");
}

[Keith Thompson]

Amkcoder <fr********************@yahoo.comwrites:
[...]

This proves I am a programmer, capable of programmer x86 based
processors.
So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:

#include <stdio.h>

int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(short int));
system("pause");
}

Most of your articles are appearing several times. This isn't an
uncommon problem with Google Groups, but most users don't have as much
trouble with it as you do.

Please don't quote the entire article to which you're replying. In
particular, don't quote signatures (the part following the "-- "
delimiter) unless you're actually commenting on them.

We don't just discuss x86 processors here; we discuss the C
programming language, which is implemented on processors you've
probably never heard of.

But ok, I'll try your program on my x86 system:

% gcc -ansi -pedantic -Wall -Wextra c.c -o c
c.c: In function 'main':
c.c:10: warning: implicit declaration of function 'system'
c.c:11: warning: control reaches end of non-void function
% ./c
666
2 bytes for short int
sh: pause: not found

And here's the same program on a SPARC system:

% cc -Xc c.c -o c
"c.c", line 10: warning: implicit function declaration: system
% ./c
-26110
2 bytes for short int
sh: pause: not found

And there are other systems where your statement

printf("%d bytes for short int \n",sizeof(short int));

is likely to produce garbage, because you're using "%d" for an
argument of type size_t (I've used systems where int is 32 bits and
size_t is 64 bits). I don't have easy access to any such systems at
the moment.

You can learn a lot here if you'll just drop the arrogant attitude and
realize that many of us actually know things that you don't,
notwithstanding your years of experience as a Professional Programmer.
The world of C is a lot bigger than you seem to think it is.

And who knows, maybe you could teach us a few things too, though so
far everything you've told us is stuff that (a) we already know, and
(b) we know isn't even close to being the whole story.

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

[Tony Mc]

On Tue, 23 Sep 2008 14:49:28 +0100, Ben Bacarisse
<be********@bsb.me.ukwrote:

[1] Mine are: a pointer is a value not a variable. They address
objects not variables

But a pointer may also be a pointer to function which does not point
to an object at all.

Tony

[Flash Gordon]

Amkcoder wrote, On 23/09/08 17:50:

<snip>

The reason universities, who make real programmers, use the definition
that a pointer
is a variable that holds the address to another variable in memory, is
because
it is.

I'll admit that the word "pointer" is often used to refer to a variable
of type pointer to something. It's a good way to confuse people though
because that is not the only way the word is commonly used.

Every time you declare a pointer space is allocated for it to hold a
value,
which will be treated as an address. This space has its own address,
just like a variable.

Since you are using the word "pointer" to mean a "pointer variable" then
it not only has its own address just like a variable it *is* a variable.
This leads to another mistake in your tutorial. You say...

The address of memory allocated by a declared variable may be retrieved
with the address of operator for assignment to a pointer, or for
later storage.
This works on any variable but pointers, if it is a pointer one
may retrieve the address it holds by excluding the asterik prefixed
to its identifier.

This is wrong. The address operator "&" works perfectly well on pointer
variables, I know because the standard says so and I use it. Of course,
it doesn't give you the value the pointer variable contains, but in that
respect it is _exactly_the_same_ as every other variable.

So that every time a pointer is declared the same amount of space is
allocated
capable of holding an address. The pointer's type merely indicates how
to treat the data it refers to when it is dereferenced.
So he is an expert,
then call me the professional.

You would not even get through the interview anywhere that I have worked.

Another error is that you seem to think that adding one to a pointer
increments it by one byte and that if you want to increment through some
type larger than a byte you have to add sizeof(type) to a pointer. This
is complete and utter rubbish. You then go on to ignore allignment
issues giving this final piece of badly broken code...

unsigned char *char_ptr=malloc(sizeof(char)+sizeof(short int));
short int *int_ptr=(short int *)char_ptr+1;
*char_ptr=123;
*int_ptr=510;
printf("%d %d",*char_ptr,*int_ptr);

Just for amusement I've expanded it to a complete program...
markg@brenda:~$ cat t.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
unsigned char *char_ptr=malloc(sizeof(char)+sizeof(short int));
short int *int_ptr=(short int *)char_ptr+1;
*char_ptr=123;
*int_ptr=510;
printf("%d %d",*char_ptr,*int_ptr);
printf("\n%p %p\n",(void*)char_ptr,(void*)int_ptr);
return 0;
}
markg@brenda:~$ gcc -ansi -pedantic -Wall -Wextra -g3 t.c
markg@brenda:~$ ./a.out
123 510
0x804a008 0x804a00a
markg@brenda:~$
Note that the addresses are two apart not 1 as you thought. This also
means that as on this machine short is two bytes it reads/writes beyond
the end of the allocated memory. For your information I also ran it
through a memory checker which reports this problem...
markg@brenda:~$ valgrind --tool=memcheck ./a.out
==5552== Memcheck, a memory error detector.
==5552== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==5552== Using LibVEX rev 1804, a library for dynamic binary translation.
==5552== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==5552== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
framework.
==5552== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==5552== For more details, rerun with: -v
==5552==
==5552== Invalid write of size 2
==5552== at 0x80483D6: main (t.c:9)
==5552== Address 0x418d02a is 2 bytes inside a block of size 3 alloc'd
==5552== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5552== by 0x80483C0: main (t.c:6)
==5552==
==5552== Invalid read of size 2
==5552== at 0x80483DE: main (t.c:10)
==5552== Address 0x418d02a is 2 bytes inside a block of size 3 alloc'd
==5552== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5552== by 0x80483C0: main (t.c:6)
123 510
0x418d028 0x418d02a
==5552==
==5552== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 11 from 1)
==5552== malloc/free: in use at exit: 3 bytes in 1 blocks.
==5552== malloc/free: 1 allocs, 0 frees, 3 bytes allocated.
==5552== For counts of detected errors, rerun with: -v
==5552== searching for pointers to 1 not-freed blocks.
==5552== checked 60,204 bytes.
==5552==
==5552== LEAK SUMMARY:
==5552== definitely lost: 3 bytes in 1 blocks.
==5552== possibly lost: 0 bytes in 0 blocks.
==5552== still reachable: 0 bytes in 0 blocks.
==5552== suppressed: 0 bytes in 0 blocks.
==5552== Rerun with --leak-check=full to see details of leaked memory.
markg@brenda:~$

One final point, you are not fluent enough in English to write a good
tutorial in English. You lack of fluency probably makes your tutorial
worse than it would be if you wrote it in your first language.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Richard Heathfield]

Amkcoder said:

<snip>

A byte, typicaly, as the most common systems I have used is 8-bits in
length.

Yes, that's a very common option.

As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte

You don't need to persuade me that 8-bit bytes are common. Nevertheless,
they are not universal. I have personally worked on a system with 32-bit
bytes, for example.

On x86 architecture based systems and compatibles,

If you want to discuss the x86 architecture, that's fine, but please do it
in a newsgroup where the x86 architecture is topical. Here we discuss C.

<lots of parochial stuff snipped>

This proves I am a programmer,

Well, no, but it does suggest that you've focussed primarily on x86s.

So if you have a x86 based processor, which you most likely do,
compile and run the following:

If your tutorial is for x86 programming, I suggest you advertise it in an
x86 group. If you're trying to teach C, I suggest you learn it first.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jameskuyper]

Amkcoder wrote:

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

....

A byte, typicaly, as the most common systems I have used is 8-bits in
length.

Just keep in mind that not all systems have 8-bit bytes.

As is confirmed at wikipedia http://en.wikipedia.org/wiki/Byte
On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,

Just keep in mind that not all C implementations run on x86
architectures.

each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.
As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.
To program on the x86 architecture it is requisite knowledge.

Not at all. It's quite feasible to write useful programs for x86
architectures which make no use whatsoever of any implementation-
specific feature you've described above. Most of my code, for
instance, makes no use of any of that information, despite the fact
that it runs mostly on Linux x86 machines (it also runs on SGI Irix
machines. It should also work on Windows and Mac machines, but I don't
have access to any machine where I can test that assumption, so I
can't be sure).

This is the most common of architectures, so to be a real programmer,

Don't count on it. For every x86 machine, there's multiple embedded
processors on the very same board with it, in addition to all of the
embedded processors in all of the other devices in the world. I'm not
sure that there's any one embedded processor that is more common than
the entire x86 family of processors, but collectively I'm quite sure
that embedded processors vastly outnumber x86 processors, and most of
those embedded processors have environments significantly different
from the one you describe.

I can't prove from my personal knowledge that more C programming is
being performed for embedded processors than for all other platforms
combined; but I have heard that claim made, and I don't know of any
reason to doubt it. It's certainly a major development area,
regardless of what the actual quantities of code are.

capable working in the real world on most systems,

Even if x86 machines are the most common, that doesn't mean that
they're more common than all other types combined. Your use of the
phrase "most systems" had better be justified with some hard numbers.

you'll need this manual for the 80386, or the newer ones:
http://www.cs.ucla.edu/~kohler/class...4/ref/i386.pdf

No, you don't. It's useful information, for some kinds of x86
programming, and completely irrelevant for other kinds of x86
programming, and it's completely irrelevant for all kinds of
programming on any system that doesn't happen to be an x86 machine.

PS, the applications programming section, chapter on datatypes
confirms all that I have said in the above pdf.
This proves I am a programmer, capable of programmer x86 based
processors.

Not really. It only proves that you think "everything's an x86". A
real programmer knows what he can and cannot rely on when porting to
different platforms, and you make it sound like you have a serious
shortage of knowledge on that subject.

[Bartc]

Keith Thompson wrote:

"Bartc" <[e-mail]:
[...]

>I neither know nor care whether a pointer is a value, variable, type
or object. But that hasn't stopped me using them quite effectively.

But it could well stop you from communicating effectively about them.

And I think you overestimate your own ignorance. For example, given:

int x;
int *obj = &x;

I think you know that obj is an object (and a variable), &x is a
value, and int* is a type.

Sure, when you stop to think about these things. But sometimes thinking too
much about something obvious is counter-productive: is x an integer, or the
address of an integer, or just a symbol? Suddenly things get complicated.

"A pointer is a variable that holds the address of another variable..." or
whatever it was, is a little sloppy but a reasonable starting point. Maybe
the pointer may not be in a variable, sometimes it doesn't point to another
variable...etc. That can wait for a subsequent tutorial.

--
Bartc

[soscpd]

Hi List

On Sep 23, 2:49*pm, Tony Mc <[e-mail]:

But a pointer may also be a pointer to function which does not point
to an object at all.

Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

Did anyone know a pointer to something who will not return any value?

Can anyone find a better definition then "pointer" itself?
I mean.... pointer is ... a pointer?
Regards
Rafael

[Richard Heathfield]

soscpd said:

Hi List

On Sep 23, 2:49 pm, Tony Mc <[e-mail]:

>But a pointer may also be a pointer to function which does not point
to an object at all.

Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

Did anyone know a pointer to something who will not return any value?

Can anyone find a better definition then "pointer" itself?
I mean.... pointer is ... a pointer?

If you're looking for a *short* definition, "pointer" is perfect. If you're
looking for a technical definition, the best place to look is the
Standard, but unfortunately it defines "pointer" in terms of behaviour,
and that definition is scattered across a trillion clauses.

If you're looking for a useful way to introduce the concept to students,
perhaps you might try something like the following:

"One great advantage of stored-program digital computers is that they can
store both code and data in their memory. To a first approximation, a
pointer value is a value that represents the place in memory where either
code (a function) or data (an object) is stored. We'll cover the two
exceptions - indeterminate pointers and null pointers - later on. Pointer
values can be stored in objects that have the appropriate pointer type for
the relevant object or function."

.... and going on to explain about null and indeterminacy.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jameskuyper]

soscpd wrote:

Hi List

On Sep 23, 2:49�pm, Tony Mc <[e-mail]:

But a pointer may also be a pointer to function which does not point
to an object at all.

Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

I'm not quite sure what you mean by those questions. A function
pointer does not "return" anything. It points at the entry point for a
function, which does not qualify as an "object" as far as the C
standard is concerned. It can be used to call the function that it
points at. That is the reason why we use function pointers. The
function call may return something, but the function pointer itself
does not.

Did anyone know a pointer to something who will not return any value?

It has a value, which is the location of the function it points at. It
doesn't "return" that value.

Can anyone find a better definition then "pointer" itself?
I mean.... pointer is ... a pointer?

The standard doesn't define "pointer" but it does define a "pointer
type":

6.2.5p20: "A pointer type describes an object whose value provides a
reference to an entity of the referenced type."

Notice how the use of the term "entity" neatly side-steps the object
pointer/function pointer distinction.

It is commonplace to use the term pointer to mean either a "pointer
object" or a "pointer value", both usages are common in the standard
itself. This occasionally leads to confusion. Amkcorder's definition
comes closer to being correct if it defines a pointer object; it
doesn't work at all as a definition of a pointer value.
Fundamentally, I think his problem is that he confuses "object" with
"variable". The standard doesn't define what the word "variable"
means, but the most reasonable definition I'm familiar with is that,
in C terms, a variable is a named object. With that definition for
"variable", his definition of "pointer" is incorrect, whether it's
meant to define a pointer object or a pointer value.

[CBFalconer]

Amkcoder wrote:

[e-mail] wrote:

.... snip ...

>

>I'm a real programmer. At least, they pay me to write computer
programs. And I know, as you apparently do not, that pointers don't
need to be variables, and they don't need to point at variables.

Sorry, when you declare a short int it allocates two bytes and
associates the beginning of the address to the two bytes to your
variable.

You have already been told many times that a short is not
necessarily a two byte object. Why do you repeat this
misinformation?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Anand Hariharan]

On Sep 23, 3:22*pm, [e-mail] wrote:

I'm not
sure that there's any one embedded processor that is more common than
the entire x86 family of processors,

The empirical evidence is fairly overwhelming to suggest that there
isn't one (especially since you pit it against the entire x86 family).

but collectively I'm quite sure
that embedded processors vastly outnumber x86 processors, and most of
those embedded processors have environments significantly different
from the one you describe.

I can easily agree with that. It's just that they are so diverse and
fragmented, one can easily conclude that x86 is what is out there.
- Anand

[Mark L Pappin]

CBFalconer <cb********@yahoo.comwrites:

I listened to the teacher, and was horrified at the inaccuracies he
was teaching. I resolved I could do better.

So I got to try out my technique. I accurately explained various
things. Then I looked at the class, and was greeted with
dumbfounded looks.

....

From then on I have been left with admiration for the way the
demonstrating teacher managed to explain things with inaccurate
explanations.

Terry Pratchett, Ian Stewart, and Jack Cohen (in their several
"Science of Discworld" books) describe the technique as "Telling Lies
To Children", where the Lies become incrementally more accurate as the
Children's understanding becomes more complete.

Some Children need particularly blatant Lies and take a while to get
used to revisions, and some refuse to accept later revisions at all.
We see examples of both here.

In an ideal world with perfectly rational students perhaps one could
begin by stating "What I am about to tell you is not completely
correct, but is a necessary simplification to bootstrap this model of
reality into your brain. Later, as your understanding grows, you will
need to throw out some of these simplifications to allow you to see
better models." We don't have such a world, unfortunately.

mlp

[Ben Bacarisse]

Richard<rg****@gmail.comwrites:
<snip>

This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address".

You are putting words into people's mouths again. Who has said this
here? I will gladly go and post a comment. & is called (in the C
standard) the address operator. It produces a value of type "pointer
to...". The terms are close to be synonymous in C.

People have, correctly, objected to your simplification that and
pointer and/or an address is a number, because that will suggest to
some people that more can be done with it than is, is fact,
permitted.

[I snipped everything because I could not find anything to support
Richard's claim in the message he replied to.]

--
Ben.

[Ben Bacarisse]

Tony Mc <af***@btinternet.comwrites:

On Tue, 23 Sep 2008 14:49:28 +0100, Ben Bacarisse
<be********@bsb.me.ukwrote:

>[1] Mine are: a pointer is a value not a variable. They address
objects not variables

But a pointer may also be a pointer to function which does not point
to an object at all.

Good point. I should, maybe, just have stuck to the point I wanted to
make: that they don't always address variables as was stated.

--
Ben.

[Andrew Poelstra]

On 2008-09-23, Amkcoder <fr********************@yahoo.comwrote:

So if you have a x86 based processor, which you most likely do,
compile and run the following:
It will print out the value 666, and the size (in bytes) of a short
int,
on your x86 system. Enjoy:

#include <stdio.h>

int main() {
short int a;
unsigned char *b=(unsigned char *)&a;
*b=154;
*(b+1)=2;
printf("%d \n",a);
printf("%d bytes for short int \n",sizeof(short int));
system("pause");
}

On my system, it does indeed output 666, followed by a "command
not found" regarding your system() call. I'm not sure what this
code demonstrates, though, other than that one can take this:
puts("666")
And make it intrinsicly non-portable, rife with undefined
behavior, inefficient and unmaintainable to boot.

But hey, you're the expert.
(My compiler also has this to say:

usenet.c: In function ‘main’:
usenet.c:9: warning: format ‘%d’ expects type ‘int’, but argument
2 has type ‘long unsigned int’
usenet.c:10: warning: implicit declaration of function ‘system’
usenet.c:11: warning: control reaches end of non-void function

but it hasn't been dealing with C code for as long as you.)

(Also, FWIW, it's incorrect on the first warning - the value
yeilded by the sizeof operator is technically a size_t. I'm
guessing since all the world's a x86, it doesn't matter.)

--
Andrew Poelstra ap*******@wpsoftware.net
Only GOD may divide by zero. That is how he created black holes.
-Veselin Jungic

[Keith Thompson]

Andrew Poelstra <ap*******@supernova.homewrites:

On 2008-09-23, Amkcoder <fr********************@yahoo.comwrote:

[...]

> printf("%d bytes for short int \n",sizeof(short int));

[...]

(My compiler also has this to say:

usenet.c: In function ‘main’:
usenet.c:9: warning: format ‘%d’ expects type ‘int’, but argument
2 has type ‘long unsigned int’

[...]

>
(Also, FWIW, it's incorrect on the first warning - the value
yeilded by the sizeof operator is technically a size_t. I'm
guessing since all the world's a x86, it doesn't matter.)

But size_t is merely a typedef for some predefined unsigned integer
type, apparently unsigned long on your system. A typedef doesn't
create a new type, merely an alias for an existing type. So on your
system, sizeof(short int) really is of type long unsigned int.

But it would be nice if the compiler were clever enough to refer to
the size_t typedef instead.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

<snip>

Then the only disagreement/confusion is over the meaning of "uses".
An object of type short, as we all know, *occupies* exactly
sizeof(short) bytes;

Yes.

you can argue (and I won't disagree) that it only
*uses* the sign and value bits.

I would indeed argue that.

(Though it might *use* the padding
bits for some purpose other than representing the value, for example
as check bits.)

That would be an implementation detail, and a program that took advantage
of it in some way would be grossly non-portable.

If Chuck intended to make that distinction, I'll gladly concede that
he was correct, though I don't know why he'd say bytes in that context
rather than bits. But he was responding to Amkcoder's claim that a
short int *is* exactly two bytes.

Yes, perhaps that's why.

A more pertinent response to that
claim is that a short int *is* exactly sizeof(short) bytes.

Right. I pointed this out to Amkcoder, but it seems to have flown way over
his head.

>
(I doubt that Amkcoder knows about padding bits anyway.)

Here, I cannot bring myself to disagree with you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Mark L Pappin wrote, On 24/09/08 01:52:

<snip>

In an ideal world with perfectly rational students perhaps one could
begin by stating "What I am about to tell you is not completely
correct, but is a necessary simplification to bootstrap this model of
reality into your brain. Later, as your understanding grows, you will
need to throw out some of these simplifications to allow you to see
better models." We don't have such a world, unfortunately.

Some of the very good teachers I had did basically tell us that. Well,
actually it was the physics and chemistry teachers told us that the
models were simplifications and if we were doing both we would be taught
different models for different purposes in the two courses and further
models in later courses if we continued with science. It did not seem to
cause problems.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Nick Keighley]

On 23 Sep, 16:48, Amkcoder <[e-mail]:

On Sep 23, 8:33 am, [e-mail] wrote:

On Sep 23, 6:09 pm, "Bartc" <[e-mail]:

sombody has messed up the attributions. There may have been
Top Posting. I've just gathered up the attributions I've
found in this post and dumped them here.

Message-ID: <Xzryk.56633$[e-mail] >
Bartc said:

vippstar said:

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

I think you're wrong. People *can* use pointers effectivly
without swallowing the standard. They might do a better
job if they fully understood the underlying type system
but not doing so does *not* preclude them from using C
effectivly.

A tutorial author though should at least be aware or the
correct terminology even if for pedalogical purposes
he drifts away from it a little.

>Given that p is char [4][2], you should immediately be able to tell
>which type *p is, p[0][0], &p[0].
>(answer: char [2], char, char (*)[2])

I wouldn't frighten off the OP with this stuff. I don't understand half of
it either.

I don't think he frightens easily!

:-)

Now, if you don't understand types, and those who are so trivial, I
doubt you can use pointers effectively.
Even if you can, it was by luck.

cobblers

You certainly *can't* write a
tutorial about using pointers effectively, or pointers in general.

Why don't you explain why I am wrong then, MR.PROGRAMMER,
and just to tell you my understanding of datatypes is backed
by the intel x86 manuals applications programming section,
chapter on data types.

It might be an idea to read C documentaion when writing
a C tutorial.

So you call Intel liars,

no he didn't. Don't be silly.

You call universities who use my same definition of pointers liars,

ditto. Which universites? Where? Do you have a link to this
usage?

And then you say I have but a smattering of datatypes
when you don't even know what your saying...

your -you're

why do you think he doesn't know what he's saying?
Is he delirious? Drugged?

Go on and explain,
or you are no programmer.

silly

Now the topic of this post is about good tutorials,
and they are, so follow the link at the top.

are you the author of the tutorial?
Bad C tutorials unfortunatly far outnumber
good ones.
--
Nick Keighley
"Perilous to us all are the devices of
an art deeper than we possess ourselves."
Gandalf The Grey (discussing Windows Vista)

[soscpd]

Hello Richard, James, List

On Sep 23, 6:20 pm, Richard Heathfield <[e-mail]:

If you're looking for a *short* definition, "pointer" is perfect. If you're
looking for a technical definition, the best place to look is the
Standard, but unfortunately it defines "pointer" in terms of behaviour,

So far, I can't agree with you more.

"One great advantage of stored-program digital computers is that they can
store both code and data in their memory. To a first approximation, a
pointer value is a value that represents the place in memory where either
code (a function) or data (an object) is stored. We'll cover the two
exceptions - indeterminate pointers and null pointers - later on. Pointer
values can be stored in objects that have the appropriate pointer type for
the relevant object or function."

Yeah, right. It is correct. But try that in a classroom. The ones who
will not sleep, will leave the room. But ok... I'll give you a shot.
By friday I can test it with a friend (teacher... :).

My point is: There must be a way to define pointers as simple as they
are - they are pointers. They point to something. Then, the behavior
it's up to the contents. Leave pointers alone and put the effort in
teaching the contents. Doing that you will not scare students with -
Hey.. that's true, but not always - or - Pointers is a hard subject.
It is not if teached without the "stuff", I think.

++++++++

On Sep 23, 6:55 pm, [e-mail] wrote:

Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

I'm not quite sure what you mean by those questions. A function
pointer does not "return" anything. It points at the entry point for a

Well... James... here is the part who, sometimes, make-me delete all
c.l.c inputs on my mail box before read. I love C. It is my favorite
language, and I am always looking for his edges. Still can't find (and
probably will not), but the trip is enough fun.

But every time we are discussing something on c.l.c, we must follow
the standards, thinking, speaking and so on. Well... was my mistake do
not follow that simple rules. By return, I mean: If you use it, in
some place where you expect the variable value, you will get the value
(please... no to initialization, error and stuff. Consider the utopia
with me, right now. I'm not a C teacher and my goal is not follow the
standards as standards... they are more general guidelines to me),
like:

int *p = malloc(sizeof(int));
p=2;

So... p is a pointer to a memory location of int size?

After all... the machine job is to go to that location and "return"
the value, if I ask for it.

That's was my return definition in there.

function, which does not qualify as an "object" as far as the C
standard is concerned. It can be used to call the function that it
points at. That is the reason why we use function pointers. The

Right. By me... that still means you are returning something. I can't
find a function who do not return (by me, a null void return is,
still, a return).

It has a value, which is the location of the function it points at. It
doesn't "return" that value.

Ok... ok...

The standard doesn't define "pointer" but it does define a "pointer
type":

Yeah, right...

Can we keep Richard's "...defines "pointer" in terms of behaviour..."
and keep that way?

It is commonplace to use the term pointer to mean either a "pointer
object" or a "pointer value", both usages are common in the standard

I can't find any difference between function pointer and variable
pointer (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use. What is
it, and how you will use it doesn't matter to the pointer. That is why
I am usual to do not mix both subjects (bottle and contents - ok...
here is not exactly bottle. Its more like the place where the bottle
is... endless). I just find that way the best one to know how to
handle pointers.

in C terms, a variable is a named object.

Mm... agreed, I think.
Regards
Rafael

[Nick Keighley]

On 23 Sep, 19:03, Amkcoder <[e-mail]:

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

Amkcoder said:

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

don't post sigs. The bit after "-- "

On x86 architecture based systems and compatibles,
it is confirmed that a word is two contiguous bytes,
each of which have their own address,
and the lower of the addresses is the address of the word.
This makes a 16-bit value.

this has nothing to do with C. C does not have "words".
Nowhere is is set in stone that a short must be an x86 word.
On some compilers a short might be 32 bits. Even on an
x86.

As can be seen in this archecture it requires a double word (32-bit
binary value)
to represent every address,
for it can address up to 2^32-1 bytes,
and as can be seen a double word contains 32-bits having
a maximum value of 2^32-1 when unsigned
, for on these systems each address refers to a byte.

there are 64-bit x86s

To program on the x86 architecture it is requisite knowledge.

no

This is the most common of architectures, so to be a real programmer,
capable working in the real world on most systems,
you'll need this manual for the 80386,

no. I have programmed x86s and I don't have an x86 hardware manual.

<snip>

You definitly should learn more C before you write any more
tutorials.
--
Nick Keighley

[Nick Keighley]

On 23 Sep, 21:22, [e-mail] wrote:

Amkcoder wrote:

On Sep 23, 10:17 am, Richard Heathfield <[e-mail]:

<snip>

[x86] is the most common of architectures, so to be a real programmer,

Don't count on it. For every x86 machine, there's multiple embedded
processors on the very same board with it, in addition to all of the
embedded processors in all of the other devices in the world. I'm not
sure that there's any one embedded processor that is more common than
the entire x86 family of processors, but collectively I'm quite sure
that embedded processors vastly outnumber x86 processors, and most of
those embedded processors have environments significantly different
from the one you describe.

the ARM is a contender. From its wiki entry:
"Today, the ARM family accounts for approximately 75% of all embedded
32-bit RISC CPUs,[1] making it one of the most widely used 32-bit
architectures."

<snip>

--
Nick Keighley

[Richard Heathfield]

soscpd said:

Hello Richard, James, List

On Sep 23, 6:20 pm, Richard Heathfield <[e-mail]:

<snip>

>

>"One great advantage of stored-program digital computers is that they
can store both code and data in their memory. To a first approximation,
a pointer value is a value that represents the place in memory where
either code (a function) or data (an object) is stored. We'll cover the
two exceptions - indeterminate pointers and null pointers - later on.
Pointer values can be stored in objects that have the appropriate
pointer type for the relevant object or function."

Yeah, right. It is correct. But try that in a classroom.

Not word for word, of course. Although "lecture" originates from the time
when a professor would read out his notes word for word and students would
religiously copy it all down, a good teacher had better be able to sound
like he /isn't/ just reading from a book. Nevertheless, the concepts in
the above paragraph are important, and a good teacher will be able to
present them without boring the students *and* without giving them
incorrect information.

A teacher should never try to tell the whole truth (because there isn't
time), but he should certainly tell the truth and nothing but the truth.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kuyper]

soscpd wrote:
....

On Sep 23, 6:55 pm, [e-mail] wrote:

>>Mmm... did the function (pointer) return something? That is not the
"why" we can use function pointers?

I'm not quite sure what you mean by those questions. A function
pointer does not "return" anything. It points at the entry point for a

Well... James... here is the part who, sometimes, make-me delete all
c.l.c inputs on my mail box before read. I love C. It is my favorite
language, and I am always looking for his edges. Still can't find (and
probably will not), but the trip is enough fun.

But every time we are discussing something on c.l.c, we must follow
the standards, thinking, speaking and so on. Well... was my mistake do
not follow that simple rules. ...

Technical jargon serves many purposes, including the ignoble purpose of
separating the in-group and the out-group. However, it's main purpose is
to clearly communicate complex concepts (to members of the in-group).
Jargon wasn't just invented for fun; it was invented because ordinary
English doesn't express the ideas with sufficient precision. (See below
for examples.

>It is commonplace to use the term pointer to mean either a "pointer
object" or a "pointer value", both usages are common in the standard

I can't find any difference between function pointer and variable
pointer

A function pointer points at a function; the function can be called
using that pointer by using the syntax pfunc(), or (*pfunc)(). An object
pointer points at an object; the value represented by that object can be
either accessed or written by using the syntax *pobj. If you don't see a
difference, how do you decide which syntax to use?

... (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use.

I suspect that you actually understand the difference those words
describe; I just think you're unclear about the fact that those words
describe that difference.

The difference is that a pointer object is a piece of memory that
contains the representation of a pointer value. A pointer value can also
occur in a C program without being stored in any object, for example, in
the expression p+3, where p is the name of a pointer variable. The
pointer value p+3 isn't necessarily stored in any object, as that term
is defined by the C standard, it typically resides in a register.

Due to optimization, that pointer value might never be stored anywhere -
p+3 might be combined with some other operation, as in (p+3)->count.
That C code might be translated into machine code which retrieves the
byte address stored in p, and then adds to it, in a single instruction,
the combined values of 3*sizeof *p and the offset of the 'count' member
within the struct pointed at by p.

The distinction between a pointer object and a pointer value is sort of
like the difference between a newspaper article describing a murder, and
the murder described by that article. If you have trouble distinguishing
between those two things, I'd recommend avoiding reading the newspaper
:-). Similarly, if you can't distinguish between a pointer object and a
pointer value, you should avoid pointers (which would make using C a bit
difficult :-).

[vippstar]

On Sep 24, 11:12 am, Nick Keighley <[e-mail]>
wrote:

On Sep 23, 8:33 am, [e-mail] wrote:

Message-ID: <Xzryk.56633$[e-mail] >
Bartc [on another article] said:

I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

I think you're wrong. People *can* use pointers effectivly
without swallowing the standard. They might do a better
job if they fully understood the underlying type system
but not doing so does *not* preclude them from using C
effectivly.

Since you repeated the typo twice, I'd wanted to mention it's
'effectiv*e*ly'.
I think you're wrong, but before we further argue I think it's best to
agree about the meaning of "effective use of pointers", as it's pretty
vague.

The reason I mentioned the type system, is that in another article,
someone asked how to learn pointers.
I replied with something close to "learn the type system, then read
the pointer semantics".
You certainly need to know the type system; if you do, you'll always
know what &p is, **p, the difference between &*p and *&p.
If you know the pointer semantics, you'll always know what operations
can be performed with the pointer.

[Richard]

vi******@gmail.com writes:

On Sep 24, 11:12 am, Nick Keighley <[e-mail]>
wrote:

>On Sep 23, 8:33 am, [e-mail] wrote:

Message-ID: <Xzryk.56633$[e-mail] >
Bartc [on another article] said:
I neither know nor care whether a pointer is a value, variable, type or
object. But that hasn't stopped me using them quite effectively.

I doubt you've used pointers effectively.

I think you're wrong. People *can* use pointers effectivly
without swallowing the standard. They might do a better
job if they fully understood the underlying type system
but not doing so does *not* preclude them from using C
effectivly.

Since you repeated the typo twice, I'd wanted to mention it's
'effectiv*e*ly'.
I think you're wrong, but before we further argue I think it's best to

No surprise there.

But you are wrong. "effective and efficient" use does not need the
knowledge of the standard since a huge % of code is never ported to
other platforms. I dont "support" writing "non standard code"
necessarily but to deny that a practical knowledge of pointers in terms
of memory addresses similar to CPU registers can produce good, stable
efficient code is purely ridiculous.

agree about the meaning of "effective use of pointers", as it's pretty
vague.

The reason I mentioned the type system, is that in another article,
someone asked how to learn pointers.
I replied with something close to "learn the type system, then read
the pointer semantics".
You certainly need to know the type system; if you do, you'll always
know what &p is, **p, the difference between &*p and *&p.

Neither of which have anything to do with the type system of course. e.g
I know what those things are and there's not a type in sight.

If you know the pointer semantics, you'll always know what operations
can be performed with the pointer.

Now I get it. You're just waffling for waffle's sake.

[Trent Josephsen]

Mark L Pappin wrote:

CBFalconer <cb********@yahoo.comwrites:

>I listened to the teacher, and was horrified at the inaccuracies he
was teaching. I resolved I could do better.

So I got to try out my technique. I accurately explained various
things. Then I looked at the class, and was greeted with
dumbfounded looks.

...

>From then on I have been left with admiration for the way the
demonstrating teacher managed to explain things with inaccurate
explanations.

Terry Pratchett, Ian Stewart, and Jack Cohen (in their several
"Science of Discworld" books) describe the technique as "Telling Lies
To Children", where the Lies become incrementally more accurate as the
Children's understanding becomes more complete.

Some Children need particularly blatant Lies and take a while to get
used to revisions, and some refuse to accept later revisions at all.
We see examples of both here.

(Almost) everything I know about pointers, I learned from K&R2.
Obviously this is not a complete understanding, but surely most would
concede that the book does a fine job? As a student, I found the
descriptions of pointers clear, concise, and unambiguous. I can only
presume accuracy, because I haven't read the Standard in its entirety.
(If I am mistaken in presuming that K&R's discussion of pointers is at
least reasonably accurate, I am fully willing to admit it.)

I agree there are times when "Lies" are necessary to build foundational
understanding (take the Bohr model of the atom, which is still taught in
schools). However, I don't think that it's necessary in this context.

[CBFalconer]

soscpd wrote:

>

.... snip ...

>
I can't find any difference between function pointer and variable
pointer (I mean... pointer object and value, sorry). Both point to
some memory location where is some "stuff" you like to use. What
is it, and how you will use it doesn't matter to the pointer. That
is why I am usual to do not mix both subjects (bottle and contents
- ok... here is not exactly bottle. Its more like the place where
the bottle is... endless). I just find that way the best one to
know how to handle pointers.

Well, here is one difference. An object pointer (dereferencable)
needs to point to memory, since that is where the value of the
object is stored. However a function pointer needs to load AND
EXECUTE code. That may well be stored in a shared library, and the
reference is to a location in a file. This is one reason function
pointers and object pointers are not interchangeable; the function
pointer may need much more data.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Tristan Miller]

Greetings.

In article
<3f**********************************@s9g2000prg.g ooglegroups.com>,
Amkcoder wrote:

Every time you declare a pointer space is allocated for it to hold a
value

Oh, really? Perhaps you could explain to us, then, how and where the
system allocates space for the following pointer declaration?

extern int *p;

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= < In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

[Richard]

Tristan Miller <ps********@nothingisreal.comwrites:

Greetings.

In article
<3f**********************************@s9g2000prg.g ooglegroups.com>,
Amkcoder wrote:

>Every time you declare a pointer space is allocated for it to hold a
value

Oh, really? Perhaps you could explain to us, then, how and where the
system allocates space for the following pointer declaration?

extern int *p;

That is declaring that the variable is external. It is not "declaring a
variable" in my view. I'm sure that thats probably over simplified and
breaks something in the standard but there you go.

>
Regards,
Tristan

--

[Keith Thompson]

soscpd <so****@gmail.comwrites:
[...]

But every time we are discussing something on c.l.c, we must follow
the standards, thinking, speaking and so on. Well... was my mistake do
not follow that simple rules. By return, I mean: If you use it, in
some place where you expect the variable value, you will get the value
(please... no to initialization, error and stuff. Consider the utopia
with me, right now. I'm not a C teacher and my goal is not follow the
standards as standards... they are more general guidelines to me),
like:

int *p = malloc(sizeof(int));
p=2;

I assume you meant "*p = 2;".

So... p is a pointer to a memory location of int size?

Right.

After all... the machine job is to go to that location and "return"
the value, if I ask for it.

That's was my return definition in there.

I'm having trouble understanding what you mean. By "my return
definition", I *think* you mean your definition of the word "return",
and I think you're trying to argue that the pointer p can "return" the
value 2. Is that correct?

I suggest that greater precision both in your C and in your English
would serve you well.

Personally, when talking about C, I use the word "return" only to
refer to a value returned by a function (using the "return" keyword),
where as an expression *yields* a value. But ok, if you want to say
that an expression returns a value, that's not too horribly bad. But
in your example, exactly what returns what? Are you saying that the
pointer object p "returns" the value 2? If so, how would you say what
I express as "the expression ``p'' yields a pointer value of type
int*"?

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

[Keith Thompson]

Nick Keighley <ni******************@hotmail.comwrites:

On 23 Sep, 18:21, Richard<[e-mail]:

[...]

>This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address". You address an object
or memory or whatever through it. One representation of that address is
as a value which can be displayed as a hexadecimal memory "address".

this was wrong the first time you said it. It is still wrong.

[...]

Um, how is it wrong?

A pointer is an address; the way the standard defines the terms,
they're nearly synonymous (though I suspect Richard is using the term
"address" in some more hardware-specific way). And it's always
possible to represent a pointer value / address in hexadecimal; even
if "%p" doesn't do this, you can interpret its representation as an
array of unsigned char.

An address is not a number (though it's often implemented that way),
but Richard didn't make that particular claim here.

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

[jameskuyper]

Richard wrote:

Tristan Miller <ps********@nothingisreal.comwrites:

Greetings.

In article
<3f**********************************@s9g2000prg.g ooglegroups.com>,
Amkcoder wrote:

Every time you declare a pointer space is allocated for it to hold a
value

Oh, really? Perhaps you could explain to us, then, how and where the
system allocates space for the following pointer declaration?

extern int *p;

That is declaring that the variable is external. It is not "declaring a
variable" in my view. I'm sure that thats probably over simplified and
breaks something in the standard but there you go.

It doesn't break something, it just doesn't use the jargon correctly.
The standard doesn't use the term "variable". However, that
declaration unambiguously declares the identifier 'p', which is the
name of an object, in exactly the same sense that

int f(int);

declares the identifier 'f', which is the name of a function. if you
accept the definition I'm familiar with (variable = "named object"),
then this means that the declaration declares a variable named 'p'.

What neither statement does is define the thing that the identifier
identifies. If Amkcoder had said "Every time you define a pointer
variable, space is allocated to store its value", he would have been
reasonably accurate There's a big difference between declaring an
identifier and defining the thing that the identifier identifies.

[Richard]

ja*********@verizon.net writes:

Richard wrote:

>Tristan Miller <ps********@nothingisreal.comwrites:

Greetings.

In article
<3f**********************************@s9g2000prg.g ooglegroups.com>,
Amkcoder wrote:
Every time you declare a pointer space is allocated for it to hold a
value

Oh, really? Perhaps you could explain to us, then, how and where the
system allocates space for the following pointer declaration?

extern int *p;

That is declaring that the variable is external. It is not "declaring a
variable" in my view. I'm sure that thats probably over simplified and
breaks something in the standard but there you go.

It doesn't break something, it just doesn't use the jargon correctly.
The standard doesn't use the term "variable". However, that
declaration unambiguously declares the identifier 'p', which is the
name of an object, in exactly the same sense that

int f(int);

declares the identifier 'f', which is the name of a function. if you
accept the definition I'm familiar with (variable = "named object"),
then this means that the declaration declares a variable named 'p'.

What neither statement does is define the thing that the identifier
identifies. If Amkcoder had said "Every time you define a pointer
variable, space is allocated to store its value", he would have been
reasonably accurate There's a big difference between declaring an
identifier and defining the thing that the identifier identifies.

I know. But one does not need to be a genius to know what he meant. or
one to understand what I said.