473,889 Members | 1,394 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 22005
Greetings.

In article <d3************ *************** *****@4ax.com>, Mark McIntyre
wrote:
On Mon, 03 Nov 2003 20:39:39 GMT, in comp.lang.c , Alan Connor
<zz****@xxx.yyy > wrote:

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.


I'm sorry, did you just killfile RJH?


Don't be surprised. Alan Connor, while only a recent appearance here, is a
well-established troll from other newsgroups in the comp.* hierarchy. His
preferred tactic is to loudly denounce some well-established standard or
technique based on his largely incorrect understanding of it, and then
conspicuously fire off plonks to anyone who dares criticize his reasoning.
Often this will be accompanied by fervent promotion of some program he
personally cobbled together to fix the mythical problem. Anyone who points
out the shortcomings or uselessness of this software is accused of
membership in a vast conspiracy for its suppression. I am not making this
up. See, for example, his rants on spam filtering and on PGP signatures in
comp.os.linux.m isc and other groups.

Roose would be better not to make too much of Alan's admiration of him.
(Actually, I'm surprised Alan hasn't already plonked Roose for his repeated
top-posting; he's known to killfile people simply because he thinks their
modest signatures are too long.)

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
Nov 13 '05 #341
Richard Heathfield <do******@addre ss.co.uk.invali d> scribbled the following:
goose wrote:
Mark McIntyre <ma**********@s pamcop.net> wrote in message
news:<j9******* *************** **********@4ax. com>...
BUAATOO, IR.
??

Yeah, that's got me stumped as well.


But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"We sorcerers don't like to eat our words, so to say."
- Sparrowhawk
Nov 13 '05 #342
On 2003-11-07, Christian Bau <ch***********@ cbau.freeserve. co.uk> wrote:
In article <bo**********@e lf.eng.bsdi.com >,
Chris Torek <no****@elf.eng .bsdi.com> wrote:
On a typical RISC we get something like:

mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"


On a PowerPC, you get:
int test (int x) { return x / 4; }

00000000: 7C601670 srawi r0,r3,2 // r0 = r3 >> 2
00000004: 7C600194 addze r3,r0 // r3 = r0 + 0 + carry
00000008: 4E800020 blr // Return


Can someone remind me what the on-topic lesson was? Here's my stab:

* For unsigned integral types, shift vs. multiply/divide by powers
of 2 are equivalent in C.
* For signed integral types, shift vs. multiply/divide by powers
of 2 in C depends on the implementation. If you want strictly
conforming code, you must use divide.

Did I get that right?

-- James
Nov 13 '05 #343
"Roose" <no****@nospam. nospam> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f******** ********@news.n l.net...

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.


Then you also know how unwise it is to teach beginners to assume that
they are equivalent. They might get bitten by this unportable
assumption, and (justly!) blame you for leading them astray.
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.
When you already _have_ non-ISO code which buggers about with pointers
and integers, it is indeed often more efficient to solve only those
cases which cause problems, if only because maintenance programmers are
mortal, too, and can unwittingly introduce new bugs.
However, when you write new code, it is both simpler and more robust to
create code which doesn't make unportable assumptions like that. Needing
to keep track of which integer is supposed to represent which pointer,
and vice versa, is often a source of bugs.
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.


<sound of hilarity from the galeries>
Like the manager doing a dry run before presenting to customers.
We're talking about a _manager_ here, remember. He _will_ test exactly
those parts of the program which don't expose the bugs.
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.
I think it is entirely likely that bugs which are caused by mixing up
pointers and integers in a non-ISO-compatible way will be avoided by
coding in an ISO-compatible way.
As I said, I would prefer to incur the cost of portability when the feature
is needed.


Ah, and there's the crux. I don't think you'll be able to show many
examples of when it is necessary to assume that "a pointer is a kind of
integer" in the first place. In fact, I think you'll be hard pushed to
come up with any at all where that assumption even makes the code more
legible or easier to write, let alone where it's a necessity. If you
think you can, feel free.

Richard
Nov 13 '05 #344
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in
news:bo******** **@oravannahka. helsinki.fi:
Richard Heathfield <do******@addre ss.co.uk.invali d> scribbled the
following:
goose wrote:
Mark McIntyre <ma**********@s pamcop.net> wrote in message
news:<j9******* *************** **********@4ax. com>...
BUAATOO, IR.

