Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   address change (http://www.velocityreviews.com/forums/t556997-address-change.html)

aarklon@gmail.com 12-03-2007 03:16 PM

address change
 
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@gmail.com 12-03-2007 03:26 PM

Re: address change
 
On Dec 3, 5:16 pm, aark...@gmail.com wrote:
> 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 12-03-2007 03:28 PM

Re: address change
 
aarklon@gmail.com wrote:
> 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 12-03-2007 03:30 PM

Re: address change
 
aarklon@gmail.com wrote:

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

--
Christophr "Jams" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN


aarklon@gmail.com 12-03-2007 03:44 PM

Re: address change
 
On Dec 3, 8:28 pm, Philip Potter <p...@doc.ic.ac.uk> wrote:
> aark...@gmail.com wrote:
> > 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?


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 12-03-2007 04:33 PM

Re: address change
 
aarklon@gmail.com wrote:
> On Dec 3, 8:28 pm, Philip Potter <p...@doc.ic.ac.uk> wrote:
>> aark...@gmail.com wrote:
>>> 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?

>
> 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 12-03-2007 04:34 PM

Re: address change
 
aarklon@gmail.com wrote:

> On Dec 3, 8:28 pm, Philip Potter <p...@doc.ic.ac.uk> wrote:
>> aark...@gmail.com wrote:
>> > 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?

>
> 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 12-03-2007 08:14 PM

Re: address change
 
Philip Potter <pgp@doc.ic.ac.uk> writes:
[...]
> 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).

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

CBFalconer 12-03-2007 11:13 PM

Re: address change
 
santosh wrote:
> aarklon@gmail.com wrote:
>> Philip Potter <p...@doc.ic.ac.uk> wrote:
>>> aark...@gmail.com 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.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com


ais523 12-05-2007 12:08 PM

Re: address change
 
On Dec 3, 3:16 pm, aark...@gmail.com wrote:
> 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?

--
ais523


All times are GMT. The time now is 02:08 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.