473,842 Members | 1,837 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

"Mastering C Pointers"....

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

sincerely ... Andy
Nov 13 '05
388 21968
Mark McIntyre <ma**********@s pamcop.net> writes:
On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.hel sinki.fi> wrote:
Mark McIntyre <ma**********@s pamcop.net> scribbled the following:
On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
<pf*****@mindsp ring.com> wrote:
int a;
&a;

(&a) is a pointer, but not an object.

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .


This depends on the definition of a "pointer".


As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.


Not everyone uses the word that way. By analogy, the phrase "an int"
or "an integer" can refer either to an object of type int or to a
value of type int.

We're not going to settle the question of what "a pointer" is, so
whenever there's any ambiguity I suggest referring to "a pointer
object" or "a pointer value".

Hmm. I just noticed that the standard's definition of "value" is
"precise meaning of the contents of an object when interpreted as
having a specific type" (3.17). On the other hand, a constant (such
as 42) is said to have a value: "The value of a constant shall be in
the range of representable values for its type." (6.4.4 p2), even
though there's no object associated with it. This looks like an
inconsistency. If so, I'll take it up in comp.std.c.

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #301
Mark McIntyre <ma**********@s pamcop.net> writes:
On Wed, 5 Nov 2003 01:46:39 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@addre ss.co.uk.invali d> wrote:
int i = 6;
int * const p = &i; /* p is not a variable - or at least, to persuade
anyone that it is, you'd have to have kissed the Blarney. */


Actually p is a variable. It merely happens to have an immutable
value. :-)


Since the standard doesn't define the word "variable", I would
hesitate to use it to refer to something that isn't able to vary.

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #302
On Wed, 05 Nov 2003 21:57:18 +0000, Joona I Palaste wrote:
Mark McIntyre <ma**********@s pamcop.net> scribbled the following:
On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
<pf*****@mindsp ring.com> wrote:
int a;
&a;

(&a) is a pointer, but not an object.

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .


This depends on the definition of a "pointer". Is it a value or a
variable?


Maybe it's necessary to differentiate between what a pointer is in
source code and what a pointer is in an executable or running
program.

For example, Richard says "NULL is most definitely a pointer" but
the standard says in 6.3.2.3#3:

"An _integer_ constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant."

and then

"If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is ..."

Which strongly implies that a null pointer constant is not a pointer,
but a null pointer is. Of course, as Keith pointed out, a null pointer
constant is a syntactic construct that doesn't exist in an executable
program.

Similarly, (&a) is an expression with type "pointer to type of a", but
in an executable program, won't necessarily exists as either an object
or an explicit value.

Nov 13 '05 #303
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote:
On Wed, 5 Nov 2003, Irrwahn Grausewitz wrote nonsense.
No, that one was ROSY. Google "spoke ur nose"... :-)
Indeed. Somehow goose's email address sneaked into me mind.
My only excuse being somewhat confused at the moment.
-Arthur,
maybe it *is* best not 2 spoke my nose on this matter


<g>
--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #304
Keith Thompson wrote:

Mark McIntyre <ma**********@s pamcop.net> writes:
On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.hel sinki.fi> wrote:
Mark McIntyre <ma**********@s pamcop.net> scribbled the following:
> On Wed, 05 Nov 2003 01:46:09 GMT, in comp.lang.c , pete
> <pf*****@mindsp ring.com> wrote:
>>int a;
>>&a;
>>
>>(&a) is a pointer, but not an object.

> I disagree. (&a) in that context is an expression. To be a pointer, it
> would have to be stored in something. .

This depends on the definition of a "pointer".


As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.


Not everyone uses the word that way. By analogy, the phrase "an int"
or "an integer" can refer either to an object of type int or to a
value of type int.

We're not going to settle the question of what "a pointer" is, so
whenever there's any ambiguity I suggest referring to "a pointer
object" or "a pointer value".

Hmm. I just noticed that the standard's definition of "value" is
"precise meaning of the contents of an object when interpreted as
having a specific type" (3.17).


I've been wondering about the meaning of the word "value"
and the meaning of the phrase "meaning of a value".

