Information on Double pointers

[agni.suresh896]

Hi i am currently working on Snmp related project. I want to know deep
concepts of "pointers" so if any one provide me information related to
datastructures and pointers i am very happy.

Thanks and regards
agni

 

[Zoran Cutura]

Hi i am currently working on Snmp related project. I want to know deep
concepts of "pointers" so if any one provide me information related to
datastructures and pointers i am very happy.

Well, how about this. A pointer is a pointer because it points to
something.
That's probably as deep as a concept can be when it comes to pointers.

You shouldn't try to learn the C programming language (or any other
programming language) from a newsgroup. If you have any specific
questions on pointers or the anything else concerning the language ask a
specific question here. But if you need to learn the basics you're
better off by grabbing your favorit text book and learn 'em from that.

 

[pete]

Well, how about this. A pointer is a pointer because it points to
something.

A null pointer is a pointer that doesn't point to anything.

 

[Jean-Claude Arbaut]

Le 14/06/2005 12:59, dans (e-mail address removed), « pete »

A null pointer is a pointer that doesn't point to anything.

It points to a very strange zone that thou shall not try to read ;-)

BTW, on a PowerPC you can avoid the usual "zero" segment, I suppose
you can then access the NULL pointer like any other. Just a security,
not a necessity, but the Standard won't agree I fear.

 

[DeltaOne]

Sorry Pete,Null pointer is not a pinter that points to nothing,but it
points to some memory location from where a software interrupt can be
generated.

 

[Chris Dollin]

Sorry Pete,Null pointer is not a pinter that points to nothing,but it
points to some memory location from where a software interrupt can be
generated.

No.

A null pointer need not point to *any* memory location.

 

[Kenneth Brody]

A null pointer is a pointer that doesn't point to anything.

I believe it would be "more correct" to say that a NULL pointer "points
to nothing", rather than "doesn't point to anything".

long *foo = ((long *)main) + 1;
long *bar = NULL;

While bar is a NULL pointer, foo is a pointer which doesn't point to
anything.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Jean-Claude Arbaut]

Le 14/06/2005 16:35, dans (e-mail address removed), « Kenneth Brody »

I believe it would be "more correct" to say that a NULL pointer "points
to nothing", rather than "doesn't point to anything".

long *foo = ((long *)main) + 1;
long *bar = NULL;

While bar is a NULL pointer, foo is a pointer which doesn't point to
anything.

I disagree... foo points in the executable code, and you may have
good reasons to read or write it, even if it's not portable or
not well defined by the Standard. On a PowerPC architecture, it would
point exactly on the second instruction of main. I agree the Standard
IS important, but actual programs are important, too. It would be
possible to do *foo=0x60000000 (write a NOP) for example.

 

[Clark S. Cox III]

I believe it would be "more correct" to say that a NULL pointer "points
to nothing", rather than "doesn't point to anything".

long *foo = ((long *)main) + 1;
long *bar = NULL;

While bar is a NULL pointer, foo is a pointer which doesn't point to
anything.

foo is undefined behaviour, as such, it very well might point at something.

 

[Clark S. Cox III]

Le 14/06/2005 16:35, dans (e-mail address removed), « Kenneth Brody »


I disagree... foo points in the executable code,

You simply don't know that.

and you may have
good reasons to read or write it, even if it's not portable or
not well defined by the Standard.

It is completely undefined by the standard.

On a PowerPC architecture, it would
point exactly on the second instruction of main. I agree the Standard
IS important, but actual programs are important, too. It would be
possible to do *foo=0x60000000 (write a NOP) for example.

While platform specific implementations of undefined behaviour may
indeed be important, they are off-topic here.

 

[john_bode]

I believe it would be "more correct" to say that a NULL pointer "points
to nothing", rather than "doesn't point to anything".

I usually describe it as pointing to a well-defined "nowhere"; IOW, a
specific value that doesn't correspond to any valid location.

 

[Jean-Claude Arbaut]

