473,842 Members | 1,917 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
> > You're playing childish word games again, Richard. (Did I do this
right?)
You have correctly misinterpreted a perfectly ordinary and unexceptional
statement as a childish word game. Yes, I think you've more or less got

the right idea.
I know this is pointless, but:

----------------
I wrote:

Let's repeat. "Roose" is not a real person. I, Andy, am a real person.
Roose has not posted here before, but I have.

-------------------
Richard wrote:
Let's repeat. "Roose" is not a real person.
I guessed as much. Therefore, any article purporting to be from "Roose" is a
forgery, and should under no circumstances be taken seriously. Certainly no
C advice should be accepted from a non-existent person.
I, Andy, am a real person.
Don't call me Andy. It's not my name. And we know it's not /your/ name,
because your name is Roose, and - by your own admission - you don't exist.
Roose has not posted here before, but I have.


You /are/ Roose, and Roose doesn't exist, remember?

-----------------

Children's games, yes? Or you are simply exceptionally obtuse. I think
this one example will suffice, no need to beat a dead horse.

Roose
Nov 13 '05 #241
Roose wrote:
Children's games, yes?


Not on my account. I have merely answered to what you've written.

If you say silly things, do you really expect an answer that treats those
silly things seriously? If so, wise up.

If you think I've misinterpreted what you've written, write more clearly in
future.

--
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 #242

"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.
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, 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.

As I said, I would prefer to incur the cost of portability when the feature
is needed. Not when writing the program for the first device. When porting
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.

Roose
Nov 13 '05 #243

"Keith Thompson" <ks*@cts.com> wrote in message
news:lz******** ****@cts.com...
"Roose" <no****@nospam. nospam> writes:
If all the structs are part of a single object (e.g., a single chunk
of memory allocated by malloc()), the kind of thing you describe can
be done portably. For each pointer, cast it to char* and subtract the
base address of the enclosing object to get the byte offset of the
object referenced by the pointer.
Good point.

On the other hand, if it's not practical for all your structs to be
part of the same object (e.g., you want to malloc() them individually)
the kind of mapping and serialization you describe would depend on the
details of how malloc() allocates memory. I don't know enough about
the inner workings of typical heap implementations to know whether
this would be practical, but I suspect there's enough variation to
make it difficult.

You mention subtracting the base address; where does this base address
come from?
Suppose they are all structs of the same type that are stored in an array.
Then the base address would be the address of the first object. The whole
collection would be allocated by a single call to malloc.
If non-portable code really is the best solution for your application,
by all means write non-portable code. Wherever possible, keep it
isolated in a small number of modules, and write the majority of your
application as portably as you can. This will make your job easier
when you need to port it to another platform; the code you have to
modify will be small and contained.

I don't think anybody here has claimed that all C code must be
strictly conforming, or that non-portable code is evil. Non-portable
code is sometimes necessary. But I've found that clean code tends to
be portable, and vice versa. If you develop the right habits, writing
portable code really isn't all that difficult. But when you write
code that depends on the characteristics of a particular system,
you've left the scope of this newsgroup, and if you have any questions
about it, you're more likely to get correct answers in a newsgroup
devoted to that system.


I can agree with that, but my impression is that this reasonable stance is
not the one that the majority of those in this newsgroup take.
Can you explain how an error in not writing standard C might result in such a bug?


Not specifically, but imagine a program that operates on a pointer in
a manner that only works if pointers are just integers. When the
program is ported to a system where that's not the case, it generates
pointer values that point to random locations in memory. If it writes
a value through such a pointer, it can clobber some arbitrary
variable. Sometimes this may be harmless, but sometimes, depending on
the circumstances, the result can be drastic.


I undestand this, but again my contention is that such bugs would be quite
obvious. Code that depends on this simply would not work when ported and
tested for this first time. But as a practical matter, there is a large
percentage of systems (if anyone would like to offer a guess, I would be
interested), where you can assume this.

But my larger point stands, that for pedagogical purposes, it is a useful,
concrete statement to say that a pointer is not unlike an array index. An
integer. Yes there can be other bits set, and so forth. But if you were a
C programmer who was NOT aware of this fact, I would seriously question you.