N869
6.2.5 Types
[#1] The meaning of a value stored in an object or returned
by a function is determined by the type of the expression
used to access it."

In the above description of types,
it seems to me that "value" is being used to mean bit pattern.

The meaning of "rvalue", in the language called "B",
was "a binary bit pattern of a fixed length".
http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html

When I use the word "value", I'm usually thinking of
the interpretation of the bit pattern according to type,
as in (3.17), quoted above.
I was thinking that the same object can have different values
depending on how the object is accessed.
But the description of types, says that the same value can have
different meanings depending on how it's accessed,
which is a different meaning for "value" than the one given in (3.17)

--
pete
Nov 13 '05 #305
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******** *************** ***********@uni x44.andrew.cmu. edu...

On Wed, 5 Nov 2003, nobody wrote:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote...

To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expression s of pointer
type." I don't think the Standard assigns any meaning to the
noun "pointer" itself, except as a kind of shorthand for
"object of pointer type" or "expression of pointer type." Just
like it doesn't make sense to speak of "a short int;" you can
speak of "an object of type 'short int'" or "a value of type
'short int'," but they're two different things whose only
commonality is their type.
Above "pairing" fails for "strings", which I believe can attribute for
often mistakes of (mis)handling them (e.g. not allocating memory
for them, or calling strstr() on "binary" data returned from socket,
as can be often? witnessed in questions posted here).
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again?


I would say, "yes, you're wrong." :-) There is no such thing as
a "value of type 'string'," for the simple reason that C doesn't
*have* a type 'string'. What C has is a type 'array of char',
which may under some circumstances *hold* a string.

Thanks for an answer. I did it again. I know exactly what you mean,
I just never can word it correctly. That is probably why everyone
who is more knowledgeable, simply uses term "string", as you above,
without any attributes (like 'type', 'value', 'object' and what-not).
I would be interested under which circumstances 'array of char'
*can't* hold a string (I mean, in principle, not if length exceeds size).
That is, the "string" is a kind of "meta-value" affected by all
the values of the elements of the char array. If the array
contains a null character, then it contains a "string." But
to avoid confusion [;-)] I do not consider arrays to have "values"
by themselves. The individual *elements* of an array can have
values, and the name of the array certainly has a value when
used in a value context, but the "array" itself... no. Not by
my way of categorizing things.
Is string value *and* object
at the same time and they are just identical, without "dichotomy"
of other types?
char *foo = "hello";
char bar[6] = "world";

'foo' is an object of type 'pointer to char'. Its value is the
address of the first element of the anonymous object "hello", which
itself is of type 'array[6] of char'. 'foo' points to a string.
'bar' is an object of type 'array[6] of char', and its elements
have the values 'w', 'o', [...], '\0' respectively. 'bar' holds
a string.

See, I never once referred to any "object of type string" or


That is true, but in paragraph above you wrote 'object "hello"'.
I know all this about arrays and pointers (in this specific case, my
problem is terminological) , but "hello" from above is obviously
a string. Is string an object? [:-)] Do you see my difficulties
with proper terminology? Maybe you wanted to write something
different, maybe not. I'm always looking for some 'qualifier' when
talking about strings. It appears none of them are 'valid' (in terms
of standardese). Except maybe 'string literal'. *Than* I know
what I'm talking about. Maybe I'm looking for something what
doesn't exist. String is a string and that's it.
"value of type string," because such things don't exist. There
is no *type* "string" in C.
(That's why I try to avoid to use term "string" when
dealing with C and beginners, unfortunately to the point when
I've recently misleadingly stated /but fortunately was corrected/
that strings don't exist in C
I think (and hope) if you'd said that C doesn't have a string
*type*, you would have been correct.


No. I meant 'string *type*', but actually said "doesn't have a string".
(I know, I know, I should think before posting.)
Kind of like C doesn't
have language support for many OOP concepts, but anyone who
flatly claims that you can't do OOP in C will get death-by-
sample-code. :-)
<ot> Is there any fitting idiom in English
for that? Something like "falling into one's own trap" ? </ot>).


"Hoist by [one's] own petard." Etymology something involving
dynamite, so I've heard. :-)

Thanks.
Nov 13 '05 #306

On Thu, 6 Nov 2003, nobody wrote:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote...
On Wed, 5 Nov 2003, nobody wrote:
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote...
>
> To be really clear (which I suppose one must), one should really
> speak of "objects of pointer type" and "expression s of pointer
> type." Above "pairing" fails for "strings", [...]
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again?
I would say, "yes, you're wrong." :-) There is no such thing as
a "value of type 'string'," for the simple reason that C doesn't
*have* a type 'string'. What C has is a type 'array of char',
which may under some circumstances *hold* a string.


Thanks for an answer. I did it again. I know exactly what you mean,
I just never can word it correctly. That is probably why everyone
who is more knowledgeable, simply uses term "string", as you above,
without any attributes (like 'type', 'value', 'object' and what-not).
I would be interested under which circumstances 'array of char'
*can't* hold a string (I mean, in principle, not if length exceeds size).


Well, okay, I suppose I could have said, "which *does* under some
circumstances hold a string." The word 'may' in English has two
meanings: sometimes it means 'can' and sometimes it means 'might':

