"Mastering C Pointers"....

[Richard Heathfield]

"for what its worth", and then ?

"I Understood What Joona Meant."

The J was the clue.

??

Yeah, that's got me stumped as well.

goose,
tia

In my country, that's the name of a drink.

 

[Joona I Palaste]

Yeah, that's got me stumped as well.

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

 

[James Hu]

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

 

[Richard Bos]

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.

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.

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

 

[Ian Woods]

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

 

[pete]

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(parent, child);
offset = parent - cbase + size;
child = parent;
parent -= (offset & odd_mask ? size + offset : offset) >> 1;
}

 

[pete]

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

 

[Joona I Palaste]

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

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.

 

[Irrwahn Grausewitz]

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

Fluid Analogies Research Group

 

[Programmer Dude]

Being killfiled by such people is like having your car registration
number written down in an eight-year-old car-spotter's notebook as
you pass under the trollbridge at seventy mph. You don't actually
notice the event all that much, and it certainly doesn't affect
your life, but it makes /his/ day, and that's what matters.

Heh. Good analogy!

Pretty much exactly what *I* thought when *you* killfiled me.

 

[Mike Wahler]

Alan Connor wrote:

[Richard Heathfield]

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

You are making a huge mistake. Richard is a frequent posters, a textbook
author and a well-respected member of this newsgroup.

Roose, on the other hand, is a troll who willing dispenses erroneous
information and replies with flames when challenged.

I suggest you reverse your decision. Killfile Roose, do not do the same
with Richard.




Brian Rodenborn

Why do you assume that I lack both eyes and common sense?

No assumptions are necessary. Your posts and Richard's serve
as concrete evidence for Brian's conclusion.

Richard and a few others have done almost nothing but attack Roos since
the thread began.

They have originally attacked the incorrect information, which
is a valuable pursuit in any technical forum. Perhaps they
have later 'attacked' Roose himself, but that is only in response
to personal attacks which *he* initiated. Read the thread.

That's the only troll-like behavior I have seen here.

You sir, obviously don't know what a troll is.

Everything Roos has told me has been verified by my research on the
Net and with local docs.

The 'Net' and 'local docs' do not determine correctness of
assertions about the C language. The *only* source for such
determination is the C langauge standard, ISO 9899.

Roos has been helpful,

I found his 'advice' to be quite harmful, *especially* for the
novice, who won't know that his statements are incorrect.

much more so than Richard (although that one post
was indeed excellent)

Were I to rank the usefulness and correctness of the articles
of the regulars here, Richard would certainly occupy one of the
top ten positions, perhaps the top five.

Richard's buddies have mostly posted material that's way over my head

The fact that you don't understand something makes it useless?
Perhaps it might initially, but you know you *can* ask for further
explanation, clarification, elaboration, etc, don't you?

I've often seen a novice write that he did not understand something
an 'expert' wrote, who asked for further clarification, and *got it*,
to his satisfaction. Whereupon the expert was *thanked*, not *attacked*
as Roose does.

and
just confuses me if I let it.

Exactly, 'if you let it'. If you don't understand something, continue
to ask questions, read books, etc.. I suspect even the great Heathfield
uses this method.

At least Roos knows that a novice doesn't know the lingo yet.

And avoiding the correct technical terms only serves to perpetuate
the ignorance of the novice.

Yet you are telling me the opposite is true.

As am I.

We'll see. But trolling gets anyone killfiled for a while.

Regardless of the 'diplomacy' or accurateness of Richard's articles,
they certainly do not represent trolling. The posts by Roose and
yourself represent trolling.

I don't care
if it's being done by Dennis Ritchie.

And we don't care what you care about.

Bye now.

-Mike

 

[Mike Wahler]

I really don't like watching people masturbate in public.

Killfiled for 60 days.

Oh dear, I'm sure that now Randy is in tears. I'd best hurry
over with a tissue and comfort him.

-Mike

 

[Programmer Dude]

Top posting, on the other hand, makes it a real pain for everyone..

No, not everyone. I have no problem with it whatsoever. My brain
has little trouble figuring out the conversation, and if the thing
is really screwed up, I can easily Go Ogle the orginals (assuming
they aren't available on the local server).

Top posting offers the *advantage* of giving me a peek at what the
poster has to say immediately. All the easier for me to determine
if the post is worth reading.

For example, most news readers (even OE) allow you to page through
messages on a group by just hitting the space bar. With bottom
posting this works, but if a message is top posted then to see the
context you have to page down though the post...

Bah. Every newsreader I've ever used had a single keystroke that
meant "go to next post".

So ALL the arguments against top posting are still valid.

Nonsense. It's more an attempt to control the environment. Good
on you if you can pull it off, but don't assume it's a mandate or
The One True Way.

It's just A Way.

 

[Mike Wahler]

That's better for you. Not better for a newbie. I would love to see some
beginner ask you about C programming, and you start blathering on about
lvalues.

"Way back when", when I was first learning C, the 'discovery' of
and subsequent understanding of lvalues, was a great day and
was a *huge* help in my understanding of the language.

And this 'discovery' was 'stumbled' upon, during the quest for
a specific answer about something else. The fact that I was
actually looking for something else did not cause me to disregard
the valuable information I'd just acquired.

Just a thought....


-Mike

 

[Mike Wahler]

And all the people that ARE, are doing nothing but confuse me.

IOW, "Truth confuses me. Thus I reject it, in favor of untruth,
which I do understand."

-Mike

 

[Richard Heathfield]

Heh. Good analogy!

Pretty much exactly what *I* thought when *you* killfiled me.

Oh, I'd forgotten about that. Well, my motivation was slightly different. I
could think of no better way to indicate the strength of my feeling on the
matter at hand. I must admit I was hoping you'd be sufficiently concerned
by it to re-examine the issue, but obviously that never happened. And, of
course, I eventually had to unplonk you because, in /technical/ discussions
about programming, I value your contribution so highly. It seems that we
are fated to be on opposite sides of non-programming discussions, though.

 

[Lew Pitcher]

Lew Pitcher wrote:




Surely you mean "cranking /in/ the data"?
>
Data is (or are!) what you put into a computer. What it cranks out is
information. Well, that's the general idea, anyway.

So, what name do you give to the results that come out of one computer to go
into another computer?

Let me guess: "a file".

<grin>

From "Websters New Dictionary and Thesaurus", (c) 1990

data n pl (now often with sing verb) facts, statistics, or information
either historical or derived by calculation or experimentation.

It seems that "data" is another word for "information", meaning that both of
us are correct: data goes in and information (aka data) comes out.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Jim Showalter]

That's completely unfair. You could just as well paint Richard with the
same brush.

This is transparent character assassination. Do you think we are stupid?

Stupid is an understatement. The odds that two imbeciles would discover
one another on c.l.c are so great, that I think it much more likely that
"Alan Connor" is an invention of "Roose"!

 

[Alan Connor]

Stupid is an understatement. The odds that two imbeciles would discover
one another on c.l.c are so great, that I think it much more likely that
"Alan Connor" is an invention of "Roose"!

I'm happy for you. Now shut the **** up and get the hell out of my life
you stupid punk.

killfiled for 90 days. The other post goes unread.