casting unsigned int to void*

Discussion in 'C Programming' started by Fred K, Jul 30, 2012.

  1. Fred K

    Fred K Guest

    The Xpm pixmap library contains code that casts an unsigned int
    to a (void *), passing that as an argument to a function
    that expects a (void *):

    /* Function prototype: */
    xpmHashIntern (xpmHashTable *table, char *tag, void *data));

    /* Calling it, casting 3rd argument: */
    int a = <something>;
    xpmHashIntern(hashtable, color->string, (void *)a );

    On a 64-bit platform where pointers are 64 bits and ints
    are 32 bits, is this safe?
     
    Fred K, Jul 30, 2012
    #1
    1. Advertising

  2. Fred K

    Eric Sosman Guest

    On 7/30/2012 1:33 PM, Fred K wrote:
    > The Xpm pixmap library contains code that casts an unsigned int
    > to a (void *), passing that as an argument to a function
    > that expects a (void *):
    >
    > /* Function prototype: */
    > xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >
    > /* Calling it, casting 3rd argument: */
    > int a = <something>;
    > xpmHashIntern(hashtable, color->string, (void *)a );
    >
    > On a 64-bit platform where pointers are 64 bits and ints
    > are 32 bits, is this safe?


    For suitable definitions of "safe," yes. Presumably the goal
    is to be able to convert the `void*' back to an `unsigned(?) int'
    and recover the original "<something>". If so,

    - The C language does not guarantee that this will work (no,
    not even if you use `intptr_t' or `uintptr_t'), but

    - It will work on every 64-bit machine I've ever encountered,
    and I haven't heard of any where it wouldn't.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jul 30, 2012
    #2
    1. Advertising

  3. Fred K

    James Kuyper Guest

    On 07/30/2012 01:33 PM, Fred K wrote:
    > The Xpm pixmap library contains code that casts an unsigned int
    > to a (void *), passing that as an argument to a function
    > that expects a (void *):
    >
    > /* Function prototype: */
    > xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >
    > /* Calling it, casting 3rd argument: */
    > int a = <something>;
    > xpmHashIntern(hashtable, color->string, (void *)a );
    >
    > On a 64-bit platform where pointers are 64 bits and ints
    > are 32 bits, is this safe?



    The fact that pointers are 64 bits and ints are 32 bits makes it more
    difficult for this to work, but not impossible. On a platform where both
    are the same size, it's more likely to work, but that's still not
    guaranteed. The precise requirements are as follows:

    Converting an integer constant expression with a value of 0 to void* is
    guaranteed by the standard to result in a null pointer value.

    Converting a pointer to void into either intptr_t or uintptr_t produces
    a value that can be converted back to void*, resulting in a pointer that
    is equivalent to the original pointer. Those two types are optional; if
    supported, they are defined in <stdint.h>, which was introduced in C99.
    You can check whether they are supported by checking whether INTPTR_MAX
    or UINTPTR_MAX are #defined.

    In all other cases, while converting an integer value to a pointer is
    permitted, "the result is implementation-defined, might not be correctly
    aligned, might not point to an entity of the referenced type, and might
    be a trap representation."

    Whether or not this code works correctly is therefore
    implementation-specific. It would never have been written and released
    unless it actually did work, somewhere, but that's no guarantee that it
    will work anywhere else.
     
    James Kuyper, Jul 30, 2012
    #3
  4. Fred K

    Fred K Guest

    On Monday, July 30, 2012 11:14:34 AM UTC-7, James Kuyper wrote:
    > On 07/30/2012 01:33 PM, Fred K wrote: > The Xpm pixmap library contains code that casts an unsigned int > to a (void *), passing that as an argumentto a function > that expects a (void *): > > /* Function prototype: */ > xpmHashIntern (xpmHashTable *table, char *tag, void *data)); > > /* Calling it, casting 3rd argument: */ > int a = <something>; > xpmHashIntern(hashtable, color->string, (void *)a ); > > On a 64-bit platform where pointers are 64 bits and ints > are 32 bits, is this safe? The fact that pointers are64 bits and ints are 32 bits makes it more difficult for this to work, butnot impossible. On a platform where both are the same size, it's more likely to work, but that's still not guaranteed. The precise requirements are as follows: Converting an integer constant expression with a value of 0 to void* is guaranteed by the standard to result in a null pointer value. Converting a pointer to void into either intptr_t or uintptr_t produces a value that can be converted back to void*, resulting in a pointer that is equivalent to the original pointer. Those two types are optional; if supported, they are defined in <stdint.h>, which was introduced in C99. You can check whether they are supported by checking whether INTPTR_MAX or UINTPTR_MAX are #defined. In all other cases, while converting an integer value to a pointer is permitted, "the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation." Whether or not this code works correctly is therefore implementation-specific. It would never have been written and released unless it actually did work, somewhere, but that's no guarantee that it will work anywhere else.


    Well, it was written a long time ago, and for platforms where the size of an int was the same size as a pointer. So far, I haven't found a problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to several flavors of (64-bit) Linux, and iPad. Time will tell...
     
    Fred K, Jul 30, 2012
    #4
  5. Fred K

    Alan Curry Guest

    There was some really unforgivable formatting in here, especially the more
    deeply quoted parts, so I chopped them out. Google Groups sucks! Get a
    real newsreader!

    In article <>,
    Fred K <> wrote:
    [about xpm]
    >
    >Well, it was written a long time ago, and for platforms where the size
    >of an int was the same size as a pointer. So far, I haven't found a
    >problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to
    >several flavors of (64-bit) Linux, and iPad. Time will tell...


    Xpm isn't some dead artifact you just dug up that nobody else remembers. It has
    been continuously maintained and is still distributed by x.org.

    Why can't you use their version? It should already be bundled with your
    Linux distribution.

    --
    Alan Curry
     
    Alan Curry, Jul 30, 2012
    #5
  6. In article <jv6i1p$ch0$>,
    Eric Sosman <> wrote:
    >On 7/30/2012 1:33 PM, Fred K wrote:
    >
    > For suitable definitions of "safe," yes. Presumably the goal
    >is to be able to convert the `void*' back to an `unsigned(?) int'
    >and recover the original "<something>". If so,
    >
    > - The C language does not guarantee that this will work (no,
    > not even if you use `intptr_t' or `uintptr_t'), but
    >
    > - It will work on every 64-bit machine I've ever encountered,
    > and I haven't heard of any where it wouldn't.


    Agreed. The spec may not support it, but it should be safe on
    most machines, as long as the size of void* is >= the size of int.

    It would fail on a 286 with the wrong compiler options, and maybe a
    PDP-11, but would be safe on any other machine I've ever worked on.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
     
    Edward A. Falk, Jul 30, 2012
    #6
  7. Fred K

    Fred K Guest

    On Monday, July 30, 2012 11:46:51 AM UTC-7, Alan Curry wrote:
    > There was some really unforgivable formatting in here, especially the more deeply quoted parts, so I chopped them out. Google Groups sucks! Get a real newsreader! In article <>, Fred K <> wrote: [about xpm] > >Well, it was written a long time ago, and for platforms where the size >of an intwas the same size as a pointer. So far, I haven't found a >problem with iton an HP-UX, SGI, Sun, AIX; I'm now porting it to >several flavors of (64-bit) Linux, and iPad. Time will tell... Xpm isn't some dead artifact you just dug up that nobody else remembers. It has been continuously maintained and is still distributed by x.org. Why can't you use their version? It should already be bundled with your Linux distribution. -- Alan Curry


    I just downloaded the current version (including source code) and it still has that code in it, so they are currently using code that may be problematic.
     
    Fred K, Jul 30, 2012
    #7
  8. Fred K <> writes:

    > On Monday, July 30, 2012 11:46:51 AM UTC-7, Alan Curry wrote:
    >> There was some really unforgivable formatting in here, especially the more deeply quoted parts, so I chopped them out. Google Groups sucks! Get a real newsreader! In article <>, Fred K <> wrote: [about xpm] > >Well, it was written a long time ago, and for platforms where the size >of an int was the same size as a pointer. So far, I haven't found a >problem with it on an HP-UX, SGI, Sun, AIX; I'm now porting it to >several flavors of (64-bit) Linux, and iPad. Time will tell... Xpm isn't some dead artifact you just dug up that nobody else remembers. It has been continuously maintained and is still distributed by x.org. Why can't you use their version? It should already be bundled with your Linux distribution. -- Alan Curry


    There is something odd with your quoting! Is this another Google groups
    issue?

    > I just downloaded the current version (including source code) and it
    > still has that code in it, so they are currently using code that may
    > be problematic.


    The "may" is key. It may be problematic, but I doubt it. It's a very
    common trick, and every implementation I've used defines the conversion
    in a way that makes recovery of the int (the actual purpose here) safe.

    You are doing the porting, are you not? Is it actually a problem?

    --
    Ben.
     
    Ben Bacarisse, Jul 30, 2012
    #8
  9. Fred K

    James Kuyper Guest

    On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
    ....
    > intptr_t is an integer which is large enough to hold a void* pointer encoded in
    > an integer. This is an ancient bug dating back to the days when an integer was
    > 60 bits, would always be 60 bits, and an address was 18 bits, and would always


    Your descriptions seem highly platform-specific; I'm not familiar with a
    platform that had those particular characteristics. Could you identify it?

    > be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits),
    > exposing this bad assumption. The intptr_t was eventually introduced to provide
    > an integer that would always be safe to hold addresses.
     
    James Kuyper, Jul 30, 2012
    #9
  10. Fred K

    James Kuyper Guest

    On 07/30/2012 05:55 PM, China Blue [Tor], Meersburg wrote:
    > In article <>,
    > James Kuyper <> wrote:
    >
    >> On 07/30/2012 04:04 PM, China Blue [Tor], Meersburg wrote:
    >> ...
    >>> intptr_t is an integer which is large enough to hold a void* pointer
    >>> encoded in
    >>> an integer. This is an ancient bug dating back to the days when an integer
    >>> was
    >>> 60 bits, would always be 60 bits, and an address was 18 bits, and would
    >>> always

    >>
    >> Your descriptions seem highly platform-specific; I'm not familiar with a
    >> platform that had those particular characteristics. Could you identify it?

    >
    > http://en.wikipedia.org/wiki/CDC_6600


    Can you give us any particular reason to believe that this particular
    processor had a major role to play in setting up expectations, relevant
    to the design of C, that were later violated by the Intel 8086 family of
    processors, as implied by your earlier message? Your wording gave the
    impression that 60-bit integers were so widely used that many people
    thought they were universal. The article you linked to refers to the
    60-bit words as "very large", belying that implication.
     
    James Kuyper, Jul 30, 2012
    #10
  11. "China Blue [Tor], Meersburg" <> writes:

    > In article <>,
    > Fred K <> wrote:
    >
    >> The Xpm pixmap library contains code that casts an unsigned int
    >> to a (void *), passing that as an argument to a function
    >> that expects a (void *):
    >>
    >> /* Function prototype: */
    >> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >>
    >> /* Calling it, casting 3rd argument: */
    >> int a = <something>;
    >> xpmHashIntern(hashtable, color->string, (void *)a );
    >>
    >> On a 64-bit platform where pointers are 64 bits and ints
    >> are 32 bits, is this safe?

    >
    > intptr_t is an integer which is large enough to hold a void* pointer
    > encoded in an integer. This is an ancient bug dating back to the days
    > when an integer was 60 bits, would always be 60 bits, and an address
    > was 18 bits, and would always be 18 bits. The 80x86s had addresses (20
    > bits) larger than ints (16 bits), exposing this bad assumption.


    It's never been an assumption made by C -- even pre-ANSI C.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Jul 30, 2012
    #11
  12. Fred K <> writes:
    > The Xpm pixmap library contains code that casts an unsigned int
    > to a (void *), passing that as an argument to a function
    > that expects a (void *):
    >
    > /* Function prototype: */
    > xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >
    > /* Calling it, casting 3rd argument: */
    > int a = <something>;
    > xpmHashIntern(hashtable, color->string, (void *)a );
    >
    > On a 64-bit platform where pointers are 64 bits and ints
    > are 32 bits, is this safe?


    Others have addressed the safety (or lack thereof) of doing this.

    The "void *data" parameter is intended for passing arbitrary information
    into the function. A safer way to pass an int value is to pass the
    address of an int object:

    int a = <something>;
    int *p = malloc(sizeof *p);
    /* check for allocation error */
    xpmHashIntern(hashtable, color->string, p);

    I used malloc to ensure that the object continues to exist as long as
    it's needed; if it's a one-off object, declaring "a" as static would
    also work.

    This assumes, of course, that the code that retrieves the value from the
    hash table knows to treat it as a pointer to an int object.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jul 31, 2012
    #12
  13. Fred K

    Eric Sosman Guest

    On 7/30/2012 4:04 PM, China Blue [Tor], Meersburg wrote:
    > In article <>,
    > Fred K <> wrote:
    >
    >> The Xpm pixmap library contains code that casts an unsigned int
    >> to a (void *), passing that as an argument to a function
    >> that expects a (void *):
    >>
    >> /* Function prototype: */
    >> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >>
    >> /* Calling it, casting 3rd argument: */
    >> int a = <something>;
    >> xpmHashIntern(hashtable, color->string, (void *)a );
    >>
    >> On a 64-bit platform where pointers are 64 bits and ints
    >> are 32 bits, is this safe?

    >
    > intptr_t is an integer which is large enough to hold a void* pointer encoded in
    > an integer.


    intptr_t and uintptr_t are both irrelevant to the O.P.'s
    question. The fact that a void* can be converted to a intptr_t
    which can be in turn converted to a void* with the two pointers
    comparing equal does not imply that a intptr_t can be converted
    to a void* and then back to a intptr_t with the two integers
    equal.

    P1 -> I -> P2, P2 == P1
    I1 -> P -> I2, I2 ?= I1 (no guarantee)

    > This is an ancient bug


    Makes no sense. It can't be any more ancient than C99, which
    introduced the types. "Bug" can be a subjective judgement, but it's
    certainly debatable whether the existence of intptr_t is a "bug."
    People who want to convert pointers to integers and back probably
    dispute your assessment.

    > dating back to the days when an integer was
    > 60 bits, would always be 60 bits, and an address was 18 bits, and would always
    > be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits),
    > exposing this bad assumption.


    Is this supposed to be an argument that intptr_t is a "bug?"
    I cannot comprehend what it's supposed to be about.

    > The intptr_t was eventually introduced to provide
    > an integer that would always be safe to hold addresses.


    Not quite. The intptr_t types are optional, meaning
    that they are not "always" safe to hold addresses. Also, there
    has been no introduction of addresses that are safe to hold
    integers. Finally, none of this is "ancient" except to pre-teens.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jul 31, 2012
    #13
  14. Fred K

    Mark Bluemel Guest

    On 30/07/2012 23:18, China Blue [Tor], Meersburg wrote:

    > It was a joke illustrating a common mistake about assuming sizeofs.


    Clearly an example of alternative comedy. Comedy is usually funny, this
    is the alternative.
     
    Mark Bluemel, Jul 31, 2012
    #14
  15. Fred K

    James Kuyper Guest

    On 07/30/2012 08:45 PM, Eric Sosman wrote:
    > On 7/30/2012 4:04 PM, China Blue [Tor], Meersburg wrote:
    >> In article <>,
    >> Fred K <> wrote:
    >>
    >>> The Xpm pixmap library contains code that casts an unsigned int
    >>> to a (void *), passing that as an argument to a function
    >>> that expects a (void *):
    >>>
    >>> /* Function prototype: */
    >>> xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >>>
    >>> /* Calling it, casting 3rd argument: */
    >>> int a = <something>;
    >>> xpmHashIntern(hashtable, color->string, (void *)a );
    >>>
    >>> On a 64-bit platform where pointers are 64 bits and ints
    >>> are 32 bits, is this safe?

    >>
    >> intptr_t is an integer which is large enough to hold a void* pointer encoded in
    >> an integer.

    >
    > intptr_t and uintptr_t are both irrelevant to the O.P.'s
    > question. ...


    No, they are not.

    > ... The fact that a void* can be converted to a intptr_t
    > which can be in turn converted to a void* with the two pointers
    > comparing equal does not imply that a intptr_t can be converted
    > to a void* and then back to a intptr_t with the two integers
    > equal.
    >
    > P1 -> I -> P2, P2 == P1
    > I1 -> P -> I2, I2 ?= I1 (no guarantee)


    Agreed. However, we were not told how the integer value was chosen, nor
    what xpmHashIntern() did with it. If you're familiar with xpm, it might
    seem obvious. However, for those of us who are not, the possibilities
    are quite open-ended. One way that code similar to the code above could
    have worked is as follows:

    double d = 3.14;
    intptr_t a = (intptr_t)(void*)&d;

    xpmHashIntern(hashtable, color->string, (void*)a);

    xpmHashIntern (xpmHashTable *table, char *tag, void *data))
    {
    /* ... stuff ... */
    double *pd = data;
    /* ... more stuff, making use of *pd ... */
    }

    Using int rather than intptr_t could therefore work on a particular
    implementation, if the result of (intptr_t)(void*)d happened to be
    representable as an int on that implementation. That's not something
    that code intended to be portable should rely upon, but it does provide
    one possible way that such non-portable code like that might have worked
    on a particular implementation.

    >> This is an ancient bug

    >
    > Makes no sense. It can't be any more ancient than C99, which
    > introduced the types. "Bug" can be a subjective judgement, but it's
    > certainly debatable whether the existence of intptr_t is a "bug."


    I didn't see anything that suggested that the existence of [u[intptr_t
    was a bug. The "bug" he's referring to is the use of 'int' rather than
    'intprt_t' in the original code.

    ....
    >> dating back to the days when an integer was
    >> 60 bits, would always be 60 bits, and an address was 18 bits, and would always
    >> be 18 bits. The 80x86s had addresses (20 bits) larger than ints (16 bits),
    >> exposing this bad assumption.

    >
    > Is this supposed to be an argument that intptr_t is a "bug?"


    No.

    > I cannot comprehend what it's supposed to be about.


    It's meant to be an explanation of the problem that intptr_t was
    invented to solve. It fails primarily due to the fact that numbers given
    were apparently chosen for humorous effect, rather than plausibility. It
    would have been a lot more plausible if 60 and 18 had both been changed
    to 16.
    --
    James Kuyper
     
    James Kuyper, Jul 31, 2012
    #15
  16. Fred K

    James Kuyper Guest

    On 07/30/2012 01:33 PM, Fred K wrote:
    > The Xpm pixmap library contains code that casts an unsigned int


    Here, you say that it was an unsigned int.

    > to a (void *), passing that as an argument to a function
    > that expects a (void *):
    >
    > /* Function prototype: */
    > xpmHashIntern (xpmHashTable *table, char *tag, void *data));
    >
    > /* Calling it, casting 3rd argument: */
    > int a = <something>;


    But that's a signed int. The difference is irrelevant to the main point
    of your question, but the discrepancy raises questions about the
    accuracy of your description of the original code.

    > xpmHashIntern(hashtable, color->string, (void *)a );
    >
    > On a 64-bit platform where pointers are 64 bits and ints
    > are 32 bits, is this safe?

    --
    James Kuyper
     
    James Kuyper, Jul 31, 2012
    #16
  17. James Kuyperæ–¼ 2012å¹´7月31日星期二UTC+8下åˆ7時26分39秒寫é“:
    > On 07/30/2012 01:33 PM, Fred K wrote:
    >
    > > The Xpm pixmap library contains code that casts an unsigned int

    >
    >
    >
    > Here, you say that it was an unsigned int.
    >
    >
    >
    > > to a (void *), passing that as an argument to a function

    >
    > > that expects a (void *):

    >
    > >

    >
    > > /* Function prototype: */

    >
    > > xpmHashIntern (xpmHashTable *table, char *tag, void *data));

    >
    > >

    >
    > > /* Calling it, casting 3rd argument: */

    >
    > > int a = <something>;

    >
    >
    >
    > But that's a signed int. The difference is irrelevant to the main point
    >
    > of your question, but the discrepancy raises questions about the
    >
    > accuracy of your description of the original code.
    >
    >
    >
    > > xpmHashIntern(hashtable, color->string, (void *)a );

    >
    > >

    >
    > > On a 64-bit platform where pointers are 64 bits and ints

    >
    > > are 32 bits, is this safe?

    >
    > --
    >
    > James Kuyper




    James Kuyperæ–¼ 2012å¹´7月31日星期二UTC+8下åˆ7時26分39秒寫é“:
    > On 07/30/2012 01:33 PM, Fred K wrote:
    >
    > > The Xpm pixmap library contains code that casts an unsigned int

    >
    >
    >
    > Here, you say that it was an unsigned int.
    >
    >
    >
    > > to a (void *), passing that as an argument to a function

    >
    > > that expects a (void *):

    >
    > >

    >
    > > /* Function prototype: */

    >
    > > xpmHashIntern (xpmHashTable *table, char *tag, void *data));

    >
    > >

    >
    > > /* Calling it, casting 3rd argument: */

    >
    > > int a = <something>;

    >
    >
    >
    > But that's a signed int. The difference is irrelevant to the main point
    >
    > of your question, but the discrepancy raises questions about the
    >
    > accuracy of your description of the original code.
    >
    >
    >
    > > xpmHashIntern(hashtable, color->string, (void *)a );

    >
    > >

    >
    > > On a 64-bit platform where pointers are 64 bits and ints

    >
    > > are 32 bits, is this safe?

    >
    > --
    >
    > James Kuyper


    As far as I know, the valid operators of pointers are ++, --, ==, =,
    and various explicit type castings, ( Type *), in the C language standards..

    All other operations of pointers are platform-dependent.

    If the compiler can be sure that the higher 32 bits of a 64-bit pointer
    is not to be changed after ++, and --, then only the lower 32 bits are needed to be loaded into a 32 bit register.

    Do we need to add more operators of pointers to be in the C standards?

    But I think some trival C macros in assembly can offer the same effects.

    Uhn, a more sophiscated malloc might be needed, too.
     
    88888 Dihedral, Aug 5, 2012
    #17
  18. Fred K

    Ike Naar Guest

    On 2012-08-05, 88888 Dihedral <> wrote:
    > As far as I know, the valid operators of pointers are ++, --, ==, =,
    > and various explicit type castings, ( Type *), in the C language standards.


    *, ->, &, +, +=, -, -=, -, [], <, <=, >, >=, !=, sizeof, (), &&, ||, ?:
     
    Ike Naar, Aug 5, 2012
    #18
  19. Fred K

    Phil Carmody Guest

    Ike Naar <> writes:
    > On 2012-08-05, 88888 Dihedral <> wrote:
    > > As far as I know, the valid operators of pointers are ++, --, ==, =,
    > > and various explicit type castings, ( Type *), in the C language standards.

    >
    > *, ->, &, +, +=, -, -=, -, [], <, <=, >, >=, !=, sizeof, (), &&, ||, ?:


    Good list, but did you really need to mention the comma operator 18 times?

    ;-) Phil
    --
    > I'd argue that there is much evidence for the existence of a God.

    Pics or it didn't happen.
    -- Tom (/. uid 822)
     
    Phil Carmody, Aug 10, 2012
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Timo Freiberger
    Replies:
    3
    Views:
    954
    Bob Hairgrove
    Oct 30, 2004
  2. Pranab Mehta

    casting from int to void* and back to int

    Pranab Mehta, Apr 12, 2004, in forum: C Programming
    Replies:
    14
    Views:
    15,003
    Eric Sosman
    Apr 13, 2004
  3. er
    Replies:
    6
    Views:
    492
    Andre Kostur
    Sep 14, 2007
  4. ciccio

    int*unsigned int = unsigned?

    ciccio, Jun 4, 2010, in forum: C++
    Replies:
    2
    Views:
    413
    Öö Tiib
    Jun 4, 2010
  5. pozz
    Replies:
    12
    Views:
    745
    Tim Rentsch
    Mar 20, 2011
Loading...

Share This Page