??

Yeah, that's got me stumped as well.


But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)


Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!

Ian Woods
Nov 13 '05 #345
James Hu wrote:

On 2003-11-07, Christian Bau <ch***********@ cbau.freeserve. co.uk> wrote:
In article <bo**********@e lf.eng.bsdi.com >,
Chris Torek <no****@elf.eng .bsdi.com> wrote:
On a typical RISC we get something like:

mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"


On a PowerPC, you get:
int test (int x) { return x / 4; }

00000000: 7C601670 srawi r0,r3,2 // r0 = r3 >> 2
00000004: 7C600194 addze r3,r0 // r3 = r0 + 0 + carry
00000008: 4E800020 blr // Return


Can someone remind me what the on-topic lesson was? Here's my stab:

* For unsigned integral types, shift vs. multiply/divide by powers
of 2 are equivalent in C.
* For signed integral types, shift vs. multiply/divide by powers
of 2 in C depends on the implementation. If you want strictly
conforming code, you must use divide.


You can shift right,
if you have a signed type which only receives non negative
values during the program.
I have heapsort function which does that with a ptrdiff_t type.

unsigned char *cbase, *left, *right, *parent, *child;
ptrdiff_t offset;
size_t odd_mask, bytes;

while (compar(child, parent) > 0) {
BYTE_SWAP(paren t, child);
offset = parent - cbase + size;
child = parent;
parent -= (offset & odd_mask ? size + offset : offset) >> 1;
}

--
pete
Nov 13 '05 #346
Richard Heathfield wrote:

Mark McIntyre wrote:
But thats fine - its not a pointer either... :-)

The Standard disagrees with you.


I disagree that it disagrees.
In order to compare p to NULL, you must
convert p to a pointer type (see quote above, plus 6.3.2.3-4).
I'm doubtful that you could convert a null pointer constant
to a pointer type without storing it somewhere....


You make a better case than I thought existed.
Lacking the time right now to
make a detailed study of the matter,
so I hope someone else picks it up.
I'm not quite so doubtful as you are about the conversion.
After all, on some implementations it's a no-op.
Would you suggest that, say, 0 is an object?


The regular conversion rules don't apply to (pointer = 0).
If they did, then (integer = 0, pointer = 0)
would be the same as (pointer = integer = 0).

--
pete
Nov 13 '05 #347
Ian Woods <ne******@wuggy nocaps.org> scribbled the following:
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in
news:bo******** **@oravannahka. helsinki.fi:
Richard Heathfield <do******@addre ss.co.uk.invali d> scribbled the
following:
goose wrote:
Mark McIntyre <ma**********@s pamcop.net> wrote in message
news:<j9******* *************** **********@4ax. com>...
> BUAATOO, IR.

??
Yeah, that's got me stumped as well.


But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)

Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!


Sorry, I don't understand. What's the FARG?

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Bad things only happen to scoundrels."
- Moominmamma
Nov 13 '05 #348
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
"Roose" <no****@nospam. nospam> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f******** ********@news.n l.net...
> 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.

Then you also know how unwise it is to teach beginners to assume that
they are equivalent. They might get bitten by this unportable
assumption, and (justly!) blame you for leading them astray.


Roose must be one of those who believe it is right to teach people to
do things the wrong way first, and then later tell them out of the
blue: "Everything I previously taught you is wrong! Forget all about
it! Do things this way instead!". I can never understand how such
teaching could possibly be more favourable than teaching how to do
things right from the start.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 13 '05 #349
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:
Ian Woods <ne******@wuggy nocaps.org> scribbled the following:
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in
news:bo******** **@oravannahka. helsinki.fi:
Richard Heathfield <do******@addre ss.co.uk.invali d> scribbled the
following:
goose wrote:
> Mark McIntyre <ma**********@s pamcop.net> wrote in message
> news:<j9******* *************** **********@4ax. com>...
>> BUAATOO, IR.
>
> ??

Yeah, that's got me stumped as well.

But Understanding Ain't Always That Object-Oriented, I Remember.
What do I win? =)

Could someone give the FARG a call (if they're still around), we have a new
cognitive-science challenge for them!


Sorry, I don't understand. What's the FARG?


Fluid Analogies Research Group

--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #350

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.