Le 14/06/2005 17:28, dans 2005061411281116807%clarkcox3@gmailcom, « Clark S.

While platform specific implementations of undefined behaviour may
indeed be important, they are off-topic here.

So the god "Standard" ignores all implementations ;-) Ok, I understand.

 

[Eric Sosman]

Le 14/06/2005 17:28, dans 2005061411281116807%clarkcox3@gmailcom, « Clark S.



So the god "Standard" ignores all implementations ;-) Ok, I understand.

The God does not ignore implementations; the God abstracts
them. That is the great benefit the God brings to His chosen
programmers, that is, to those who obey His Commandments and
in particular the Tenth:

Thou shalt foreswear, renounce, and abjure the vile
heresy which claimeth that "All the world's a VAX",
and have no commerce with the benighted heathens who
cling to this barbarous belief, that the days of thy
program may be long even though the days of thy
current machine be short.

-- http://www.lysator.liu.se/c/ten-commandments.html

The God is powerful but not quite all-powerful. He has not
abstracted all features of all implementations, for the Idols
of Idiosyncrasy (whose worshippers call them "Innovators") are
numerous and prolific. Nor are all His abstractions as pleasant
to use as they might have been had not the twin demons of Custom
and Compromise marred His holy work at every turn. The result
is that even His most devoted disciples are now and then lured
from the strait and narrow way by the Tempter called Expediency.
Yet the God is merciful, forgiving the occasional transgression
if the sinner truly repents and solemnly swears never to do it
again, responding in the sacred chant:

"What, never?"
"No, never!"
"What, never?????"
"We-e-e-ll, hardly ever."

But just as the God's power is not infinite, neither is His
mercy. The apostate who flouts the Commandments for the sheer
nastiness of it, the idolator who worships the Little Tin God
above all others, the heretic who recites spells to invoke the
dread demon Undefined Behavior -- all these shall be condemned
to the Pit, where they shall be afflicted by bugs until the End
of the Infinite Loop. Do not be among their number! Strive to
mend thy ways, and when thou slippest (as thou shalt, being but
an imperfect mortal), take no delight in thy slippage but recall
just how bad things were before the Great Prophet Ansi proclaimed
the coming of the new Day.

 

[Jean-Claude Arbaut]

Le 14/06/2005 19:05, dans [email protected], « Eric

The God does not ignore implementations; the God abstracts
them. That is the great benefit the God brings to His chosen
programmers, that is, to those who obey His Commandments and
in particular the Tenth: [...]
the coming of the new Day.

I said I understood Ok, I woulnd't like to be treated as a troll,
so a last question and I stop: what do you think of programs like
ATLAS (and maybe gmp, or Linux kernel) ? Are there Standard means
to check/set IEEE 754 flags ? to prefetch data in case the compiler
has no clue where it is best done ? or to use SIMD instructions
on some architectures ? Do I need to write my programs in full
assembly to avoid hurting His Holiness ?

My personnal feeling, for what it's worth:
* Standard is usefull and necessary for 90% of programs (at least)
* For the next 10%, just forget the Standard and make things run fast
and accurate.

No flame me, no problemo

 

[Lawrence Kirby]

Sorry Pete,Null pointer is not a pinter that points to nothing,

A null pointer is a pointer that simply does not point. It is an error to
attempt to make it point i.e. to dereference it.

but it
points to some memory location from where a software interrupt can be
generated.

You're confusing how the language is defined with how a particular
implementation might work. There is no requirement that a null pointer
point at a memory location, on some implementations it doesn't i.e. a
value that doesn't correspond to the address of any valid memory location.
On other implementations it does but it cannot be the address of any valid
object in the program. However you cannot assume this in standard C code.

Lawrence

 

[Gordon Burditt]

long *foo = ((long *)main) + 1;

I disagree... foo points in the executable code, and you may have
good reasons to read or write it, even if it's not portable or
not well defined by the Standard. On a PowerPC architecture, it would
point exactly on the second instruction of main. I agree the Standard
IS important, but actual programs are important, too. It would be
possible to do *foo=0x60000000 (write a NOP) for example.

