Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13047 > unrolled thread

Typecasting Pointers on a 64 bit System

Back to article view | Back to comp.lang.c

Contents

  Typecasting Pointers on a 64 bit System Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-10 20:21 +0000
    Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-10 20:29 +0000
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:51 +0000
        Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:58 +0000
        Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 16:08 -0500
          Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:35 +0000
            Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 17:18 -0500
              Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:14 +0000
                Re: Typecasting Pointers on a 64 bit System Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-10 19:36 -0500
    Re: Typecasting Pointers on a 64 bit System Ben Pfaff <blp@cs.stanford.edu> - 2011-11-10 12:32 -0800
      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 15:44 -0500
      Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 12:58 -0800
        Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:53 +0000
    Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:45 +0000
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:00 +0000
    Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-10 15:14 -0700
    Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-11 11:22 +1300
      Re: Typecasting Pointers on a 64 bit System William Ahern <william@wilbur.25thandClement.com> - 2011-11-14 11:10 -0800
        Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 08:28 +1300
          Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:48 -0500
            Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:15 +1300
              Re: Typecasting Pointers on a 64 bit System jacob navia <jacob@spamsink.net> - 2011-11-14 22:18 +0100
                Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:26 +1300
              Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 16:46 -0500
                Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:58 +1300
                  Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 17:15 -0500
                    Re: Typecasting Pointers on a 64 bit System blp@cs.stanford.edu (Ben Pfaff) - 2011-11-14 14:18 -0800
                    Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 11:29 +1300
                      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 18:14 -0500
                        Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-14 23:01 +0000
                          Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:39 +0200
                            Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-16 20:18 +0000
                            Re: Typecasting Pointers on a 64 bit System Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> - 2011-11-17 02:54 +0100
                              Re: Typecasting Pointers on a 64 bit System pete <pfiland@mindspring.com> - 2011-11-16 21:29 -0500
                              Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 02:31 +0000
                                Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:31 +0200
                              Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-17 02:44 +0000
                              Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-16 21:33 -0700
                          Re: Typecasting Pointers on a 64 bit System "io_x" <a@b.c.invalid> - 2011-11-17 04:01 +0100
                          Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:46 +0000
                            Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 18:48 +0000
                              Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-18 14:48 +0000
                        Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 14:37 +1300
                    Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:23 +0200
                      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 06:53 -0500
                        Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 11:15 -0500
                          Re: Typecasting Pointers on a 64 bit System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-16 17:08 +0000
                          Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:09 +0200
                        Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:24 +0200
                          Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-18 10:08 -0500
                            Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 17:52 +0200
              Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-14 15:45 -0700
    Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-10 15:19 -0800
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:41 +0000
        Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 20:48 -0800
        Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-14 03:39 -0800
          Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-14 13:08 +0000
            Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 09:21 -0500
          Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-14 12:54 -0800

Page 1 of 3  [1] 2 3  Next page →

#13047 — Typecasting Pointers on a 64 bit System

What is the best way to handle this warning:

warning: cast from pointer to integer of different size

I am casting in and out of a function that requires a pointer type.  I
am casting an integer as a pointer, but the pointer is 8 bytes while
the integer is only 4 bytes.

Here's an example function:

pthread_create(&tid, NULL, readit, (void *)(long)connfd)

I need to pass the file descriptor as a void * for pthread_create.  But
I need the file descriptor as an integer to read and write to it.  Is the
above the best approach to turn off the warning?  I am considering just
typecasting to size_t before typecasting to the pointer.  Is that a
better approach than typecasting to long since size_t should remain equal 
to the size of pointers?

Of course, I run into the reverse problem when I have to close the
file descriptor.

close((int) arg);

I don't even know what to do in the above case.  I shouldn't be
truncating anything, so I should be okay.

I originally wrote the code using a 32 bit version, so I am receiving
these errors when I ported it over to a 64 bit version.

[toc] | [next] | [standalone]

#13048

In article <j9hbnp$13g$1@speranza.aioe.org>,
Quentin Pope  <qp19433@hotmail.NOSPAM.com> wrote:
> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
> 
> I need to pass the file descriptor as a void * for pthread_create.  But
> I need the file descriptor as an integer to read and write to it.  Is the
> above the best approach to turn off the warning?

No.

Just pass a pointer to the fd:

pthread_create(&tid, NULL, readit, &connfd);

Then dereference the pointer in the readit function to get the
descriptor. If connfd is a local variable, you need to make sure that
connfd doesn't exit the scope before the new thread has read it. If
this is difficult, you can allocate a new copy for the thread:

int* fdp = malloc(sizeof(int));
*fdp = connfd;
pthread_create(&tid, NULL, readit, fdp);

