dereference

[Barry Schwarz]

Barry Schwarz wrote:
There are no pointer variables in your code. Go back and start again
from scratch while writing "Arrays and pointers are different objects"
1000 times.

This is something I know because its been drilled into me. But the thing
is I haven't yet caught onto the real meaning yet. For example I know of a

If you don't understand the meaning, how can you possibly claim to
know something? If you really knew arrays and pointers were
different, you would never attempt to assign a value to an array name
as you did in this code from your 24 Aug message:

char p[]="hello world\n";
p==NULL;

That's not an assignment, it's a comparison. The statement

p==NULL;

is perfectly legal, though it's utterly useless.

Absolutely true on both counts. Another reason why those of us with
bad eyes beg for judicial horizontal white space.

(I don't know whether it was *meant* to be an assignment.)

Since Bill responded yes, I claim clairvoyance and responded to his
intent if not his text.

 

[Adrian Ratnapala]

int cbc_crypt(char *key, char *data, unsigned datalen,
unsigned mode, char *ivec)

Notice it is `char *`, not `const char *`. This is a hint that the

[snip]
Would the man page author have done us all a big favor and instead of
calling all the char *'s in this example char key[] for example? Or is this
just me and something I didn't get at first.

Good question, but the answer is: NO! The author got it right.

For example you could do:

char *key = malloc(length_of_the_goddamn_key);

cbc_crypt(key, ...);

 

[Adrian Ratnapala]

Would the man page author have done us all a big favor and instead of
calling all the char *'s in this example char key[] for example? Or is

[snip]
Good question, but the answer is: NO! The author got it right.

I should add, that although this all look like a big subtlety, it isn't. The thing in the man page was probably created by just cut-and-pasting whatever was in the header file. And that's a good thing -- it gives the language-lawyers a canonical source to work with.

And here in this thread, we are language-lawyers. I don't even know if there would be any pracitcal difference had the function prototype said `char key[]`; the only reason I care is that an unusually sharp newbie is asking pointed questions.

 

[Adrian Ratnapala]

char key[] = "some stuff";
In this case the compiler allocates ten bytes on the stack,

Eleven bytes, and not necessarily on the stack.

Correct, if you will beleive it, I remembered the '\0' but forgot the space.

Damn!

Also you are right, it is not necessarily on the stack, it's just somewhere that is safe against multithreading and re-entrant calls. Like all the other local fucking variables.

 

[Hans Vlems]

Depends.

Is there another draw (the centre one perhaps) with a note saying "one
dollar in the right drawer"?

If yes, then nothing
If no, then the dollar turns into free space.

~Andrew- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

No, the dollar remains inside its own (right) drawer. It is not
affected by the operation.

 

[Hans Vlems]

I think the "Nothing" answer was better.  I think the right drawer doesn't have a note saying "one dollar in left drawer".  Rather it has a notesaying "Money, left drawer", where it is previously understood that the *right* drawer contains a treasure map to finding, say, auntie Rohini's life savings.

   typedef int Dollars;
   Dollars rohinis_stash = 1;
   Dollars *treasure_map = &rohinis_stash;

   rohinis_stash = 0;
   assert(treasure_map == &rohinis_stash);  // passes
   assert(*treasure_map == 0); // passes

The pointer in the right draw is unchanged, and still correct, if Rohini empties out the here stash.  What was a pointer to $1 is now a pointer to$0.  A NULL pointer would be if Rohini keeps here money where it is, butreplaces the pointer with a not saying "Money, up your nether hole".

   typedef int Dollars;
   Dollars rohinis_stash = 1;
   Dollars *treasure_map = &rohinis_stash;

   treasure_map = NULL;
   assert(*treasure_map == 1); hopefully segfaults

The right hand drawer is not a pointer. It is simply a location
holding a value.

 

[Nick Keighley]

The right hand drawer is not a pointer. It is simply a location
holding a value.

sounds like a distinction without a difference

 

[Nick Keighley]

That sounds like a null pointer.
char p[]="hello world\n";
p==NULL;

what?

There are no pointer variables in your code.  Go back and start again
from scratch while writing "Arrays and pointers are different objects"
1000 times.

 

[Nick Keighley]

On Saturday, 25 August 2012 15:46:50 UTC+2, Bill Cunningham  wrote:
[regarding "array" is not a pointer"]

    This is something I know because its been drilled into me. But
the thing is I haven't yet caught onto the real meaning yet. For
example I know of a funtion whose prototype is char * but if you put
a string into it the function doesn't work correctly it's called
cbc_crypt(). You have to pass char key[]="string"; to char *key, the
first parameter. Not quite sure why yet but that's the way it works.

That's a really nice example; (warning) I didn't know about
cbc_crypt()
until just now, but I will try to explain it anyway.  My man page
says:

    int cbc_crypt(char *key, char *data, unsigned datalen,
                  unsigned mode, char *ivec);

Notice it is `char *`, not `const char *`.  This is a hint that the
function will be read, and *write* into the buffer.  So one way or
another, `key` must point to writeable memory.

[snip]

    Would the man page author have done us all a big favor and instead of
calling all the char *'s in this example char key[] for example? Or is this
just me and something I didn't get at first.

presumably the author assumed his audience were C programmers

 

[Nick Keighley]

    int cbc_crypt(char *key, char *data, unsigned datalen,
                  unsigned mode, char *ivec)
    Would the man page author have done us all a big favor and instead of
calling all the char *'s in this example char key[] for example? Or is

[snip]
Good question, but the answer is: NO!  The author got it right.

I should add, that although this all look like a big subtlety, it isn't.  The thing in the man page was probably created by just cut-and-pasting whatever was in the header file.  And that's a good thing -- it gives the language-lawyers a canonical source to work with.

And here in this thread, we are language-lawyers.  I don't even know ifthere would be any pracitcal difference had the function prototype said `char key[]`;

no, none.

the only reason I care is that an unusually sharp newbie is asking pointed questions.

Bill? newbie? sharp newbie?!

 

[Nick Keighley]

Depends.

Is there another draw (the centre one perhaps) with a note saying "one
dollar in the right drawer"?

If yes, then nothing
If no, then the dollar turns into free space.

not if you assume drawers are variables. That's the trouble with
strained analogies.

 

[Keith Thompson]

sounds like a distinction without a difference

In the analogy, the drawers are objects, and the note in the left
drawer is a pointer value.

 

[James Kuyper]

On 08/26/2012 05:46 PM, Adrian Ratnapala wrote:
....

... the only reason I care is that an unusually sharp newbie is asking pointed questions.

Bill is not a newbie. He's very carefully (some would say suspiciously)
maintained exactly his current nearly-complete lack of understanding of
C despite having asked frequently asked questions about it for more than
a decade, and having received large quantities of helpful answers to
those questions. The only way he could be considered sharp is if he's
faking his ignorance, which is in fact what many people think he's
doing. I'd like to apply Hanlon's Razor to him, but it's been a long
time since I felt comfortable doing so.

 

[Adrian Ratnapala]

not if you assume drawers are variables. That's the trouble with
strained analogies.

When I read it, I thought of drawers as patches of memory, each untyped, but of big enough store at least a pointer. I don't think that's such a strained analogy.

 

[Adrian Ratnapala]

Bill is not a newbie. He's very carefully (some would say suspiciously)
maintained exactly his current nearly-complete lack of understanding of

Well I have only been hear about a week, so I am the newbie.

C despite having asked frequently asked questions about it for more than
a decade, and having received large quantities of helpful answers to
those questions. The only way he could be considered sharp is if he's
faking his ignorance, which is in fact what many people think he's

Well, I am starting to share this suspicion; I think his questions are genuinely sharp; which makes him look like some kind of white-hat troll trying to increase the educational value of this list.

doing. I'd like to apply Hanlon's Razor to him, but it's been a long
time since I felt comfortable doing so.

Well I suppose the "white-hat" thing might excuse him from "malice".

 

[James Kuyper]

Well I have only been hear about a week, so I am the newbie.



Well, I am starting to share this suspicion; I think his questions are genuinely sharp; which makes him look like some kind of white-hat troll trying to increase the educational value of this list.


Well I suppose the "white-hat" thing might excuse him from "malice".

I've seen nothing to suggest he deserves a "white-hat" designation. His
questions generally reflect a great deal of confusion about the C
language, without being worded in such a way as to shed light on those
points of confusion. The malicious interpretation of his actions is
based upon the assumption that he enjoys seeing people waste their time
trying to explain things to him. He responds with comments saying that
he finally understands, but in those very same messages he says things
making it clear that he does not (except possibly in the negative sense
that he does understand, and deliberately writes his response to suggest
that he does not).

In the past, he's claimed to have a medical condition that requires him
to take drugs which have the side-effect of making it impossible for him
to learn anything. This is the only non-malicious interpretation I've
ever seen for his actions that makes any sense. In that case, it's a
waste of his time to try to learn anything as complicated as C, and it's
a waste of everyone else's time to try to teach it to him. However, by
the same token he's also incapable of learning that it's a waste of his
time (to be fair, some of the people who've been trying to help him seem
equally incapable of learning it). It all holds together logically, but
I've been finding it increasingly difficult to believe.

 

[Adrian Ratnapala]

waste of his time to try to learn anything as complicated as C, and it's

C is not complicated.

 

[James Kuyper]

C is not complicated.

It's more complicated than, for instance, tic-tac-toe, which seems to be
about the most complicated thing I can think of that he could reasonably
be expected to understand, based upon past experience. I'm not saying
he's capable of developing any meaningful strategy while playing the
game, but I do think he's capable of remembering the rules long enough
to play at least one game, possibly several. I would not recommend
assuming that he'll still remember the rules the next day, though he's
likely to claim that he does.

I'm sorry to be so nasty about this, but he's either suffering under a
extremely cruel learning disability, or he's a moderately clever troll.
In the first case my "nasty" description is entirely accurate; in the
second it accurately describes the false front he's been projecting -
either way, I stand by it.

 

[Hans Vlems]

In the analogy, the drawers are objects, and the note in the left
drawer is a pointer value.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

The drawers are storage units i.e. memory locations. The analogy is
quite simple, like the way computers work ;-)