Convert pointer address to integer then back to a pointer address
Diego Acevedo
convert a pointer address to an integer, but how do you convert back to
a pointer after sorting so as to re-queue the pointers?
int* fooptr;
int a[10];
for (int i = 0; i < 10; i++)
{
fooptr = PtrFromQueueArray();
a[i] = (uint32_t) fooptr;
}
qsort(a, 10, sizeof(int), compareFunc);
Should I have used a struct to store the pointer address as well as the
converted pointer inside the QueueArray?
Thanks in advance!
Diego
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Barry Schwarz
<diegoa...@worldnet.att.net> wrote:
>I am trying to sort an array of pointers to int. My method was to
>convert a pointer address to an integer, but how do you convert back to
>a pointer after sorting so as to re-queue the pointers?
There is no need to convert the pointers to integer. compareFunc can
be coded to determine whether pointer-1 is less than, equal to, or
greater than pointer-2 directly.
>
>int* fooptr;
>int a[10];
>
>for (int i = 0; i < 10; i++)
>{
> fooptr = PtrFromQueueArray();
> a[i] = (uint32_t) fooptr;
Since a[i] is an int and not necessarily the same as a unit32_t, this
cast is a problem waiting to happen. Either change the cast to match
the type of a[i] or change the type of a so the cast is correct.
To answer your question anyway, if this does what you want, then
chances are that
fooptr = (int*)a[i];
will result in fooptr having its original value.
>}
>
>qsort(a, 10, sizeof(int), compareFunc);
>
>Should I have used a struct to store the pointer address as well as the
>converted pointer inside the QueueArray?
I would go with my first suggestion.
Remove del for email
Hans-Bernhard Bröker
> I am trying to sort an array of pointers to int.
Before you go on, you should ask yourself whether that's actually a sane
thing to be trying to do. Pointers aren't generally ordered, i.e.
sorting them by value isn't supported by the language. For all you
know, all pointers could be magic objects that have no numeric, sortable
value at all.
> My method was to convert a pointer address to an integer,
First problem: you don't know if an int is big enough to store a
pointer. You should use uintptr_t where available, uintmax_t otherwise.
> but how do you convert back to
> a pointer after sorting so as to re-queue the pointers?
You don't, and you don't have to. You can just compare the pointer
values directly. That's not officially supported by the language
either, but the odds that it'll work anyway are at least as good as
those that the result of casting pointers to integer types will preserve
any ordering.
Andrei Voropaev
> I am trying to sort an array of pointers to int. My method was to
> convert a pointer address to an integer, but how do you convert back to
> a pointer after sorting so as to re-queue the pointers?
Well, you don't need any conversion. Though all of this stuff is
implementation specific. Without going much into standards etc, on linux
there's header stdint.h, this header defines the type uintptr_t, this
type can fit the pointer on your system. Then to treat a pointer as an
unsigned integer you just typecast it to uintptr_t. Example
void * a, * b;
if((uintptr_t)a > (uintptr_t)b)
{
}
In case of array void * a[10] you can typecast it to (uintptr_t *)a.
Hm, to understand all of this you just need to understand how the
variables are represented in RAM. Knowing something about assembler is
required for all who call themselves "programmer" :)
--
Minds, like parachutes, function best when open
Kevin Ashley
> I am trying to sort an array of pointers to int. My method was to
> convert a pointer address to an integer, but how do you convert back to
> a pointer after sorting so as to re-queue the pointers?
>
> int* fooptr;
> int a[10];
>
> for (int i = 0; i < 10; i++)
> {
> fooptr = PtrFromQueueArray();
> a[i] = (uint32_t) fooptr;
> }
>
> qsort(a, 10, sizeof(int), compareFunc);
>
> Should I have used a struct to store the pointer address as well as the
> converted pointer inside the QueueArray?
>
I'm sure this is just going to be one of many responses to this question,
but... the question you ask at the end of your post is so far removed from
the question you ought to be asking it's difficult to know what to tell you.
But consider these things:
(1) What order do you want the results to be in ? Do you want pointers
to the smallest integers to be at the front of the list, and pointers
to bigger ones at the end ? Or do you want to sort the integers
in order of magnitude ? Or prettiness ? Or do you want pointers themselves
to be sorted in some sort of memory order ? You haven't said, and you haven't
shown us your comparison function, so we can't tell either what you want to do
or whether your program actually does it correctly.
(2) What made you want to turn the pointer into an int ? What problem were you
trying to fix by doing that ? (And note, whatever the problem was, you almost
certainly haven't fixed it by doing this.) Does your compiler give you
warnings about that conversion ? (It ought to.)
(3) How do you expect us to diagnose your problem without a clear statement
of what it is, or a complete program or code fragment to work with ?
For what it's worth, my belief is that you should not be using any intermediate
array or structure to store things derived from your pointers: qsort should be
passed the pointer array itself, and compareFunc should do whatever is necessary
to compare two elements of that array in a way that suits your (unstated)
requirements.
DG.Ward
If you hate casting, you could use a union.
But, if you must cast a pointer to an integral type, it's best to cast
to a uintptr_t (which regardless of architecture, is large enough to
store an address in memory).
int* fooptr;
// int a[10]; <-- Don't try and store an address in a signed integer!
uintptr_t a[10];
for (int i = 0; i < 10; i++)
{
fooptr = PtrFromQueueArray();
a[i] = (uintptr_t) fooptr;
}
Alternatively, You could have a structure like this.
union
{
int *address;
uintptr_t integral;
}
ptr_t;
That way, when you assign an address to the address member, you can
access the integral representation without having to cast...
~K
-- Posted on news://freenews.netfront.net - Complaints to ne...@netfront.net --
Barry Schwarz
<HBBr...@t-online.de> wrote:
>Diego Acevedo wrote:
>> I am trying to sort an array of pointers to int.
>
>Before you go on, you should ask yourself whether that's actually a sane
>thing to be trying to do. Pointers aren't generally ordered, i.e.
>sorting them by value isn't supported by the language. For all you
>know, all pointers could be magic objects that have no numeric, sortable
>value at all.
You must be joking. Since ptr+1 is well defined, so is ptr1<ptr2.
>
>> My method was to convert a pointer address to an integer,
>
>First problem: you don't know if an int is big enough to store a
>pointer. You should use uintptr_t where available, uintmax_t otherwise.
>
>> but how do you convert back to
>> a pointer after sorting so as to re-queue the pointers?
>
>You don't, and you don't have to. You can just compare the pointer
>values directly. That's not officially supported by the language
>either, but the odds that it'll work anyway are at least as good as
>those that the result of casting pointers to integer types will preserve
>any ordering.
Remove del for email
Francis Glassborow
> On Sat, 28 Jun 2008 19:04:28 -0500 (CDT), Diego Acevedo
> <diegoa...@worldnet.att.net> wrote:
>
>> I am trying to sort an array of pointers to int. My method was to
>> convert a pointer address to an integer, but how do you convert back to
>> a pointer after sorting so as to re-queue the pointers?
>
> There is no need to convert the pointers to integer. compareFunc can
> be coded to determine whether pointer-1 is less than, equal to, or
> greater than pointer-2 directly.
>
same type) can only be compared for equality.
As to the original question, just write a compare function for qsort
that does the conversions internally. It will have no effect on the
actual values stored in your array.
Hans-Bernhard Bröker
> On Fri, 4 Jul 2008 01:46:22 -0500 (CDT), Hans-Bernhard Bröker wrote:
>> Before you go on, you should ask yourself whether that's actually a sane
>> thing to be trying to do. Pointers aren't generally ordered, i.e.
>> sorting them by value isn't supported by the language. For all you
>> know, all pointers could be magic objects that have no numeric, sortable
>> value at all.
> You must be joking. Since ptr+1 is well defined,
Not generally it isn't. In particular, if ptr is already pointing one
past the end of an array, (ptr+1) causes undefined behaviour (C99 6.5.6 p8)
> so is ptr1<ptr2.
Not generally it isn't. It's defined *only* if p1 and p2 happen to be
pointers into the same object (same array, or same block on the heap).
Francis Glassborow
> On Fri, 4 Jul 2008 01:46:22 -0500 (CDT), Hans-Bernhard Bröker
> <HBBr...@t-online.de> wrote:
>
>> Diego Acevedo wrote:
>>> I am trying to sort an array of pointers to int.
>> Before you go on, you should ask yourself whether that's actually a sane
>> thing to be trying to do. Pointers aren't generally ordered, i.e.
>> sorting them by value isn't supported by the language. For all you
>> know, all pointers could be magic objects that have no numeric, sortable
>> value at all.
>
> You must be joking. Since ptr+1 is well defined, so is ptr1<ptr2.
undefined behaviour. So what do you mean by 'well defined'?
Jasen Betts
> Diego Acevedo wrote:
>> I am trying to sort an array of pointers to int.
>
> Before you go on, you should ask yourself whether that's actually a sane
> thing to be trying to do.
I've had cause to do it in the past (hint: all the pointers pointed
into the same array)
> Pointers aren't generally ordered, i.e. sorting them by value isn't supported by the language.
the > < and - operators are supported between pointers any one of which is
sufficient to determine order.
> For all you know, all pointers could be magic objects that have no numeric,
> sortable value at all.
If that were so the language involved would not be 'C'
ordering-type comparison of pointers is specifically
allowed where the pointers point into the same object.
>> My method was to convert a pointer address to an integer,
> First problem:
agreed.
Bye.
Jasen
Francis Glassborow
> On 2008-07-04, Hans-Bernhard Bröker <HBBr...@t-online.de> wrote:
>> Diego Acevedo wrote:
>>> I am trying to sort an array of pointers to int.
>> Before you go on, you should ask yourself whether that's actually a sane
>> thing to be trying to do.
>
> I've had cause to do it in the past (hint: all the pointers pointed
> into the same array)
>
>> Pointers aren't generally ordered, i.e. sorting them by value isn't supported by the language.
>
> the > < and - operators are supported between pointers any one of which is
> sufficient to determine order.
>
No, those operators are only supported between pointers into the same
object.
--
Note that robinton.demon.co.uk addresses are no longer valid.
Hans-Bernhard Bröker
> On 2008-07-04, Hans-Bernhard Bröker <HBBr...@t-online.de> wrote:
>> Pointers aren't generally ordered, i.e. sorting them by value isn't supported by the language.
> the > < and - operators are supported between pointers any one of which is
> sufficient to determine order.
That's true _only_ if they point into the same object --- a pretty
serious limitation the OP was most likely unware of. I qualified the
above with "generally" for a reason, see?