Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > pointer conversion

Reply
Thread Tools

pointer conversion

 
 
junky_fellow@yahoo.co.in
Guest
Posts: n/a
 
      08-31-2007
guys,

I have a question regarding pointer conversion. Please look at the
following code snippet.

char *cptr;
int *iptr;

/* Some code here that initializes "iptr" */

cptr = (char *)iptr; /* Line 1
*/
cptr = cptr + sizeof(int); /* Line 2 */
iptr = (int *)cptr; /* Line 3 */

Now as per the pointer conversion rule:
Page 47: n1124.pdf

A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the resulting
pointer is not correctly aligned57) for thepointed-to type, the
behavior is undefined. Otherwise, when converted back again, the
result shall compare equal to the original pointer.

According to above conversion rule, "Line 1" should be perfectly fine.
But, I want to know if the conversion done at "Line 3" is allowed or
not.
I have this doubt because the "cptr" has been changed.
But, it is properly aligned to point to an integer object.

 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      08-31-2007

<> wrote in message
news: oups.com...
> guys,
>
> I have a question regarding pointer conversion. Please look at the
> following code snippet.
>
> char *cptr;
> int *iptr;
>
> /* Some code here that initializes "iptr" */
>
> cptr = (char *)iptr; /* Line 1
> */
> cptr = cptr + sizeof(int); /* Line 2 */
> iptr = (int *)cptr; /* Line 3 */
>
> Now as per the pointer conversion rule:
> Page 47: n1124.pdf
>
> A pointer to an object or incomplete type may be converted to a
> pointer to a different object or incomplete type. If the resulting
> pointer is not correctly aligned57) for thepointed-to type, the
> behavior is undefined. Otherwise, when converted back again, the
> result shall compare equal to the original pointer.
>
> According to above conversion rule, "Line 1" should be perfectly fine.
> But, I want to know if the conversion done at "Line 3" is allowed or
> not.
> I have this doubt because the "cptr" has been changed.
> But, it is properly aligned to point to an integer object.
>

You will be OK.
char is always 1 byte. So casting an arbitrary pointer to a char *, adding
an exact multiple of the size of the original type, and casting back is
guaranteed to preserve alignment.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
 
Charlton Wilbur
Guest
Posts: n/a
 
      08-31-2007
>>>>> "M" == Malcolm McLean <> writes:

M> You will be OK. char is always 1 byte. So casting an arbitrary
M> pointer to a char *, adding an exact multiple of the size of
M> the original type, and casting back is guaranteed to preserve
M> alignment.

I am not so sure about that; would you care to cite C&V, please, if
you claim that it's guaranteed by the standard?

Charlton


--
Charlton Wilbur

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      08-31-2007

"Charlton Wilbur" <> wrote in message
news:...
>>>>>> "M" == Malcolm McLean <> writes:

>
> M> You will be OK. char is always 1 byte. So casting an arbitrary
> M> pointer to a char *, adding an exact multiple of the size of
> M> the original type, and casting back is guaranteed to preserve
> M> alignment.
>
> I am not so sure about that; would you care to cite C&V, please, if
> you claim that it's guaranteed by the standard?
>

Arrays have to be contiguous in memory. No padding bytes may be inserted
between items.
The rest follows from that.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-31-2007
In article <_>,
Eric Sosman <> wrote:

>> M> You will be OK. char is always 1 byte. So casting an arbitrary
>> M> pointer to a char *, adding an exact multiple of the size of
>> M> the original type, and casting back is guaranteed to preserve
>> M> alignment.


>> I am not so sure about that; would you care to cite C&V, please, if
>> you claim that it's guaranteed by the standard?