void readit(void* fdp) {
  int connfd = *(int*)fdp;
  free(fdp);
  ...;
}


Lauri

[toc] | [prev] | [next] | [standalone]

#13054

On 2011-11-10, Lauri Alanko <la@iki.fi> wrote:
> In article <j9hbnp$13g$1@speranza.aioe.org>,
> Quentin Pope  <qp19433@hotmail.NOSPAM.com> wrote:
>> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>> 
>> I need to pass the file descriptor as a void * for pthread_create.  But
>> I need the file descriptor as an integer to read and write to it.  Is the
>> above the best approach to turn off the warning?
>
> No.
>
> Just pass a pointer to the fd:
>
> pthread_create(&tid, NULL, readit, &connfd);

Ths is an inferior approach because now the object &connfd has
to remain stable for as long as the created thread wants to touch
that object.

> Then dereference the pointer in the readit function to get the
> descriptor. If connfd is a local variable, you need to make sure that
> connfd doesn't exit the scope before the new thread has read it.

You need to ensure that AND that the object is not overwritten with a different
value (e.g. in a loop that launches more than one thread).

In this case, why use threads? Just call "readit" directly from
this thread.

If the parent thread has to be confined while a thread executes, there is no
point. Just thread creation and context switching overhead.

What you can do is implement some little "mousetrap" protocol
wherby the thread indicates "I have consumed the argument, you can
trash it now". E.g condition variable, etc.

Or you could just cast the darn value to a pointer!

> this is difficult, you can allocate a new copy for the thread:
>
> int* fdp = malloc(sizeof(int));
> *fdp = connfd;
> pthread_create(&tid, NULL, readit, fdp);

Or just cast the darn value to a pointer. Save this trick for when the argument
list grows to include more than one value.

[toc] | [prev] | [next] | [standalone]

#13056

On 2011-11-10, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2011-11-10, Lauri Alanko <la@iki.fi> wrote:
>> int* fdp = malloc(sizeof(int));
>> *fdp = connfd;
>> pthread_create(&tid, NULL, readit, fdp);
>
> Or just cast the darn value to a pointer. Save this trick for when the argument
> list grows to include more than one value.

P.S. what is more important: having an allergic reaction to
pointer-integer casts? Or checking the return value of malloc.

:)

[toc] | [prev] | [next] | [standalone]

#13058

On 11/10/2011 03:51 PM, Kaz Kylheku wrote:
> On 2011-11-10, Lauri Alanko <la@iki.fi> wrote:
>> In article <j9hbnp$13g$1@speranza.aioe.org>,
>> Quentin Pope  <qp19433@hotmail.NOSPAM.com> wrote:
>>> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>>>
>>> I need to pass the file descriptor as a void * for pthread_create.  But
>>> I need the file descriptor as an integer to read and write to it.  Is the
>>> above the best approach to turn off the warning?
>>
>> No.
>>
>> Just pass a pointer to the fd:
>>
>> pthread_create(&tid, NULL, readit, &connfd);
> 
> Ths is an inferior approach because now the object &connfd has
> to remain stable for as long as the created thread wants to touch
> that object.
> 
>> Then dereference the pointer in the readit function to get the
>> descriptor. If connfd is a local variable, you need to make sure that
>> connfd doesn't exit the scope before the new thread has read it.
...
> Or you could just cast the darn value to a pointer!

Unless you're worried about the possibility that the result of the
conversion is a trap representation, as is explicitly allowed by the C
standard. Does POSIX say something to guarantee that this is not a
possibility?

[toc] | [prev] | [next] | [standalone]

#13060

On 2011-11-10, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/10/2011 03:51 PM, Kaz Kylheku wrote:
>> On 2011-11-10, Lauri Alanko <la@iki.fi> wrote:
>>> In article <j9hbnp$13g$1@speranza.aioe.org>,
>>> Quentin Pope  <qp19433@hotmail.NOSPAM.com> wrote:
>>>> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>>>>
>>>> I need to pass the file descriptor as a void * for pthread_create.  But
>>>> I need the file descriptor as an integer to read and write to it.  Is the
>>>> above the best approach to turn off the warning?
>>>
>>> No.
>>>
>>> Just pass a pointer to the fd:
>>>
>>> pthread_create(&tid, NULL, readit, &connfd);
>> 
>> Ths is an inferior approach because now the object &connfd has
>> to remain stable for as long as the created thread wants to touch
>> that object.
>> 
>>> Then dereference the pointer in the readit function to get the
>>> descriptor. If connfd is a local variable, you need to make sure that
>>> connfd doesn't exit the scope before the new thread has read it.
> ...
>> Or you could just cast the darn value to a pointer!
>
> Unless you're worried about the possibility that the result of the
> conversion is a trap representation, as is explicitly allowed by the C
> standard. Does POSIX say something to guarantee that this is not a
> possibility?