PowerPC allows you to write on executable code? That's widely
recognized as a security problem for an OS/platform on any platform.

Gordon L. Burditt

 

[Jean-Claude Arbaut]

PowerPC allows you to write on executable code? That's widely
recognized as a security problem for an OS/platform on any platform.

The linker enforces r-x right on executable segment, *by default*, but
it's easy to set rwx rights. And you're right, it's a well known security
concern. I don't know if one can change the rights during execution, though.

 

[Michael Wojcik]

Le 14/06/2005 16:35, dans (e-mail address removed), « Kenneth Brody »


I disagree... foo points in the executable code, and you may have
good reasons to read or write it, even if it's not portable or
not well defined by the Standard. On a PowerPC architecture, it would
point exactly on the second instruction of main.

This is incorrect. On *some* PowerPC architectures, foo might point
to "the second instruction of main" (a concept outside C, but perhaps
pertinent to the implementation). On the AS/400, however, which is a
PowerPC (variant) architecture, it most certainly will not, and you
will not be able to dereference it for any purpose, because the C
implementations for the AS/400 do not permit this sort of nonsense.

There are implementations other than your own, and making assumptions
about how all implementations behave (such as "foo points in the
executable code") based on how yours behaves is not only a poor
practice (since it leads to incorrect code) but sloppy thinking. The
existence of PowerPC architectures that do not behave as you believe
they behave is only one case in point.

 

[Jean-Claude Arbaut]

Le 16/06/2005 15:59, dans (e-mail address removed), « Michael Wojcik »

This is incorrect. On *some* PowerPC architectures, foo might point
to "the second instruction of main" (a concept outside C, but perhaps
pertinent to the implementation). On the AS/400, however, which is a
PowerPC (variant) architecture, it most certainly will not, and you
will not be able to dereference it for any purpose, because the C
implementations for the AS/400 do not permit this sort of nonsense.

I didn't know that, sorry. I should have written "for some PPC arch"

There are implementations other than your own, and making assumptions
about how all implementations behave> (such as "foo points in the
executable code") based on how yours behaves is not only a poor
practice (since it leads to incorrect code) but sloppy thinking.

I ***NEVER*** said or thought that !!!!!!!
What I say, however, is that one may have good reasons to program
for a particular machine. People who wrote your AS/400 Operating
System needed to take its peculiarities into account. Denying
that *is* poor practice and sloppy thinking.

The
existence of PowerPC architectures that do not behave as you believe
they behave is only one case in point.

I know at least another: Macintosh, but with MacOS9/PPC, not MacOSX.
CFM programming is considerably different.

 

[Michael Wojcik]

Le 16/06/2005 15:59, dans (e-mail address removed), « Michael Wojcik »


I didn't know that, sorry. I should have written "for some PPC arch"


I ***NEVER*** said or thought that !!!!!!!

foo points in the executable code, and you may have
good reasons to read or write it, even if it's not portable or
not well defined by the Standard. On a PowerPC architecture, it would
point exactly on the second instruction of main.

"foo points in the executable code" is an implicit assumption about
how all implementations behave; "On a PowerPC architecture..." is
an explicit assumption about how all PPC implementations behave.

If those weren't your assumptions, you should have made that more
clear.

What I say, however, is that one may have good reasons to program
for a particular machine.

Agreed, but that doesn't justify making general claims about how
nonstandard constructs work.

People who wrote your AS/400 Operating
System needed to take its peculiarities into account. Denying
that *is* poor practice and sloppy thinking.

I don't recall ever arguing otherwise on either of these points. And
I'm not sure how the implementation of OS/400 (which is not in C, for
the most part) is relevant.

My point is quite simple: a statement on comp.lang.c like "foo points
in the executable code" is wrong. In a particular implementation it
may be true, but in the general case it is not, so it is no more
correct than, say, "cars are black".