Mother said that I may go to the candy shop today. [or "can"]
^^^
Mother said that she may go to the candy shop today. [or "might"]
^^^

I intended to mean "might." Under some circumstances which *might*
arise, an array can hold a string. Under *other* circumstances, an
array might *not* hold a string -- namely, if the array doesn't
contain a terminating null character.
<pedantry>
But see this interesting point by Dan Pop in another recent
thread for one reason why what I just wrote is wrong:
http://groups.google.c om/gr************* ************@su nnews.cern.ch
</pedantry>

char *foo = "hello";
char bar[6] = "world";

'foo' is an object of type 'pointer to char'. Its value is the
address of the first element of the anonymous object "hello", which
itself is of type 'array[6] of char'. 'foo' points to a string.
'bar' is an object of type 'array[6] of char', and its elements
have the values 'w', 'o', [...], '\0' respectively. 'bar' holds
a string.

See, I never once referred to any "object of type string" or


That is true, but in paragraph above you wrote 'object "hello"'.
I know all this about arrays and pointers (in this specific case, my
problem is terminological) , but "hello" from above is obviously
a string.


Yup. "hello" is the string stored in the anonymous array pointed
to by 'foo'.
Is string an object?


Nope. A string is not an object.

"hello" in the above code is also a string literal. 'String
literal' is a compile-time, source-level concept. The Standard
defines exactly what a 'string literal' is, and you can look it
up yourself. :-) Basically, it's a bunch of junk in between
double quotes.

<pedantry>
As the Standard points out, not all string literals are
strings. For example, "abc\0def" is a string literal, but not
a string. But then again, in a value context that string
literal decays into a pointer that *does* point to a string --
the string "abc"!
</pedantry>

HTH,
-Arthur

Nov 13 '05 #307
"Chris Torek" <no****@elf.eng .bsdi.com> wrote in message
news:bo******** **@elf.eng.bsdi .com...
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******* *************** ************@un ix47.andrew.cmu .edu...
To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expression s of pointer
type." ...

(Yes. Left in just to establish context.)

In article <dV************ *******@twister 01.bloor.is.net .cable.rogers.c om>
nobody <no****@nowhere .non> writes:
Above "pairing" fails for "strings", which I believe can attribute for
often mistakes of (mis)handling them (e.g. not allocating memory
for them, or calling strstr() on "binary" data returned from socket,
as can be often? witnessed in questions posted here).
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again?


In C, the term "string" really refers to a data *format*, rather
than anything in the type, value, object, etc., sense.

Thank you. This was the wording I couldn't quite put my finger on.
"data format".
Suppose I were to tell you that I have a set of (binary) files
in which each "record" is a variable-length region prefixed by
two eight-bit bytes giving the length of the record in big- or
little-endian format (i.e., I tell you which byte to multiply
by 256 before adding the other, to get the length). You then
find the record length by doing:

c1 = getc(fp);
c2 = getc(fp);
if (c1 == EOF || c2 == EOF) ... handle trouble and/or EOF ...
len = c1 * 256 + c2; /* if big-endian */
len = c2 * 256 + c1; /* if little-endian */
Wouldn't left shift be better? Or are today's compilers "smart" enough
to do this kind of stuff themselves? /*Someone had mentioned this
possibility earlier (particular case was multiplication by 2).*/
Having done this, you can now read the record -- which is "len"
bytes long -- or skip over it using fseek(), for instance.

What I have done is describe a data format for the file. As long
as you have a valid starting point from which to read the file's
records, you can read through all the records in the file, and
detect a "short read" if the file ends too soon (in the middle of
a record, or with c2==EOF but c1!=EOF in the above code).

A C string is just a data format in memory -- simpler than the
record format in this file, because there is no leading count to
interpret, but a data format nonetheless. You could write a sequence
of strings to a binary file and then read them back by reading
bytes until you find each '\0' -- each such set of bytes is a
"string" in the file.
Is string value *and* object at the same time ... ?


Since a string is a data format, you must store it in some other
data object. A sequence of bytes ending with a '\0' will fit in
*any* C object of sufficient size (due to C's requirement that all
objects break down into a sequence of "unsigned char" bytes), but
the most suitable is a sufficiently large array of char (or unsigned
char, in some special circumstances).

Among other things, this means that you can -- nonportably, but
perhaps tested at compile time -- store 7-or-fewer-character C
strings in "double"s, as long as sizeof(double) >= 8 (as is fairly
typical). But you must then use considerable care never to access
those "double"s as lvalues of type "double", since the bit patterns
created by strings might be reserved when treated as ordinary
"double", and cause a runtime trap. (Modern IEEE-fp machines in
particular will trap "signalling NaNs" if the NaN trap is enabled.)
This is thus the kind of code one should only use in an "obfuscated
C" contest.

