Change address of pointer

[Ramon]

Hi,

How can I change the address of a pointer? Please look at the code
below. What I'm trying to do is to make c = &cell (without using this
notation of course). How can I assign the address of /cell/ (which is
stored in the variable /addr/) to the pointer named /c/??

// cell is a struct
Cell *cell = (Cell *) malloc(sizeof(Cell));

// getting the address of the mem location of the object
unsigned int addr = (unsigned int) &cell;

// changing the address of the new pointer to point to the
// 'cell' object
Cell *c = ??? <-- make c point to the address addr

Thanks.

 

[Donkey Hottie]

25.10.2009 17:34, Ramon kirjoitti:

Hi,

How can I change the address of a pointer? Please look at the code
below. What I'm trying to do is to make c = &cell (without using this
notation of course). How can I assign the address of /cell/ (which is
stored in the variable /addr/) to the pointer named /c/??

// cell is a struct
Cell *cell = (Cell *) malloc(sizeof(Cell));

// getting the address of the mem location of the object
unsigned int addr = (unsigned int) &cell;

// changing the address of the new pointer to point to the
// 'cell' object
Cell *c = ??? <-- make c point to the address addr

Thanks.

Cell *c = *((Cell**)addr) ;

 

[BGB / cr88192]

Hi,

How can I change the address of a pointer? Please look at the code below.
What I'm trying to do is to make c = &cell (without using this notation of
course). How can I assign the address of /cell/ (which is stored in the
variable /addr/) to the pointer named /c/??

// cell is a struct
Cell *cell = (Cell *) malloc(sizeof(Cell));

(personally, I find this style distasteful, but oh well...).
well, that and many compilers will refuse to accept it (for example, MSVC,
which apparently is based mostly on a slightly older C standard, where
initializers need to be constant...).

// getting the address of the mem location of the object
unsigned int addr = (unsigned int) &cell;

// changing the address of the new pointer to point to the
// 'cell' object
Cell *c = ??? <-- make c point to the address addr

you realize though that on many archs, such as x86-64, this will blow up
(one needs a 64-bit integer type instead), ...

c=*(Cell **)addr;

where addr holds address of the pointer to the cell.


another had suggested intptr_t, which works well apart from assuming (at
least partial) C99 support from the compiler.

sadly, I don't know of anything clearly better (apart from maybe declaring a
custom type, and using lots of #ifdef's and friends to set it up so that it
is the correct size for a given archictecture, ...).

 

[Ben Bacarisse]

How can I change the address of a pointer? Please look at the code
below. What I'm trying to do is to make c = &cell (without using this
notation of course). How can I assign the address of /cell/ (which
is stored in the variable /addr/) to the pointer named /c/??

There is a bigger question buried in all this. What are you really
trying to do? Why do you think you are forced to go outside of the
type rules of C (see below). Can you outline what you are doing and
why you think the fragment below is your best shot at doing it?

// cell is a struct
Cell *cell = (Cell *) malloc(sizeof(Cell));

I prefer

Cell *cell = malloc(sizeof *cell);

// getting the address of the mem location of the object
unsigned int addr = (unsigned int) &cell;

All bets are now off! This conversion is implementation defined and
might produce garbage. C99 (the newest standard) says that if there
is an unsigned int type that can hold a pointer it will be called
uintptr_t and you can get it by using #include <stdint.h>.

The danger in this conversion is a very real one. For example, on my
rather ordinary laptop your code does not work at all.

Why do you need to do this? The address of cell can be taken whilst
staying inside C's type system:

Cell **addr = &cell;

You can even use void * here if you really need to forget about the
type of the pointer (though you should do that only if you need to).

// changing the address of the new pointer to point to the
// 'cell' object
Cell *c = ??? <-- make c point to the address addr

You've had an answer which might fit what your needs (*(Cell **)addr)
but it is possible that you need to be asking another question!

Some of your wording is little ambiguous -- there is no point in
making c "point to the address addr" because that would make c
useless. addr contains a (possibly invalid) integer version of a
pointer to a pointer to a cell so you can make c "point to the cell
pointed to by the pointer in addr" which is what *(Cell **)addr does.

 

[Ben Bacarisse]

cell is a pointer to a struct Cell.

Small point: we don't know if it is a struct or not, though I agree
that is more than likely.

 

[Keith Thompson]

(personally, I find this style distasteful, but oh well...).
well, that and many compilers will refuse to accept it (for example, MSVC,
which apparently is based mostly on a slightly older C standard, where
initializers need to be constant...).

[...]

Initializers for static objects need to be constant. Local variables
can be initialized with any arbitrary expression. This didn't
change from C90 to C99.

 

[Phil Carmody]

Anyone interested in C, skip this post, it's nothing but a flame.



Ben didn't write precisely that - 'below' was on the same line as 'code'.

Ditto, 'of' was on the same line as 'notation'.

