pointer offsetting

[c.a.l]

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]

c.***@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_safe_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_Keith) ks***@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]

Thanks You both much for explanation.

On 11 íj, 21:56, Keith Thompson <[e-mail]:

[e-mail] 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_safe_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]

c.***@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)(void*)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_Keith) ks***@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]

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

>In article <11**********************@o3g2000hsb.googlegroups. com>,
<c.***@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.
Nevertheless outcome of pointer_to_safe_memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

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

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

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

>>In article <11**********************@o3g2000hsb.googlegroups. com>,
<c.***@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.
Nevertheless outcome of pointer_to_safe_memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

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

"Harald van D?k" <tr*****@gmail.comschrieb im Newsbeitrag
news:fe**********@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), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:

>>>In article <11**********************@o3g2000hsb.googlegroups. com>,
<c.***@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.
Nevertheless outcome of pointer_to_safe_memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

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

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

"Harald van D?k" <tr*****@gmail.comschrieb im Newsbeitrag
news:fe**********@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]

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

Harald van Dijk <tr*****@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]

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

Keith Thompson wrote:

Peter Pichler <us****@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]

Keith Thompson <ks***@mib.orgwrote:

Harald van D?k <tr*****@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]

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

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

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

>>>In article <11**********************@o3g2000hsb.googlegroups. com>,
<c.***@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.
Nevertheless outcome of pointer_to_safe_memory - 1000 operation
yielding pointer may be undefined. For i do not know whether pointers
wraparound like integers?

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

Barry Schwarz wrote:

On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<tr*****@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?

"Implementation-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]

la************@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

[CBFalconer]

Keith Thompson wrote:

Harald van D©¦k <tr*****@gmail.comwrites:

>Joachim Schmitz wrote:

.... snip ...

>

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

PDF can be converted to plain text (with some loss of information).

N869 is available in a properly formatted text version, unlike the
others. So called 'text conversion' just leaves a mess. After
page information is stripped from N869, and the indentation is
reduced, the result is available (compressed) as n869_txt.bz2 at:

<http://cbfalconer.home.att.net/download/>

and is quite suitable for quoting, grepping, etc.

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

[Barry Schwarz]

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<ja*********@verizon.netwrote:

>Barry Schwarz wrote:

>On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<tr*****@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?

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

If the behavior is implementation-dependent (I agree with your normal
meaning), and if the implementation doesn't changed, it is reasonable
to conclude that the behavior won't either. If it does, then it
depends on something other (or something more) than the
implementation. Undefined behavior offers no such assurances.
Remove del for email

[jameskuyper]

Barry Schwarz wrote:

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<ja*********@verizon.netwrote:

Barry Schwarz wrote:

On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D )& k
<tr*****@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?

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

If the behavior is implementation-dependent (I agree with your normal
meaning), and if the implementation doesn't changed, it is reasonable
to conclude that the behavior won't either. If it does, then it
depends on something other (or something more) than the
implementation. Undefined behavior offers no such assurances.

To say that something depends upon one thing is not the same as saying
that it depends only upon that thing.

If, with implementation A, the behavior depends upon the day of the
week, and with implementation B the behavior depends upon whether or
not the current month has an 'r' in it, then the behavior is
implementation dependent, even though knowing which implementation
you're using is not sufficient to determine what the behavior actually
is. The behavior is also, in both cases, time dependent, which does
not conflict with the fact that it is also implementation-dependent.

[Eric Sosman]

Barry Schwarz wrote On 10/19/07 13:27,:

On Wed, 17 Oct 2007 13:35:44 GMT, "James Kuyper Jr."
<ja*********@verizon.netwrote:

>>Barry Schwarz wrote:

>>>On Sun, 14 Oct 2007 12:44:02 +0000 (UTC), $)CHarald van D)&k
<tr*****@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?

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

If the behavior is implementation-dependent (I agree with your normal
meaning), and if the implementation doesn't changed, it is reasonable
to conclude that the behavior won't either. If it does, then it
depends on something other (or something more) than the
implementation. Undefined behavior offers no such assurances.

Where is it written that "the implementation" can
have no time-varying components? The behavior of

puts( __TIME__ );

.... clearly changes as the module is compiled and recompiled,
and although __TIME__ itself is not implementation-defined
its value certainly is. Can't the rest of the implementation
have at least this much freedom?

--
Er*********@sun.com