pointer offsetting

[c.a.l@seznam.cz]

a) If i do
pointer = pointer_to_safe _thing - 1000;
pointer[1000] == pointer_to_safe _thing[0];

then
I am *not* accessing invalid memory. Nor i am incorrect in
mathematical sense.
Nevertheless outcome of pointer_to_safe _memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

b) And if i do (lets say array is integer)
intprt_t i;
i = pointer_to_safe _thing - 1000;
(pointer = (int*) (i+1000) ) == pointer_to_safe _thing[0];

then
It should be correct. For integers wraparound (should?).

Am i correct? I feel that it depends on what type of number system
computer uses.
Thank you in advance.

[Keith Thompson]

Re: pointer offsetting

c.a.l@seznam.cz writes:

a) If i do
pointer = pointer_to_safe _thing - 1000;
pointer[1000] == pointer_to_safe _thing[0];
>
then
I am *not* accessing invalid memory. Nor i am incorrect in
mathematical sense.
Nevertheless outcome of pointer_to_safe _memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

Right, evaluating the expression pointer_to_safe _thing - 1000 invokes
undefined behavior (note: *not* just an undefined value). This
doesn't necesssarily have anything to do with wraparound; the behavior
is undefined because the standard says so.

b) And if i do (lets say array is integer)
intprt_t i;
i = pointer_to_safe _thing - 1000;
(pointer = (int*) (i+1000) ) == pointer_to_safe _thing[0];
>
then
It should be correct. For integers wraparound (should?).

I'm not quite sure what you're doing here. Presumably intprt_t is a
typo for intptr_t. There happens to be a type by that name, declared
in <stdint.h>; it's a signed integer type capable of holding pointer
values. The result of ``pointer_to_sa fe_thing - 1000'' is of a
pointer type, not an integer type. The assignment is illegal; there's
no implicit conversion from pointers to integers.

If you make it legal by adding a cast, then you get some arbitrary
integer value; all you know about it is that you ca convert the same
value back to a pointer type and get back the original pointer value.
(Actually for intptr_t that guarantee applies only to void*.)

If intptr_t is meant to be a pointer type (int*?), then you have
exactly the same problem as in your first example.

If you can reconstruct your second example with code that will
actually compile, we can help you figure out whether the behavior is
defined. My guess is that you won't be able to do so without
producing something that's equivalent to your first example.

Am i correct? I feel that it depends on what type of number system
computer uses.

It could depend on any number of things. The standard says that the
behavior of certain operations is undefined; it doesn't necessarily
say why.

Here's another example that may or may not be relevant and/or
instructive:

int obj;
int *valid_pointer = &obj;
(valid_pointer + 1000) - 1000; /* undefined behavior */
valid_pointer + 1000 - 1000; /* equivalent to the above */
valid_pointer + (1000 - 1000); /* ok */

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[c.a.l@seznam.cz]

Re: pointer offsetting

Thanks You both much for explanation.

On 11 íj, 21:56, Keith Thompson <ks...@mib.orgw rote:

c....@seznam.cz writes:

b) And if i do (lets say array is integer)
intprt_t i;
i = pointer_to_safe _thing - 1000;
(pointer = (int*) (i+1000) ) == pointer_to_safe _thing[0];

>

then
It should be correct. For integers wraparound (should?).

>
I'm not quite sure what you're doing here. Presumably intprt_t is a
typo for intptr_t. There happens to be a type by that name, declared
in <stdint.h>; it's a signed integer type capable of holding pointer
values.

Yes, i ment integer type capable of holding pointer value. Sorry i
misspelled.

The result of ``pointer_to_sa fe_thing - 1000'' is of a
pointer type, not an integer type. The assignment is illegal; there's
no implicit conversion from pointers to integers.

Thanks i blindly presumed that for this type it is done;) Now i
checked that
it is not true.

If you make it legal by adding a cast, then you get some arbitrary
integer value; all you know about it is that you ca convert the same
value back to a pointer type and get back the original pointer value.
(Actually for intptr_t that guarantee applies only to void*.)

Now i think that safe way might be something like:

object_t* p = & obj;
object_t* newptr = NULL; /* just for dereferencing */
uintptr_t vp = 0;

vp = (intptr) (void*) p;
vp = vp + INTPTR_MAX * sizeof(*p); /* to overflow + keep alignment */
newptr = (object_t*) (void*) (vp - INTPTR_MAX * sizeof(*p));
assert (newptr == p);