And 'the' was on the same line as 'in'.

Note to OP - this style of comment can get mangled by people's
newsreaders unnecessarily re-wrapping long lines, as seen above.
So it's better to stick to /* these style */ comments to be safer.
(Oh, bugger, that's vaguely C related, and not a flame.)

Erm, and we didn't need to see Ben's sig again - trim it.

And that's your sole original contribution at this point, is it?
You mess up Ben's formatting, unnecessarily quote his signature,
and then do nothing apart from adding two blank lines? Please
learn to control your newsreader.

Phil

 

[Keith Thompson]

Anyone interested in C, skip this post, it's nothing but a flame.


Ben didn't write precisely that - 'below' was on the same line as 'code'.

Ditto, 'of' was on the same line as 'notation'.
[snip]

And that's your sole original contribution at this point, is it?
You mess up Ben's formatting, unnecessarily quote his signature,
and then do nothing apart from adding two blank lines? Please
learn to control your newsreader.

Phil, I routinely reformat quoted English text, as do many other
people here. Unless there some deliberate layout (say, if it's
poetry), I don't consider line break placement to be part of the
text, and I feel free to re-fill paragraphs as convenient.

If you mentioned this to make a point about // comments, perhaps
you could have done so more directly.

 

[Phil Carmody]

Anyone interested in C, skip this post, it's nothing but a flame.

How can I change the address of a pointer? Please look at the code
below.

Ben didn't write precisely that - 'below' was on the same line as 'code'.

What I'm trying to do is to make c = &cell (without using this notation
of

Ditto, 'of' was on the same line as 'notation'.
[snip]

And that's your sole original contribution at this point, is it?
You mess up Ben's formatting, unnecessarily quote his signature,
and then do nothing apart from adding two blank lines? Please
learn to control your newsreader.

Phil, I routinely reformat quoted English text, as do many other
people here. Unless there some deliberate layout (say, if it's
poetry), I don't consider line break placement to be part of the
text, and I feel free to re-fill paragraphs as convenient.

Do you think that quoting signatures is good form?
Do you think that posting otherwise-blank responses is sensible
usenet behaviour?

The 'lines' count increased from something like 28 to 33.
I was expecting at least a few lines of new content from it.
But no - firstly no reduction due to the sig, then two blank
lines, and just as a cherry on top there's the unnecessary
reformatting.

If you mentioned this to make a point about // comments, perhaps
you could have done so more directly.

Not everything I post is ironic. I thought I was perfectly
direct about the fact that the post was not interested in
addressing matters of C. I fail to imagine how *anyone* can
misunderstand that.

Phil

 

[Keith Thompson]

Do you think that quoting signatures is good form?
Do you think that posting otherwise-blank responses is sensible
usenet behaviour?

No, and no. Did I suggest otherwise?

The 'lines' count increased from something like 28 to 33.
I was expecting at least a few lines of new content from it.
But no - firstly no reduction due to the sig, then two blank
lines, and just as a cherry on top there's the unnecessary
reformatting.


Not everything I post is ironic. I thought I was perfectly
direct about the fact that the post was not interested in
addressing matters of C. I fail to imagine how *anyone* can
misunderstand that.

I didn't misunderstand that.

Let me make my point again. Reformatting paragraphs of quoted
English text is common and harmless (and sometimes necessary to keep
quoted text down to a reasonable line length). 99% of the time I
don't even notice it, and when I do notice it I'm grateful if it
makes the quoted text easier to read. Complaining about something
totally harmless distracted from the valid points you were making.

 

[Peter Nilsson]

25.10.2009 17:34, Ramon kirjoitti:
You can't. You can change the address a pointer points to
though.

You don't need that crap.

Cell *c = *((Cell**)addr) ;

<sigh>

Cell *c = cell;

 

[BGB / cr88192]

(personally, I find this style distasteful, but oh well...).
well, that and many compilers will refuse to accept it (for example,
MSVC,
which apparently is based mostly on a slightly older C standard, where
initializers need to be constant...).

[...]

Initializers for static objects need to be constant. Local variables
can be initialized with any arbitrary expression. This didn't
change from C90 to C99.

ok, I thought both cases needed to be constant in C90...

either way, I don't generally initialize with non-constant expressions as
personally I regard this practice as ugly (likewise, I feel that all
declarations belong at the top of a function, and prefer to keep them sorted
in particular orders WRT types and properties, ...).

 

[Ramon]

C99 (the newest standard) says that if there
is an unsigned int type that can hold a pointer it will be called
uintptr_t and you can get it by using #include <stdint.h>.

Thx, did not know about uintptr_t

The danger in this conversion is a very real one. For example, on my
rather ordinary laptop your code does not work at all.

Why do you need to do this?

What I was trying to do is a linked list with direct 'location' access.
To solve the problem of direct access, I was thinking to implement a
sort of hash table. I don't know if you have ever programmed in
assembly on 8086... Well basically the interrupts in an 8086 used to be
stored as list of addresses, each address represents the respective
interrupt routine. To get the address of an interrupt routine, the
processor used to multiply the interrupt number by 4, thus direct access.

So, I tried to use that concept in order to implement a direct access
linked list, i.e. allocate a chunk of memory that is used to store the
addresses instances of cell. I know that there may be an infinite
number of ways to implement this, but I just tried to the "integer"
addresses of the cell structures... just like the interrupt system of an
8086 CPU.

 

[Phil Carmody]

Thx, did not know about uintptr_t


What I was trying to do is a linked list with direct 'location'
access. To solve the problem of direct access, I was thinking to
implement a sort of hash table. I don't know if you have ever
programmed in assembly on 8086... Well basically the interrupts in an
8086 used to be stored as list of addresses, each address represents
the respective interrupt routine. To get the address of an interrupt
routine, the processor used to multiply the interrupt number by 4,
thus direct access.

So, I tried to use that concept in order to implement a direct access
linked list, i.e. allocate a chunk of memory that is used to store the
addresses instances of cell. I know that there may be an infinite
number of ways to implement this, but I just tried to the "integer"
addresses of the cell structures... just like the interrupt system of
an 8086 CPU.

The reason that works in the x86 IVT is because the addresses are all
contiguous. The interrupt numbers are nothing but an index into that
table. If you're going to make your allocated memory contiguous (so
allocate an array), then you can also use an integer to index its
elements.