This type of concern has no economic consequence.

[toc] | [prev] | [next] | [standalone]

#13062

On 11/10/2011 04:35 PM, Kaz Kylheku wrote:
> On 2011-11-10, James Kuyper <jameskuyper@verizon.net> wrote:
...
>> Unless you're worried about the possibility that the result of the
>> conversion is a trap representation, as is explicitly allowed by the C
>> standard. Does POSIX say something to guarantee that this is not a
>> possibility?
> 
> This type of concern has no economic consequence.

If trap representations are in fact possible, programs can radically
malfunction (if they can't malfunction, it isn't really a trap
representation). That often can have economic consequences, depending
upon the nature of the malfunction. Therefore, your response, if
accurate, would seem to be a pointlessly complicated way of saying
"Yes". If you meant something else, it needs more (and clearer) explanation.

[toc] | [prev] | [next] | [standalone]

#13067

On 2011-11-10, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/10/2011 04:35 PM, Kaz Kylheku wrote:
>> On 2011-11-10, James Kuyper <jameskuyper@verizon.net> wrote:
> ...
>>> Unless you're worried about the possibility that the result of the
>>> conversion is a trap representation, as is explicitly allowed by the C
>>> standard. Does POSIX say something to guarantee that this is not a
>>> possibility?
>> 
>> This type of concern has no economic consequence.
>
> If trap representations are in fact possible, programs can radically
> malfunction (if they can't malfunction, it isn't really a trap
> representation). That often can have economic consequences, depending
> upon the nature of the malfunction.

Before you can discover that this POSIX-threaded program malfunctions in this
way, you have to get a POSIX implementation running on a chip which has these
trap representations.

The economic consequence is that there will be so many problems with this,
leading to so many delays, that the platform will be left without customers,
and soon without investors.

Where can order an evaluation board for a chip with trap representations, and a
POSIX runtime and toolchain?

[toc] | [prev] | [next] | [standalone]

#13073

On 11/10/11 6:14 PM, Kaz Kylheku wrote:
> On 2011-11-10, James Kuyper<jameskuyper@verizon.net>  wrote:
>> On 11/10/2011 04:35 PM, Kaz Kylheku wrote:
>>> On 2011-11-10, James Kuyper<jameskuyper@verizon.net>  wrote:
>> ...
>>>> Unless you're worried about the possibility that the result of the
>>>> conversion is a trap representation, as is explicitly allowed by the C
>>>> standard. Does POSIX say something to guarantee that this is not a
>>>> possibility?
>>>
>>> This type of concern has no economic consequence.
>>
>> If trap representations are in fact possible, programs can radically
>> malfunction (if they can't malfunction, it isn't really a trap
>> representation). That often can have economic consequences, depending
>> upon the nature of the malfunction.
>
> Before you can discover that this POSIX-threaded program malfunctions in this
> way, you have to get a POSIX implementation running on a chip which has these
> trap representations.
>
> The economic consequence is that there will be so many problems with this,
> leading to so many delays, that the platform will be left without customers,
> and soon without investors.
>
> Where can order an evaluation board for a chip with trap representations, and a
> POSIX runtime and toolchain?