a) If i'd use intptr_t instead, wraparound is not guaranteed (it is
signed value!)?
b) Was this void* cast necessary for transfering values from, to
uintptr_t?
c) Was the way i have used it with stepping by sizeof(*p) correct?
Emulation of stepping a pointer to a type ala
array[5] = array + 5 = (char*) array + 5 * (sizeof(array[0])/
sizeof(char))?

[Keith Thompson]

Re: pointer offsetting

c.a.l@seznam.cz writes:

Thanks You both much for explanation.

[...]

Now i think that safe way might be something like:

The safe way to do what?

object_t* p = & obj;
object_t* newptr = NULL; /* just for dereferencing */
uintptr_t vp = 0;

You assign values to newptr and vp; why initialize them?

vp = (intptr) (void*) p;

I think you meant:

vp = (uintptr_t)(voi d*)p;

This obtains a valid uintptr_t value by conversion from a valid
pointer value. So far, so good.

vp = vp + INTPTR_MAX * sizeof(*p); /* to overflow + keep alignment */

You can convert a void* value to uintptr_t. Converting the result
back to void* is guaranteed to give you back the original void* value.
That's the *only* thing that's guaranteed. If you modify the
uintptr_t value in any way, converting it back to void* is meaningless
(even if it happens to work on your platform). You can do anything
you like with it *as an integer*, but you've lost the association with
any meaningful pointer value.

I can't figure out what the above statement is supposed to do anyway.
For one thing, you're mixing intptr_t and uintptr_t values.

newptr = (object_t*) (void*) (vp - INTPTR_MAX * sizeof(*p));

Garbage in, garbage out.

assert (newptr == p);
>
a) If i'd use intptr_t instead, wraparound is not guaranteed (it is
signed value!)?

Since uintptr_t is an unsigned type, arithmetic on it has wraparound
semantics. Since intptr_t is signed, overflow invokes undefined
behavior. Neither of these is relevant in any portable way to their
relationship to pointers.

b) Was this void* cast necessary for transfering values from, to
uintptr_t?

I think so.

c) Was the way i have used it with stepping by sizeof(*p) correct?
Emulation of stepping a pointer to a type ala
array[5] = array + 5 = (char*) array + 5 * (sizeof(array[0])/
sizeof(char))?

No, though it might happen to work on your platform.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Barry Schwarz]

Re: pointer offsetting

On Thu, 11 Oct 2007 19:39:30 +0000 (UTC), roberson@ibd.nr c-cnrc.gc.ca
(Walter Roberson) wrote:

>In article <1192130548.100 801.171110@o3g2 000hsb.googlegr oups.com>,
<c.a.l@seznam.c zwrote:

>>a) If i do
>>pointer = pointer_to_safe _thing - 1000;
>>pointer[1000] == pointer_to_safe _thing[0];

>

>>then
>>I am *not* accessing invalid memory. Nor i am incorrect in
>>mathematica l sense.
>>Nevertheles s outcome of pointer_to_safe _memory - 1000 operation
>>yielding pointer may be undefined. For i do not know whether pointers
>>wraparound like integers?

>
>Implementati on dependant. You can only *safely* have a pointer
>that is NULL, or points into an object, or points "one past" the end
>of the object.

Nope. It is undefined behavior (n1124, 6.5.6-8)



Remove del for email

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Re: pointer offsetting

On Sat, 13 Oct 2007 18:48:38 -0700, Barry Schwarz wrote:

On Thu, 11 Oct 2007 19:39:30 +0000 (UTC), roberson@ibd.nr c-cnrc.gc.ca
(Walter Roberson) wrote:
>

>>In article <1192130548.100 801.171110@o3g2 000hsb.googlegr oups.com>,
><c.a.l@seznam. czwrote:

>>>a) If i do
>>>pointer = pointer_to_safe _thing - 1000; pointer[1000] ==
>>>pointer_to_s afe_thing[0];

>>

>>>then
>>>I am *not* accessing invalid memory. Nor i am incorrect in mathematical
>>>sense.
>>>Neverthele ss outcome of pointer_to_safe _memory - 1000 operation
>>>yielding pointer may be undefined. For i do not know whether pointers
>>>wraparound like integers?

>>
>>Implementatio n dependant. You can only *safely* have a pointer that is
>>NULL, or points into an object, or points "one past" the end of the
>>object.

>
Nope. It is undefined behavior

Undefined behaviour is inherently implementation dependent.

(n1124, 6.5.6-8)