Roose
Nov 13 '05 #244

"Richard Heathfield" <do******@addre ss.co.uk.invali d> wrote in message
news:bo******** **@sparta.btint ernet.com...
Roose wrote:
Children's games, yes?
Not on my account. I have merely answered to what you've written.

If you say silly things, do you really expect an answer that treats those
silly things seriously? If so, wise up.

If you think I've misinterpreted what you've written, write more clearly

in future.


Let me ask what is silly about claiming that I have posted in this newsgroup
with different names before.
Nov 13 '05 #245
Roose wrote:
Let me ask what is silly about claiming that I have posted in this
newsgroup with different names before.


Well, did you really expect anyone to believe you, after your amazingly
clueless entry into the newsgroup?
--
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 #246
Roose wrote:
"Keith Thompson" <ks*@cts.com> wrote in message
news:lz******** ****@cts.com...

I don't think anybody here has claimed that all C code must be
strictly conforming, or that non-portable code is evil. Non-portable
code is sometimes necessary. But I've found that clean code tends to
be portable, and vice versa. If you develop the right habits, writing
portable code really isn't all that difficult. But when you write
code that depends on the characteristics of a particular system,
you've left the scope of this newsgroup, and if you have any questions
about it, you're more likely to get correct answers in a newsgroup
devoted to that system.
I can agree with that, but my impression is that this reasonable stance is
not the one that the majority of those in this newsgroup take.


Then that majority must be silent indeed, or we'd have heard them, surely?
Keith has very nicely outlined a view which I think /is/ representative of
the majority of regular contributors to this newsgroup.
Not specifically, but imagine a program that operates on a pointer in
a manner that only works if pointers are just integers. When the
program is ported to a system where that's not the case, it generates
pointer values that point to random locations in memory. If it writes
a value through such a pointer, it can clobber some arbitrary
variable. Sometimes this may be harmless, but sometimes, depending on
the circumstances, the result can be drastic.


I undestand this, but again my contention is that such bugs would be quite
obvious.


Alas, this isn't necessarily the case.
Code that depends on this simply would not work when ported and
tested for this first time.
But it might, you see - except in certain, rather odd, situations. I don't
have a specific example on this particular subject, but it is by no means
uncommon for people to write code which /always/ works on Processor A, and
/nearly always/ works on Processor B, despite not being "legal" code. When
this happens, faults on the B version of the code may be few and far
between - but they /do/ happen, and finding them can be a nightmare,
especially since you don't know what you're looking for.
But as a practical matter, there is a large
percentage of systems (if anyone would like to offer a guess, I would be
interested), where you can assume this.
Well, you certainly can't assume pointers are integers on at least three of
the desktop systems in my house.
But my larger point stands, that for pedagogical purposes, it is a useful,
concrete statement to say that a pointer is not unlike an array index.


I agree, provided it is suitably qualified. For example, I like to deal with
this subject using a series of successive "approximations ", where it's
clear at each stage that /this/ isn't the right answer, and that one must
read on if one is to get the full picture.

<snip>

--
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 #247
>"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.

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 */

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #248

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.

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
"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. 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. :-)

HTH,
-Arthur
Nov 13 '05 #249

"Richard Heathfield" <do******@addre ss.co.uk.invali d> wrote in message
news:bo******** **@titan.btinte rnet.com...
Roose wrote:
Let me ask what is silly about claiming that I have posted in this
newsgroup with different names before.


Well, did you really expect anyone to believe you, after your amazingly
clueless entry into the newsgroup?


Please do not quote out of context, in an attempt to divert the discussion,
as you have made a recent habit of doing. This is irrelevant to the
question at hand, which is whether my argument was logically consistent.
And whether you refused to acknowledge that it was logically consistent by
playing word games with it.

So, let me suggest that you are the one who "resorts to abuse when you run
out of logic". This hypocrisy thing keeps coming back to bite you.

Roose
Nov 13 '05 #250

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.