Good Tutorials

[Amkcoder]

Re: Good Tutorials

On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

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
&integerobje ct
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/aos-f04/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(shor t int));
system("pause") ;
}

[Keith Thompson]

Re: Good Tutorials

Amkcoder <frontal_lobe_d estroyer@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(shor t 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(shor t 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_Keit h) kst-u@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]

Re: Good Tutorials

On Tue, 23 Sep 2008 14:49:28 +0100, Ben Bacarisse
<ben.usenet@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]

Re: Good Tutorials

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_sa me_ 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=mallo c(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=mallo c(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*)ch ar_ptr,(void*)i nt_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_mal loc.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_mal loc.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 smap@spam.cause way.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]

Re: Good Tutorials

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@verizon.net]

Re: Good Tutorials

Amkcoder wrote:

On Sep 23, 10:17 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

....

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]

Re: Good Tutorials

Keith Thompson wrote:

"Bartc" <bc@freeuk.comw rites:
[...]

>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]

Re: Good Tutorials

Hi List

On Sep 23, 2:49 pm, Tony Mc <af...@btintern et.comwrote:

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]

Re: Good Tutorials

soscpd said:

Hi List
>
On Sep 23, 2:49 pm, Tony Mc <af...@btintern et.comwrote:

>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@verizon.net]

Re: Good Tutorials

soscpd wrote:

Hi List
>
On Sep 23, 2:49�pm, Tony Mc <af...@btintern et.comwrote:

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]

Re: Good Tutorials

Amkcoder wrote:

jameskuy...@ver izon.net 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]

Re: Good Tutorials

On Sep 23, 3:22 pm, jameskuy...@ver izon.net 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]

Re: Good Tutorials

CBFalconer <cbfalconer@yah oo.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]

Re: Good Tutorials

Richard<rgrdev@ 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]

Re: Good Tutorials

Tony Mc <afmcc@btintern et.comwrites:

On Tue, 23 Sep 2008 14:49:28 +0100, Ben Bacarisse
<ben.usenet@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.