Look at the 16 bit protected mode x86 architecture, admittedly a bit old 
now, but was a mainstay architecture, and I do believe did have POSIX 
available (and in fact was probably at one time a dominate architecture 
for it). In this model, far pointers (which were the default for some 
memory models) consisted of a 16 bit selector and a 16 bit offset. The 
typical instruction to manipulate a data pointer would load the pointer 
into the registers in a way that caused the processor to check the 
validity of the selector. (An all 0 selector would always be valid, so a 
NULL pointer didn't flag, so small integral values would be safe). 
Converting an arbitrary 32 bit value gave you a very good chance of 
generating a Segment Fault when you accessed the pointer.

You actually can run into this same issue with 32 bit x86 processors, it 
is just that "far" pointers are so much rarer that you aren't apt to 
misuse it this way, and my guess the current x64 mode would do the same 
if you used a far pointer.

[toc] | [prev] | [next] | [standalone]

#13049

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> What is the best way to handle this warning:
>
> warning: cast from pointer to integer of different size

The best way may be to avoid casting between a pointer and an
integer.

Another way is to use (u)intptr_t from <stdint.h>, which is
ordinarily defined as an integer type that is the same width as a
pointer.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#13051

On 11/10/2011 03:32 PM, Ben Pfaff wrote:
...
> Another way is to use (u)intptr_t from <stdint.h>, which is
> ordinarily defined as an integer type that is the same width as a
> pointer.

More accurately, it's defined to be big enough for the conversion to be
reversible. In practice, it's likely to be the same size, but that's not
part of the definition. It could easily be larger. If there's any
redundancy in the pointer representation, and the conversion removes
that redundancy, it could even be smaller.

[toc] | [prev] | [next] | [standalone]

#13055

Ben Pfaff <blp@cs.stanford.edu> writes:
> Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
>> What is the best way to handle this warning:
>>
>> warning: cast from pointer to integer of different size
>
> The best way may be to avoid casting between a pointer and an
> integer.
>
> Another way is to use (u)intptr_t from <stdint.h>, which is
> ordinarily defined as an integer type that is the same width as a
> pointer.

But (u)intptr_t won't exist on systems where no integer type is
wide enough to hold a converted pointer value without loss of
information, so code that depends on it is non-portable.  But if
you insist on passing an integer value in a pointer argument,
uintptr_t or intptr_t is the way to go.

In this case, the intent of the "arg" argument to pthread_create()
is that it should be a pointer to data needed by the start routine.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13560

In article <ln8vnn8zkr.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
> Ben Pfaff <blp@cs.stanford.edu> writes:
> > Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:
> >> What is the best way to handle this warning:
> >>
> >> warning: cast from pointer to integer of different size
> >
> > The best way may be to avoid casting between a pointer and an
> > integer.
> >
> > Another way is to use (u)intptr_t from <stdint.h>, which is
> > ordinarily defined as an integer type that is the same width as a
> > pointer.

[ snip ]
> 
> In this case, the intent of the "arg" argument to pthread_create()
> is that it should be a pointer to data needed by the start routine.
> 

Which in my thinking is a strong argument for *not* using creative
casting to pass some other kind of data.  

Granted that it may take a bit of thought to be sure that both
the pointer and the pointed-to data are stable enough to be
passed to another thread without creating the potential for race
conditions, and maybe that argues against using the parameter as
it was clearly meant to be used.  But still, if anyone else is
ever going to read or use this code, well ....

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#13052

On 2011-11-10, Quentin Pope <qp19433@hotmail.NOSPAM.com> wrote:
> What is the best way to handle this warning:
>
> warning: cast from pointer to integer of different size

Use an integer of a suitable size.

> I am casting in and out of a function that requires a pointer type.  I
> am casting an integer as a pointer, but the pointer is 8 bytes while
> the integer is only 4 bytes.

In the C99 language, there is the intptr_t type for this sort of thing.

For older dialects of C, you have to cob together some kind of compile
time configuration. Define the type as a typedef and change it based
on target compiler and platform.

I've written a configure script which detects what integral type is
suitable for holding pointers (based on size) and throws the info
into a "config.h" header.

This is BSD licensed so you can borrow it.

http://www.kylheku.com/cgit/txr/tree/configure

The approach taken in this script is to compile a sample translation unit and
then inspect the symbols (using the POSIX-standard nm command).

This creates an int_ptr_t typedef in "config.h" along with macros
giving the minimum and maximum value.

It's only been tested on various GNU/Linux architectures, Cygwin and MinGW.

It supports cross-compiling because the test programs are only compiled, never
executed.

[toc] | [prev] | [next] | [standalone]

#13057

On 2011-11-10, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2011-11-10, Quentin Pope <qp19433@hotmail.NOSPAM.com> wrote:
>> What is the best way to handle this warning:
>>
>> warning: cast from pointer to integer of different size
>
> Use an integer of a suitable size.
>
>> I am casting in and out of a function that requires a pointer type.  I
>> am casting an integer as a pointer, but the pointer is 8 bytes while
>> the integer is only 4 bytes.
>
> In the C99 language, there is the intptr_t type for this sort of thing.
>
> For older dialects of C, you have to cob together some kind of compile
> time configuration. Define the type as a typedef and change it based
> on target compiler and platform.
>
> I've written a configure script which detects what integral type is
> suitable for holding pointers (based on size) and throws the info
> into a "config.h" header.

But, by the way, I would not bother with this for something so trivial.

Here, your pointer type is larger than the integer you are trying to
pass through, so it doesn't matter.

Just kill the warning for that source file.

[toc] | [prev] | [next] | [standalone]

#13061

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> What is the best way to handle this warning:
>
> warning: cast from pointer to integer of different size
>
> I am casting in and out of a function that requires a pointer type.  I
> am casting an integer as a pointer, but the pointer is 8 bytes while
> the integer is only 4 bytes.
>
> Here's an example function:
>
> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>
> I need to pass the file descriptor as a void * for pthread_create.  But
> I need the file descriptor as an integer to read and write to it.  Is the
> above the best approach to turn off the warning?  I am considering just
> typecasting to size_t before typecasting to the pointer.  Is that a
> better approach than typecasting to long since size_t should remain equal 
> to the size of pointers?
>
> Of course, I run into the reverse problem when I have to close the
> file descriptor.
>
> close((int) arg);
>
> I don't even know what to do in the above case.  I shouldn't be
> truncating anything, so I should be okay.
>
> I originally wrote the code using a 32 bit version, so I am receiving
> these errors when I ported it over to a 64 bit version.

Why do you need to pass the file descriptor as a void*?  Why not pass a
pointer to the file descriptor?

[toc] | [prev] | [next] | [standalone]

#13063

On 11/11/11 09:21 AM, Quentin Pope wrote:
> What is the best way to handle this warning:
>
> warning: cast from pointer to integer of different size
>
> I am casting in and out of a function that requires a pointer type.  I
> am casting an integer as a pointer, but the pointer is 8 bytes while
> the integer is only 4 bytes.
>
> Here's an example function:
>
> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>
> I need to pass the file descriptor as a void * for pthread_create.  But
> I need the file descriptor as an integer to read and write to it.  Is the
> above the best approach to turn off the warning?

No. just pass the address of the descriptor.

> I am considering just
> typecasting to size_t before typecasting to the pointer.  Is that a
> better approach than typecasting to long since size_t should remain equal
> to the size of pointers?

Pointers aren't actors.

> Of course, I run into the reverse problem when I have to close the
> file descriptor.
>
> close((int) arg);
>
> I don't even know what to do in the above case.  I shouldn't be
> truncating anything, so I should be okay.
>
> I originally wrote the code using a 32 bit version, so I am receiving
> these errors when I ported it over to a 64 bit version.

Hacks invariably come back and bite you in the arse!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13302

Ian Collins <ian-news@hotmail.com> wrote:
> On 11/11/11 09:21 AM, Quentin Pope wrote:
<snip>
> > pthread_create(&tid, NULL, readit, (void *)(long)connfd)
> >
> > I need to pass the file descriptor as a void * for pthread_create.  But
> > I need the file descriptor as an integer to read and write to it.  Is the
> > above the best approach to turn off the warning?

> No. just pass the address of the descriptor.

Why do people keep suggesting this? Pass-by-reference and threads aren't
known to play well. IMHO the OP had sensible intuition to pass the
descriptor by value. It may not be pretty in C, but neither is threaded
programming.

[toc] | [prev] | [next] | [standalone]

#13303

On 11/15/11 08:10 AM, William Ahern wrote:
> Ian Collins<ian-news@hotmail.com>  wrote:
>> On 11/11/11 09:21 AM, Quentin Pope wrote:
> <snip>
>>> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>>>
>>> I need to pass the file descriptor as a void * for pthread_create.  But
>>> I need the file descriptor as an integer to read and write to it.  Is the
>>> above the best approach to turn off the warning?
>
>> No. just pass the address of the descriptor.
>
> Why do people keep suggesting this?

If OP had, this thread would never have been born.

> Pass-by-reference and threads aren't
> known to play well. IMHO the OP had sensible intuition to pass the
> descriptor by value. It may not be pretty in C, but neither is threaded
> programming.

As long as the address is still valid when a thread dereferences it, 
what's the problem?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13306

On 11/14/2011 02:28 PM, Ian Collins wrote:
> On 11/15/11 08:10 AM, William Ahern wrote:
...
>> Pass-by-reference and threads aren't
>> known to play well. IMHO the OP had sensible intuition to pass the
>> descriptor by value. It may not be pretty in C, but neither is threaded
>> programming.
> 
> As long as the address is still valid when a thread dereferences it, 
> what's the problem?

The possibility that the address might NOT still be valid at the time of
use. This has already been pointed out, and is explicitly considered
(but somehow ignored as unimportant) in your own response.
A relevant response would give reasons justifying your treatment of that
possibility as unimportant.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web