Phil

 

[Ben Bacarisse]

Thx, did not know about uintptr_t

OK, but remember that this is not the right way to do what you want in
C.

What I was trying to do is a linked list with direct 'location'
access. To solve the problem of direct access, I was thinking to
implement a sort of hash table. I don't know if you have ever
programmed in assembly on 8086... Well basically the interrupts in an
8086 used to be stored as list of addresses, each address represents
the respective interrupt routine. To get the address of an interrupt
routine, the processor used to multiply the interrupt number by 4,
thus direct access.

So, I tried to use that concept in order to implement a direct access
linked list, i.e. allocate a chunk of memory that is used to store the
addresses instances of cell. I know that there may be an infinite
number of ways to implement this, but I just tried to the "integer"
addresses of the cell structures... just like the interrupt system of
an 8086 CPU.

It is not always good idea to take a solution to one problem
(organising low-level interrupt addresses) and apply it to an
unrelated one (linked lists). At least the two are unrelated as far
as I can see, but I don't understand what you are hinting at with
"direct 'location' access". At first glance, that just sounds like
an array, not a list.

 

[James Kuyper]

Phil Carmody wrote:
....

Do you think that quoting signatures is good form?
Do you think that posting otherwise-blank responses is sensible
usenet behaviour?

I think that it is something that occasionally happens as a result of
accidentally hitting the wrong button while preparing to respond to a
message. In itself, it doesn't deserve the flames you've spent on it,
unless it was clearly intentional.

 

[James Kuyper]

BGB / cr88192 wrote:
....

either way, I don't generally initialize with non-constant expressions as
personally I regard this practice as ugly (likewise, I feel that all
declarations belong at the top of a function, and prefer to keep them sorted
in particular orders WRT types and properties, ...).

I have almost exactly the opposite preference. I think that the best
location for declaring a variable is the one that gives it the smallest
scope that is consistent with performing the task that it is intended to
perform, without going out of my way to create a scope specifically for
that variable.

If the function is big enough that searching for the declaration is
difficult, then I prefer to keep that search as short as possible, by
defining each variable as close as possible to it's point of use. I have
not found the "declare everything at the start of the function" approach
very effective for such purposes.

I think that it's bad design to give a variable a value before it can be
given a value that will actually be used, and if the first such value is
the result of a non-constant expression, so what?

 

[Stefan Ram]

I have almost exactly the opposite preference. I think that the best
location for declaring a variable is the one that gives it the smallest
scope that is consistent with performing the task that it is intended to
perform, without going out of my way to create a scope specifically for
that variable.

Why not?

{ .
.
.
{ int const original_alpha = alpha; alpha = beta; beta = original_alpha; }
.
.
. }

What is wrong the scope specifically for »original_alpha« here?

 

[James Kuyper]

Why not?

{ .
.
.
{ int const original_alpha = alpha; alpha = beta; beta = original_alpha; }
.
.
. }

What is wrong the scope specifically for �original_alpha� here?

It's a matter of taste, judgment, and programming style, more than
anything else, and I would not insist on it as an absolute rule.
However, my own coding style would require that each of the three
statements in that block be put on a separate line, so that I can single
step through the code if I need to go into debug mode. Those lines would
have to be indented by at least 4 spaces from the brackets defining the
bounds of that block. The extra level of indentation is one of the key
things I want to avoid; but I also prefer to avoid increasing the number
of levels of nested blocks, even if indentation were not an issue.