If you're going to refer to a draft, could you please refer to n1256?
It's available in the same format as n1124 (PDF), but it's more recent.

[Joachim Schmitz]

Re: pointer offsetting

"Harald van D?k" <truedfx@gmail. comschrieb im Newsbeitrag
news:fet2ui$s4k $1@news2.zwoll1 .ov.home.nl...

On Sat, 13 Oct 2007 18:48:38 -0700, Barry Schwarz wrote:

>On Thu, 11 Oct 2007 19:39:30 +0000 (UTC), roberson@ibd.nr c-cnrc.gc.ca
>(Walter Roberson) wrote:
>>

>>>In article <1192130548.100 801.171110@o3g2 000hsb.googlegr oups.com>,
>><c.a.l@seznam .czwrote:
>>>>a) If i do
>>>>pointer = pointer_to_safe _thing - 1000; pointer[1000] ==
>>>>pointer_to_ safe_thing[0];
>>>
>>>>then
>>>>I am *not* accessing invalid memory. Nor i am incorrect in mathematical
>>>>sense.
>>>>Nevertheles s outcome of pointer_to_safe _memory - 1000 operation
>>>>yielding pointer may be undefined. For i do not know whether pointers
>>>>wraparoun d like integers?
>>>
>>>Implementati on dependant. You can only *safely* have a pointer that is
>>>NULL, or points into an object, or points "one past" the end of the
>>>object.

>>
>Nope. It is undefined behavior

>
Undefined behaviour is inherently implementation dependent.
>

>(n1124, 6.5.6-8)

>
If you're going to refer to a draft, could you please refer to n1256?

n1124 is not a draft, it is C99 plus TC 1 and TC2, while n1256 is C99 + Tc1,
TC2 and TC3.
Or if n1124 is a draft, n1256 is one too
The pre C99 draft has a 3 digit namber which escapes me at this moment...

It's available in the same format as n1124 (PDF), but it's more recent.

True

Bye, Jojo

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Re: pointer offsetting

On Sun, 14 Oct 2007 16:53:32 +0200, Joachim Schmitz wrote:

"Harald van D?k" <truedfx@gmail. comschrieb im Newsbeitrag
news:fet2ui$s4k $1@news2.zwoll1 .ov.home.nl...

>On Sat, 13 Oct 2007 18:48:38 -0700, Barry Schwarz wrote:

>>(n1124, 6.5.6-8)

>>
>If you're going to refer to a draft, could you please refer to n1256?

n1124 is not a draft, it is C99 plus TC 1 and TC2,

As I recall, some DRs have been resolved between TC2 and n1124. n1124 is
a draft, and different from C99+TC1+TC2.

while n1256 is C99 +
Tc1, TC2 and TC3.

I do not know if n1256 differs from C99+TC1+TC2+TC3 . C99 TC3 does not
appear to be available yet.

Or if n1124 is a draft, n1256 is one too The pre C99 draft has a 3 digit
namber which escapes me at this moment...

n869, which has the advantage of being available in plain text format.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Re: pointer offsetting

On Sun, 14 Oct 2007 12:49:32 -0700, Keith Thompson wrote:

Harald van Dijk <truedfx@gmail. comwrites:

>I do not know if n1256 differs from C99+TC1+TC2+TC3 . C99 TC3 does not
>appear to be available yet.

>
It is; you can download
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1235.pdf>.

I had completely missed this bit when I first read and replied to your
message. Thanks.

[Peter Pichler]

Re: pointer offsetting

Keith Thompson wrote:

>>b) And if i do (lets say array is integer)
>>intprt_t i;
>>i = pointer_to_safe _thing - 1000;
>>(pointer = (int*) (i+1000) ) == pointer_to_safe _thing[0];
>>
>>then
>>It should be correct. For integers wraparound (should?).

>
I'm not quite sure what you're doing here. Presumably intprt_t is a
typo for intptr_t. There happens to be a type by that name, declared
in <stdint.h>; it's a signed integer type capable of holding pointer
values. The result of ``pointer_to_sa fe_thing - 1000'' is of a
pointer type, not an integer type. The assignment is illegal; there's
no implicit conversion from pointers to integers.
>
If you make it legal by adding a cast, then you get some arbitrary
integer value; all you know about it is that you ca convert the same
value back to a pointer type and get back the original pointer value.
(Actually for intptr_t that guarantee applies only to void*.)

He might get away with casting the pointer first, before subtracting
1000. The rest is just integer arithmetic. It may still fall down if i
overflows.

