dereference

[Hans Vlems]

Ok I read Kenneth Brody's post. I guess the difference is the pointer and
what it's pointing at.

Bill

Imagine two drawers in a cabinet. The right drawer contains a one
dollar note. The left drawer contains a note that says "one dollar
note in right drawer".
The content of the left drawer points to the right drawer. Only the
right drawer holds the real thing (the money).
Hans

 

[Bill Cunningham]

Using GC, if I remove the note from the left drawer, what happens to
the money in the right drawer?

Nothing ?

Bill

 

[Bill Cunningham]

Using GC, if I remove the note from the left drawer, what happens to
the money in the right drawer?

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

 

[Andrew Cooper]

Using GC, if I remove the note from the left drawer, what happens to the
money in the right drawer?

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

 

[Adrian Ratnapala]

the money in the right drawer?

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 note saying "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, but replaces 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

 

[Barry Schwarz]

Using GC, if I remove the note from the left drawer, what happens to
the money in the right drawer?

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

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.

 

[Bill Cunningham]

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

Bill

 

[Vincenzo Mercuri]

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

All you need to know is explained here:
http://c-faq.com/aryptr/index.html

 

[Vincenzo Mercuri]

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

I read your post in comp.unix.programmer, you also
need to read this: http://c-faq.com/decl/strlitinit.html

I'd suggest to read all the FAQ, of course

 

[Adrian Ratnapala]

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.

If we try:

int main(void)
{
char *key = "some stuff";

 

[Vincenzo Mercuri]

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.

[..]

You probably meant that the *key* will be read and written into a buffer.
So, from this point of view, it's the buffer that needs to be writable,
not the `key'. However, in this case in particular, the only reason why
he also needs the key to be writable is because the *crypt() functions
are usually preceded by a call to `des_setparity()' which sets the key's
parity. But `cbc_crypt()' itself would work just fine even if `key' was
not modifiable. But this is not topical here

 

[Adrian Ratnapala]

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.

[..]



You probably meant that the *key* will be read and written into a buffer.

`key` points to the buffer. The buffer must be writeable, therefore `key` must point to writeable memory. But you are quite right; what I wrote could be misunderstood to mean that the pointer itself had to be writeable. Thanks for the clarification.

 

[Les Cargill]

Using GC, if I remove the note from the left drawer, what happens to
the money in the right drawer?

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

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.

Would the terms "l-value" and "r-value" be of any use here?

 

[Barry Schwarz]

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;

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.

If you insist on taking big bytes without chewing your food, you
really shouldn't be surprised when you choke on something. Stop
playing with functions you don't understand until after you master the
basics.

 

[Ike Naar]

char key[] = "some stuff";

In this case the compiler allocates ten bytes on the stack,

Eleven bytes, and not necessarily on the stack.

and initialises them with "some stuff\0".

No, it initializes them with "some stuff", the string constant already
includes the terminating null char. "some stuff\0" would be 12 bytes
long and have two null chars at the end.

These bytes are an array of type `char[10]`.

No, char[11],
[0] 's'
[1] 'o'
[2] 'm'
[3] 'e'
[4] ' '
[5] 's'
[6] 't'
[7] 'u'
[8] 'f'
[9] 'f'
[10] '\0'

 

[Bill Cunningham]

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.

Bill

 

[Keith Thompson]

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.

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

 

[Keith Thompson]

Adrian Ratnapala wrote: [...]

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.

"char key[]", as a parameter declaration, means exactly the same thing
as "char *key". C doesn't even have parameters of array type.

 

[Bill Cunningham]

"char key[]", as a parameter declaration, means exactly the same thing
as "char *key". C doesn't even have parameters of array type.

Oh. OK. My bad.

Bill

 

[Bill Cunningham]

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

Yes.