pointer conversion

[junky_fellow@yahoo.co.in]

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.

[Malcolm McLean]

Re: pointer conversion


<junky_fellow@y ahoo.co.inwrote in message
news:1188533039 .039419.116570@ i38g2000prf.goo glegroups.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

[Charlton Wilbur]

Re: pointer conversion

>>>>"M" == Malcolm McLean <regniztar@btin ternet.comwrite s:

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

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
cwilbur@chromat ico.net

[Malcolm McLean]

Re: pointer conversion


"Charlton Wilbur" <cwilbur@chroma tico.netwrote in message
news:87abs7wu2c .fsf@mithril.ch romatico.net...

>>>>>"M" == Malcolm McLean <regniztar@btin ternet.comwrite s:

>
MYou will be OK. char is always 1 byte. So casting an arbitrary
Mpointer to a char *, adding an exact multiple of the size of
Mthe original type, and casting back is guaranteed to preserve
Malignment.
>
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

[Eric Sosman]

Re: pointer conversion

Charlton Wilbur wrote:

>>>>>"M" == Malcolm McLean <regniztar@btin ternet.comwrite s:

>
MYou will be OK. char is always 1 byte. So casting an arbitrary
Mpointer to a char *, adding an exact multiple of the size of
Mthe original type, and casting back is guaranteed to preserve
Malignment.
>
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*)p tr + 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
esosman@ieee-dot-org.invalid

[Richard Tobin]

Re: pointer conversion

In article <_eidnezKNPZ67E XbnZ2dnUVZ_vShn Z2d@comcast.com >,
Eric Sosman <esosman@ieee-dot-org.invalidwrot e:

> MYou will be OK. char is always 1 byte. So casting an arbitrary
> Mpointer to a char *, adding an exact multiple of the size of
> Mthe original type, and casting back is guaranteed to preserve
> Malignment.

>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*)p tr + 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

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Malcolm McLean]

Re: pointer conversion


"Richard Tobin" <richard@cogsci .ed.ac.ukwrote in message
news:fb9ran$1fa p$1@pc-news.cogsci.ed. ac.uk...

In article <_eidnezKNPZ67E XbnZ2dnUVZ_vShn Z2d@comcast.com >,
Eric Sosman <esosman@ieee-dot-org.invalidwrot e:
>

>> MYou will be OK. char is always 1 byte. So casting an arbitrary
>> Mpointer to a char *, adding an exact multiple of the size of
>> Mthe original type, and casting back is guaranteed to preserve
>> Malignment.

>

>>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*)p tr + 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

[Eric Sosman]

Re: pointer conversion

Richard Tobin wrote:

In article <_eidnezKNPZ67E XbnZ2dnUVZ_vShn Z2d@comcast.com >,
Eric Sosman <esosman@ieee-dot-org.invalidwrot e:
>

>> MYou will be OK. char is always 1 byte. So casting an arbitrary
>> Mpointer to a char *, adding an exact multiple of the size of
>> Mthe original type, and casting back is guaranteed to preserve
>> Malignment.

>

>>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*)p tr + 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
esosman@ieee-dot-org.invalid

[Richard Tobin]

Re: pointer conversion

In article <K6mdnV5WebJ360 XbnZ2dneKdnZydn Z2d@bt.com>,
Malcolm McLean <regniztar@btin ternet.comwrote :

>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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

Re: pointer conversion

In article <D5Kdna6POqdW50 XbnZ2dnUVZ_gedn Z2d@comcast.com >,
Eric Sosman <esosman@ieee-dot-org.invalidwrot e:

BTW, "excessive pedantry" is unnecessarily redundant. ;-)

I thought the comp.lang.c view was that it's an oxymoron.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Malcolm McLean]

Re: pointer conversion


"Richard Tobin" <richard@cogsci .ed.ac.ukwrote in message
news:fb9ura$1g6 t$2@pc-news.cogsci.ed. ac.uk...

In article <K6mdnV5WebJ360 XbnZ2dneKdnZydn Z2d@bt.com>,
Malcolm McLean <regniztar@btin ternet.comwrote :
>

>>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.
>

I surrender. Yes, the misaligned pointer can only be assigned to a pointer
of that type with UB, after which any futher operations are allowed to
produce any results whatsoever.

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

That's an example of useful pedantry. I should have specified that the
operation is not safe, if the new pointer cannot be contained in the old
object.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[CBFalconer]

Re: pointer conversion

Eric Sosman wrote:

>

.... snip ...

>
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.

Oh? When I was in primary school:

4 had 1 bit
4 + 2 is 6, with 2 bits
6 + 2 is 8, with 1 bit

which doesn't seem to preserve parity.

--
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

[Richard Tobin]

Re: pointer conversion

In article <46D8909B.B75A6 70@yahoo.com>,
CBFalconer <cbfalconer@mai neline.netwrote :

>Oh? When I was in primary school:
>
4 had 1 bit
4 + 2 is 6, with 2 bits
6 + 2 is 8, with 1 bit
>
>which doesn't seem to preserve parity.

Oops. I was using the term "parity" in the mathematical sense of
whether a number is odd or even; not in the computer sense of whether
it has an odd or even number of bits set. I used the phrase "odd/even
parity" to emphasize the kind of parity I meant, but of course it does
nothing of the kind.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Barry Schwarz]

Re: pointer conversion

On 31 Aug 2007 12:24:43 -0400, Charlton Wilbur
<cwilbur@chroma tico.netwrote:

>>>>>"M" == Malcolm McLean <regniztar@btin ternet.comwrite s:

>
MYou will be OK. char is always 1 byte. So casting an arbitrary
Mpointer to a char *, adding an exact multiple of the size of
Mthe original type, and casting back is guaranteed to preserve
Malignment.
>
>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?
>

It follows directly from paragraph 2 in section 6.5.2.1 and the first
few sentences of paragraph 8 in section 6.5.6 of n1124.

While the arithmetic is guaranteed to preserve alignment, it can still
invoke undefined behavior. If the resulting address is not within (or
just 1 past the end of) the original object, the next to last sentence
of paragraph 8 of section 6.5.6 applies.


Remove del for email