[Peter Pichler]

Re: pointer offsetting

Keith Thompson wrote:

Peter Pichler <usenet@pichler .co.ukwrites:
>

>>He might get away with casting the pointer first,

<snip>

But what's the point?

I didn't say there was one. What's the point of the whole exercise? ;-)

[lawrence.jones@ugs.com]

Re: pointer offsetting

Keith Thompson <kst-u@mib.orgwrote:

Harald van D?k <truedfx@gmail. comwrites:

>>
>As I recall, some DRs have been resolved between TC2 and n1124. n1124 is
>a draft, and different from C99+TC1+TC2.

>
Really? That's news to me (and the "ISO/IEC 9899:TC2" in the page
headers seems to imply otherwise). Can you or someone else confirm
this, preferably with details?

N1124 was intended to be substantively identical to C99+TC1+TC2 just as
N1256 is intended to be substantively identical to C99+TC1+TC2+TC3 .
However, the editor (yours truly) reserves the right to make editorial
changes in the process of applying the TCs to make the text read better
and has also been known to slip in minor editorial changes in the
process (e.g., somewhere along the way, I switched from "one's
complement" to "ones' complement" based on Knuth's argument for the
latter and there have also been a number of improvements to the index).
Non-trivial changes usually show up in a "cleanup" DR to be formally
adopted by the committee, but we don't always bother for trivial and
inconsequential changes (such as the index changes).

The only significant difference I know of in N1124 is that TC2 made a
change to the description of the "g" conversion specifier in the
description of fprintf in 7.19.6.1 but did not make the parallel change
to the description of fwprintf in 7.24.2.1. Since the same source code
is used for both, N1124 does have the change to 7.24.2.1 even though it
wasn't formally adopted until TC3.

-Larry Jones

The hardest part for us avant-garde post-modern artists is
deciding whether or not to embrace commercialism. -- Calvin

[Barry Schwarz]

Re: pointer offsetting

On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<truedfx@gmail. comwrote:

>On Sat, 13 Oct 2007 18:48:38 -0700, Barry Schwarz wrote:

>On Thu, 11 Oct 2007 19:39:30 +0000 (UTC), roberson@ibd.nr c-cnrc.gc.ca
>(Walter Roberson) wrote:
>>

>>>In article <1192130548.100 801.171110@o3g2 000hsb.googlegr oups.com>,
>><c.a.l@seznam .czwrote:
>>>>a) If i do
>>>>pointer = pointer_to_safe _thing - 1000; pointer[1000] ==
>>>>pointer_to_ safe_thing[0];
>>>
>>>>then
>>>>I am *not* accessing invalid memory. Nor i am incorrect in mathematical
>>>>sense.
>>>>Nevertheles s outcome of pointer_to_safe _memory - 1000 operation
>>>>yielding pointer may be undefined. For i do not know whether pointers
>>>>wraparoun d like integers?
>>>
>>>Implementati on dependant. You can only *safely* have a pointer that is
>>>NULL, or points into an object, or points "one past" the end of the
>>>object.

>>
>Nope. It is undefined behavior

>
>Undefined behaviour is inherently implementation dependent.
>

Implementation dependent implies that the behavior will be consistent
on a particular implementation (the same today as it was yesterday).
Undefined behavior is not so constrained.


Remove del for email

[James Kuyper Jr.]

Re: pointer offsetting

Barry Schwarz wrote:

On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<truedfx@gmail. comwrote:

....

>Undefined behaviour is inherently implementation dependent.
>>

Implementation dependent implies that the behavior will be consistent
on a particular implementation (the same today as it was yesterday).

Citation, please?

"Implementa tion-dependent behavior" isn't a term defined in the C
standard. It's normal English meaning is only that the behavior depends
upon which implementation you use, which is certainly true for undefined
behavior. I don't see any implication that the behavior has to be
consistent.

[CBFalconer]

Re: pointer offsetting

lawrence.jones@ ugs.com wrote:

>

.... snip ...

>
The only significant difference I know of in N1124 is that TC2
made a change to the description of the "g" conversion specifier
in the description of fprintf in 7.19.6.1 but did not make the
parallel change to the description of fwprintf in 7.24.2.1.
Since the same source code is used for both, N1124 does have the
change to 7.24.2.1 even though it wasn't formally adopted until
TC3.

Glad to see you here. Please consider publishing a text version of
N1256, as you [1] did for N869. This is much more useful than a
PDF version for many purposes.

[1] collective you :-)

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