> He's wrong: it's not guaranteed. Simple example:
>
> int target = 42;
> int *ptr = &target + 1; /* "an arbitrary pointer" */
> ptr = (int*)((char*)ptr + sizeof *ptr); /* U.B. */
>
> If the original pointer points at an actual object of its
>type (so it's not "arbitrary"), the conversion is safe.


That seems to be excessive pedantry. He said it "preserves
alignment", not that it's legal. Presumably you would deny that
adding 2 to an int preserves it odd/even parity, because you might
choose INT_MAX.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-31-2007
Charlton Wilbur wrote:
>>>>>> "M" == Malcolm McLean <> writes:

>
> M> You will be OK. char is always 1 byte. So casting an arbitrary
> M> pointer to a char *, adding an exact multiple of the size of
> M> the original type, and casting back is guaranteed to preserve
> M> alignment.
>
> I am not so sure about that; would you care to cite C&V, please, if
> you claim that it's guaranteed by the standard?


He's wrong: it's not guaranteed. Simple example:

int target = 42;
int *ptr = &target + 1; /* "an arbitrary pointer" */
ptr = (int*)((char*)ptr + sizeof *ptr); /* U.B. */

If the original pointer points at an actual object of its
type (so it's not "arbitrary"), the conversion is safe.

--
Eric Sosman
lid
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-31-2007
Malcolm McLean wrote:
>

.... snip ...
>
> Arrays have to be contiguous in memory. No padding bytes may be
> inserted between items. The rest follows from that.


Nonsense. Consider:

struct foo {int iv; char ch} arr[N];

A struct foo, on a machine with sizeof int == 4, will be occupy 5
bytes. However, in order to make addressable arrays of these,
sizeof struct foo == 8 (assuming ints need to be aligned modulo
4). I.E. there are 3 padding bytes per item.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



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

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      08-31-2007

"Richard Tobin" <> wrote in message
news:fb9ran$1fap$...
> In article <_>,
> Eric Sosman <> wrote:
>
>>> M> You will be OK. char is always 1 byte. So casting an arbitrary
>>> M> pointer to a char *, adding an exact multiple of the size of
>>> M> the original type, and casting back is guaranteed to preserve
>>> M> alignment.

>
>>> I am not so sure about that; would you care to cite C&V, please, if
>>> you claim that it's guaranteed by the standard?

>
>> He's wrong: it's not guaranteed. Simple example:
>>
>> int target = 42;
>> int *ptr = &target + 1; /* "an arbitrary pointer" */
>> ptr = (int*)((char*)ptr + sizeof *ptr); /* U.B. */
>>
>> If the original pointer points at an actual object of its
>>type (so it's not "arbitrary"), the conversion is safe.

>
> That seems to be excessive pedantry. He said it "preserves
> alignment", not that it's legal. Presumably you would deny that
> adding 2 to an int preserves it odd/even parity, because you might
> choose INT_MAX.
>

Yes, to be a successful pedant you've got to be absolutely, precisely
accurate.

Clearly if the pointer is misaligned, adding sizeof(*ptr) will preserve the
(mis) alignment.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-31-2007
Richard Tobin wrote:
> In article <_>,
> Eric Sosman <> wrote:
>
>>> M> You will be OK. char is always 1 byte. So casting an arbitrary
>>> M> pointer to a char *, adding an exact multiple of the size of
>>> M> the original type, and casting back is guaranteed to preserve
>>> M> alignment.

>
>>> I am not so sure about that; would you care to cite C&V, please, if
>>> you claim that it's guaranteed by the standard?

>
>> He's wrong: it's not guaranteed. Simple example:
>>
>> int target = 42;
>> int *ptr = &target + 1; /* "an arbitrary pointer" */
>> ptr = (int*)((char*)ptr + sizeof *ptr); /* U.B. */
>>
>> If the original pointer points at an actual object of its
>> type (so it's not "arbitrary"), the conversion is safe.

>
> That seems to be excessive pedantry. He said it "preserves
> alignment", not that it's legal. Presumably you would deny that
> adding 2 to an int preserves it odd/even parity, because you might
> choose INT_MAX.


Adding two to an "arbitrary" integer need not preserve
parity, although adding two to most integers does. For the
two problematic integers you get undefined behavior, after
which assertions about what is and isn't preserved -- or
pickled -- just evaporate.

Adding sizeof *ptr to an "arbitrary" value of ptr need
not preserve alignment, although adding it to a restricted
class of values certainly does. But once U.B. occurs, the
Standard abdicates and no longer supports arguments that
formerly relied on it. It is wrong to claim that alignment
preservation is "guaranteed" in light of U.B.; "guaranteed"
by whom or by what?

BTW, "excessive pedantry" is unnecessarily redundant.

--
Eric Sosman
lid
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-31-2007
In article <>,
Malcolm McLean <> wrote:

>Yes, to be a successful pedant you've got to be absolutely, precisely
>accurate.
>
>Clearly if the pointer is misaligned, adding sizeof(*ptr) will preserve the
>(mis) alignment.


No. If you're a real pedant, you will observe that the undefined
behaviour of creating the misaligned pointer could be that the addition
produces an aligned one.

But the example wasn't a misaligned pointer - it was that the addition
produced a pointer outside of the object.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
Pointer to pointer conversion WaterWalk C Programming 3 05-23-2008 05:46 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM
pointer to pointer conversion pw4getter C++ 5 03-05-2004 11:41 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57