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

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

Re: "Conversions" of types

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "Conversions" of types Keith Thompson <kst-u@mib.org> - 2019-06-09 11:44 -0700
    Re: "Conversions" of types unidef <jon@unidef-systems.com> - 2019-06-10 04:16 -0500
      Re: "Conversions" of types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-10 03:27 -0700
        Re: "Conversions" of types David Brown <david.brown@hesbynett.no> - 2019-06-10 13:24 +0200
      Re: "Conversions" of types Keith Thompson <kst-u@mib.org> - 2019-06-10 14:00 -0700

#144672 — Re: "Conversions" of types

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> |Any pointer type may be converted to an integer type.
> N2310, 6.3.2.3p6
>
>   If this is true, then may I ask: Which integer type
>   is the result of the conversion of the pointer type
>   »double *« to an integer type?
>
>   Don't they mean:
>
> Any /value of/ an expression of pointer type may be 
> converted to a /value of/ an integer type.

Yes.

>   ? Or does it really make sense to say that a /type/
>   can be converted to another type?

No.  The wording in the standard is slightly informal.  The intent is
clear enough that I don't have a problem with it, though I wouldn't
mind if it were changed to refer to values.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [next] | [standalone]

#144696

Keith Thompson <kst-u@mib.org> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> |Any pointer type may be converted to an integer type.
>> N2310, 6.3.2.3p6
>> 
>> If this is true, then may I ask: Which integer type
>> is the result of the conversion of the pointer type
>> »double *« to an integer type?
>> 
>> Don't they mean:
>> 
>> Any /value of/ an expression of pointer type may be 
>> converted to a /value of/ an integer type.
> 
> Yes.
> 
>> ? Or does it really make sense to say that a /type/
>> can be converted to another type?
> 
> No.  The wording in the standard is slightly informal.  The intent is
> clear enough that I don't have a problem with it, though I wouldn't
> mind if it were changed to refer to values.
> 

You gotta look into the machines native assembly code to make sense out of
casting. I don’t know assembly that well :(

-- 
“There is nothing certain in this world, aside from Death or Taxes” - 
Benjamin Franklin

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

#144697

On Monday, 10 June 2019 10:17:10 UTC+1, unidef  wrote:
> 
> You gotta look into the machines native assembly code to make sense out of
> casting. I don’t know assembly that well :(
> 
Address registers and integer registers are usually the same. So there's
a natural mapping from int or a longer type on 64 bit machines to
pointers and back. 
However that's not guaranteed.

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

#144698

On 10/06/2019 12:27, Malcolm McLean wrote:
> On Monday, 10 June 2019 10:17:10 UTC+1, unidef  wrote:
>>
>> You gotta look into the machines native assembly code to make sense out of
>> casting. I don’t know assembly that well :(
>>
> Address registers and integer registers are usually the same. So there's
> a natural mapping from int or a longer type on 64 bit machines to
> pointers and back.
> However that's not guaranteed.
> 

Fortunately, C answers the question for you.  In <stdint.h>, there will 
be types "intptr_t" and "uintptr_t" that are integer types suitable for 
mapping back and forth with pointers, unless you have such an unusual 
architecture that there are no suitable integer types.


Instead of guessing about the size of address and integer registers 
(which vary from cpu to cpu) or the relative sizes of different C 
integer types and pointers, use the /standard/ types "intptr_t" or 
"uintptr_t".

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

#144719

unidef <jon@unidef-systems.com> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> |Any pointer type may be converted to an integer type.
>>> N2310, 6.3.2.3p6
>>> 
>>> If this is true, then may I ask: Which integer type
>>> is the result of the conversion of the pointer type
>>> »double *« to an integer type?
>>> 
>>> Don't they mean:
>>> 
>>> Any /value of/ an expression of pointer type may be 
>>> converted to a /value of/ an integer type.
>> 
>> Yes.
>> 
>>> ? Or does it really make sense to say that a /type/
>>> can be converted to another type?
>> 
>> No.  The wording in the standard is slightly informal.  The intent is
>> clear enough that I don't have a problem with it, though I wouldn't
>> mind if it were changed to refer to values.
>> 
>
> You gotta look into the machines native assembly code to make sense out of
> casting. I don’t know assembly that well :(

No, you don't have to look at assembly code to make sense out
of casting.  The semantics of casts, and more generally of
type conversions, are defined by the standard (and are left
implementation-defined in some cases).

For pointer conversions (pointer-to-pointer, pointer-to-integer, or
integer-to-pointer), it helps to know how pointers are represented,
but knowing about the CPU instructions instructions that act on them
is not particularly helpful.  On most systems, pointer conversions
just copy the bits; the only slightly tricky part is making sure
that the source and target have consistent sizes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

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

csiph-web