Thanks.
Nov 13 '05 #308
"Roose" <no****@nospam. nospam> wrote in message
news:2d******** *****@newssvr14 .news.prodigy.c om...

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f******** ********@news.n l.net...
"Roose" <no****@nospam. nospam> wrote:
_That_ exact bug? No, obviously not, since Keith already said that that
scenario was a spur-of-the-moment invention. However, some bugs can be
pretty arcane, and only show up under unusual circumstances. For
example, search the Jargon File for "phase of the moon".

For an example where assuming that "integer" is equivalent to "pointer"
leads to a bug, assume that a pointer is six bytes and the best
available integer four.
I'm aware of the pitfalls of assuming pointers are integers. However, I'd
say that when porting non-ANSI code from a platform to where they are
"equivalent " to one where they are not, that you'd simply do well to know
your hardware, and thus this fact would stick out like a sore thumb.

Point of writing conforming code is that you *don't* have "well to know
your hardware". Sane people prefer freedom from such details given to
them by standartized abstraction. That is not to say that they don't know
those details. Sane people prefer not to have sore thumbs sticked in
their eyes.
Suppose, also, that for normal users, including developers, their
address space is in the lower part of the spectrum, so that they'll
never encounter the situation where a pointer converted to an integer
overflows, which means that for them, converting a (small) pointer to an
integer and back again apparently works.
Now suppose that your manager, who never uses the program but wants to
demonstrate it to a customer, happens to have a wheel bit set, causing
his address space to be in the upper reaches of memory, which means that
in his case the higher-order bytes of his pointers are _not_ all zero,
unlike the usual case...


I'm not too familiar with wheel bits,


Thanks to God Almighty. Otherwise there would be another endless
"discussion " why it's good to use them, so later on "this fact would stick
out like a sore thumb", but that would be OK, because "then you will
incur the cost, and not a particularly great one". BTW, I've got no idea
what they (wheel bits) are, but AFAIK they are not mentioned in the
standard, and I'm not going to pretend that I'm "not *too* familiar" with
them, just in case :-) it's made-up term.
but I would suggest that this bug
could quickly found out by any rudimentary testing. Like the manager doing a dry run before presenting to customers. It depends on the specifics of
course, but I think it is a stretch to think that such errors are likely to produce rare bugs that could have only been avoided if the code were ANSI C in the first place.
It's not a stretch This kind of bugs (as described above and creation of
whose you are advocating /*assume equivalence of pointer and integer*/)
*would* have been avoided by adherence to the standard. *That's* why
it is good thing to write ANSI C code (among other things).
As I said, I would prefer to incur the cost of portability when the feature is needed.
No one is preventing you from doing it. However, you shouldn't try that
hard to convince newbies that the opposite "simply isn't necessary
engineering practice" and to change focus of this NG.
Not when writing the program for the first device. When porting
And I thought you are writing (C-like) programs *for* customers,
to make money for your company ("Thus, in the business world, it is
not considered good practice, since time = money", "ones that actually
generate money", "Do we have standard C code now that we ported it?
No.Do we need to? Not really, the products sold more than 1.5 million
copies and generated millions of dollars in profits").
to the second device, you will have specific hardware differences to
examine. And then you will incur the cost, and not a particularly great one in my experience.

Would you incur such cost out of your pocket? Why not to avoid
associated cost (when possible)? Just because *company* will pay for
it? Ultimately, it's customers who are paying it.
Nov 13 '05 #309
Ben Pfaff wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
On 5 Nov 2003 21:57:18 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.hel sinki.fi> wrote:
>This depends on the definition of a "pointer".
As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.


See my post elsethread for why that's a bad definition.


And mine (although I admit I'll have to go another round with Mark, since he
seems to think that a null pointer isn't a pointer).
Mornington Crescent.


I have no idea what that means. Is it a breakfast food?


Ah, welcome to British culture.

"Mornington Crescent" is a joke on "I'm Sorry I Haven't A Clue", a Radio 4
'comedy' quiz program. The contestants (always the same four, I think, so
really they're members of the cast - Tim Brooke-Taylor and Graeme Garden of
"The Goodies", one of Barry {Humphries|Crye r}, and some other bloke)
pretend to follow a set of complicated rules whilst taking turns to name
London Underground (subway) stations. The joke, which has worn rather thin
over the hundred years or so that the show has been running (and it's still
starring the original cast), is that there are in fact no rules whatsoever.

I understand I may have broken some kind of cabalistic law by revealing this
fact, so if I don't post any more after today, you'll know why.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #310

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.