address change

[aarklon]

Hi all,

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

now my question is is there a round about way to do this in
C....??????

 

[vippstar]

Hi all,

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

Certainly is.

now my question is is there a round about way to do this in
C....??????

Do what? You can't change the lvalue of an object.

 

[Philip Potter]

Hi all,

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

now my question is is there a round about way to do this in
C....??????

What are you trying to do? And why?

Variables cannot be re-seated. A variable ties a name to a location. If
you wish to do something like this, you may need a pointer type:

int a=19;
int b=94;

int *x=&a;
/* now *x is the same as a */

x = &b;
/* now *x is the same as b */

Memory addresses cannot be directly entered into portable C code.
Integers cannot be converted to pointer types [1]. Your implementation
may provide a way of doing this, but it is not universal. Why do you
want to do this?

Philip

[1] with the two exceptions of 0, which needn't be converted to memory
address 0 at all, and the value of an intptr_t that was previously
generated from a pointer type.

 

[Chris Dollin]

Hi all,

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

now my question is is there a round about way to do this in
C....??????

(a) No.

(b) No, not even if you replace the integer `1789` with an address.

(c) Why do you want to do this?

(d) For some answers to (c), you may be able to imitate what you want
by judicious use of pointers; `x` would likely become a pointer-to-int,
you'd use `*x` not `x` mostly, and then your assignment would be
`x = newAddress`. But only for /some/ answers to (c).

(e) There is no (e).

 

[aarklon]

What are you trying to do? And why?

just experimenting with things, to learn more about c

[1] with the two exceptions of 0, which needn't be converted to memory
address 0 at all, and the value of an intptr_t that was previously
generated from a pointer type.

what does intptr_t mean???
what is it's purpose ???
is it defined in stddef.h ????

i have seen ptrdiff_t but not this one

 

[Philip Potter]

just experimenting with things, to learn more about c

Always a commendable goal.

[1] with the two exceptions of 0, which needn't be converted to memory
address 0 at all, and the value of an intptr_t that was previously
generated from a pointer type.

what does intptr_t mean???
what is it's purpose ???
is it defined in stddef.h ????

It's not directly related to the problem at hand; I mentioned it as an
exception to the general rule I stated.

intptr_t is a C99 integer type which is enables you to convert pointers
to integers and back again. I have never used it, and I have never seen
it used, though I'm sure it has been somewhere. It is an optional type,
so portable code won't rely on it.

 

[santosh]

What are you trying to do? And why?

just experimenting with things, to learn more about c

[1] with the two exceptions of 0, which needn't be converted to
[memory
address 0 at all, and the value of an intptr_t that was previously
generated from a pointer type.

what does intptr_t mean???
what is it's purpose ???
is it defined in stddef.h ????

It is defined in stdint.h and thus is C99 specific.
Roughly speaking any pointer to void can be converted to intptr_t or
uintptr_t and when converted back to a pointer to void, will compare
equal to the original pointer.

See section 7.18.1.4 of n1256.

 

[Keith Thompson]

Memory addresses cannot be directly entered into portable C
code. Integers cannot be converted to pointer types [1]. Your
implementation may provide a way of doing this, but it is not
universal. Why do you want to do this?

[1] with the two exceptions of 0, which needn't be converted to memory
address 0 at all, and the value of an intptr_t that was previously
generated from a pointer type.

Correction: integers can always be converted to pointer types (in most
cases, this requires an explicit cast). The result of such a
conversion is guaranteed to be meaningful only in the cases you
mention; in other cases, the result is implementation-defined, and may
invoke undefined behavior (for example, if the resulting pointer is
not correctly aligned).

 

[CBFalconer]

(e-mail address removed) wrote:

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

now my question is is there a round about way to do this in
C....??????

What are you trying to do? And why?

just experimenting with things, to learn more about c

[1] with the two exceptions of 0, which needn't be converted to
[memory address 0 at all, and the value of an intptr_t that was
previously generated from a pointer type.

what does intptr_t mean???
what is it's purpose ??? is it defined in stddef.h ????

It is defined in stdint.h and thus is C99 specific.
Roughly speaking any pointer to void can be converted to intptr_t
or uintptr_t and when converted back to a pointer to void, will
compare equal to the original pointer.

See section 7.18.1.4 of n1256.

Note the last sentence of the following quote:

7.18.1.4 Integer types capable of holding object pointers

[#1] The following type designates a signed integer type
with the property that any valid pointer to void can be
converted to this type, then converted back to pointer to
void, and the result will compare equal to the original
pointer:

intptr_t

The following type designates an unsigned integer type with
the property that any valid pointer to void can be converted
to this type, then converted back to pointer to void, and
the result will compare equal to the original pointer:

uintptr_t

These types are optional.

i.e. they may not exist at all.

 

[ais523]

Hi all,

consider this,

int x=19;
now &x = 1789; /*this is illegal in c*/

now my question is is there a round about way to do this in
C....??????

The only circumstances I can think of for doing this is when you're
writing nonportable code that needs to access memory directly. Some
compilers have their own directives for doing this; there's no
guaranteed portable way to do this, because it's a nonportable thing
to do to begin with, but the method I use is

#define x (*(int*)1789) /* I'd actually write the memory location in
hexadecimal */

This method doesn't give you a variable x, but such a concept would be
dubious anyway. Your line

int x=19;

is equivalent to

auto int x=19; /* nobody ever uses auto because it's everywhere either
forbidden or default */

which tells the compiler to find storage for x that lasts until it
goes out of scope; so if you place it in a function that calls itself
recursively, there have to be two different xs in the different
invocation. You appear to be trying to place them both at memory
location 1789, which contradicts the semantics of auto, as well as
being nonportable. Causing a static variable to be placed at a
particular memory location would be more reasonable (and I've come
across a compiler for a language which strongly resembled C which had
a #pragma to do it (although it violated various parts of the
standards, for instance it had an 8-bit int by default)), but still
inadvisable unless you know what you're doing and are willing to write
nonportable code, and there's no syntax that can be used to portably
do that. The #define method is about as portable as the dubious
operation of writing to fixed memory locations is anyway, and protects
you from doing things like trying to declare a variable in a fixed
memory location as auto; it does have problems with scoping, but those
can be partially reduced using #undef if you really need to (but
having such values program-wide has been useful the few times I've
wanted to use it).

If you're not trying to access a fixed memory location (that operation
only makes sense on microcontrollers and in other situations where
you're trying to interface with hardware directly rather than go
through the parts of an implementation that make code portable), what
are you trying to do?

 

[Ben Bacarisse]

Your line

int x=19;

is equivalent to

auto int x=19; /* nobody ever uses auto because it's everywhere either
forbidden or default */

which tells the compiler to find storage for x that lasts until it
goes out of scope;

At the risk of seeming overly picky I'd point out that the link
between lifetime and cope is more subtle than that. The lifetime of
an automatic variable[1] extends from the time when execution enters
the block with which it is associated to the time when execution of
the block ends. Calling a function will, in the terminology of the
standard, suspend the execution of the block -- the names of the
automatic variables go out of scope but the variables continue to
exist.

To further illustrate the messy link, the exact (and seemingly
deliberate) wording makes the following program well-defined and
makes it print 42:

#include <stdio.h>

int main(void)
{
int *ip = 0;
start:
if (ip) {
printf("%d\n", *ip);
return 0;
}
int i = 42;
ip = &i;
goto start;
}

The variable 'i' is accessed (via a pointer) in a part of the block
where the name 'i' is not in scope but the lifetime of the variable
must exist from the time execution enters the block of main.

[1] that does not have variable length array type.