contradiction in TC++PL?

[ES Kim]

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

--
ES Kim

[JKop]

ES Kim posted:

"JKop" <NU**@NULL.NULL > wrote in message
news:1M******** ***********@new s.indigo.ie...

If you use reinterpret_cas t to convert a pointer value to an unsigned
integral value (assuming the integral type is large enough to hold the
value) and then reconvert it back, then you're left with a valid
pointer.

So while the following may be invalid:

int jack[6];

int* p = jack;

--p; //There may be overflow, for instance if p == 0

That is, if p is null pointer?
Surely you're joking, Mr. JKop. ;-)

The value for a null pointer is implementation defined.

Just because when you write:

int* k = 0;

it sets it to a null pointer, doesn't mean that the null pointer value is in
actual fact 0. Consider the following to be the definition of a pointer:

class *
{
public:
*& operator=(int value)
{
if ( !value )
{
//Set to null pointer value
}
else

...

}
};
-JKop

[Ioannis Vranos]

JKop wrote:

From the C90 draft that I have:

Wrong language dude.

Actually I had searched in C++98 unsuccessfully, that's why I fell back
to C90 (which is a subset of C++98 except of the cases where something
else is provided).
Anyway, regarding C++:
5.2.10

5 A value of integral type or enumeration type can be explicitly converted
to a pointer.64) A pointer converted
to an integer of sufficient size (if any such exists on the implementation)
and back to the same pointer type
will have its original value; mappings between pointers and integers are
otherwise implementation-defined.

The above means that you can't assign a pointer value to an unsigned,
increment the unsigned and reassign the result back to the pointer and
expect well-defined behaviour.
You can only assign a pointer to an integer than can store it, and
reassign that back.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

JKop wrote:

int jack[6];

int* p = jack;

--p; //There may be overflow, for instance if p == 0

That is, if p is null pointer?
Surely you're joking, Mr. JKop. ;-)

The value for a null pointer is implementation defined.

Just because when you write:

int* k = 0;

it sets it to a null pointer, doesn't mean that the null pointer value is in
actual fact 0. Consider the following to be the definition of a pointer:

class *
{
public:
*& operator=(int value)
{
if ( !value )
{
//Set to null pointer value
}
else

...

}
};

A null pointer never points to a valid object.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Tom Widmer]

On Tue, 19 Oct 2004 07:55:41 GMT, JKop <NU**@NULL.NULL > wrote:

ES Kim posted:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial
element is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I
think contradict the statement in the excerpt. What do you think?
Well consider this:

If you use reinterpret_cas t to convert a pointer value to an unsigned
integral value (assuming the integral type is large enough to hold the
value) and then reconvert it back, then you're left with a valid pointer.

So while the following may be invalid:

int jack[6];

int* p = jack;

--p; //There may be overflow, for instance if p == 0

How would p == 0? p can't be a null pointer since it points to jack
(!)

The reason that it is undefined is that it is illegal to form a
pointer that doesn't point within an object, or one past the end of an
object, or to "0". A debugging implementation might generate code to
enforce this.
I'd advocate that the following *is* legal:
int jack[6];

int* p = jack;

unsigned long address = reinterpret_cas t<unsigned long const>(p);

--address;
//We don't have to check for overflow because it's
//guaranteed not to occur with unsigned integrals.

p = reinterpret_cas t<int* const>(address) ;

//Now 'p' points to one before the start of the array.
But that makes p an invalid pointer value, so the above cast and
assignment have UB.
In short, I would say that it's safe to increment or decrement a pointer
however you see fit, but just watch out for overflow!
Overflow isn't really the issue, rather it is a more fundamental one
that pointer rvalues must point within an object (or one past the
end). This is partly to allow for an implementation that has special
pointer registers where pointer values are checked for validity
whenever they are loaded into the register.
To simply say "it's UB to do this" even though there's a perfect logic
behind it to illustrate what's going on, is simply being formal and
pedantic.

I don't think that talking about overflow sheds any light on the
topic; overflow is not necessarily the underlying problem.

Tom

[JKop]

So what do you think of the following, does it exhibit UB in your opinion?:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239);
}
In my own opinion, it does *not* exhibit UB.
-JKop

[Tom Widmer]

On Tue, 19 Oct 2004 11:38:11 GMT, JKop <NU**@NULL.NULL > wrote:

So what do you think of the following, does it exhibit UB in your opinion?:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239);
}
In my own opinion, it does *not* exhibit UB.

Actually, I think my statement of UB might have been a bit strong -
it's implementation defined behaviour (which may of course be defined
to do anything). For example, on DOS, such expressions can be used to
access video memory IIRC. On other platforms they might cause a crash:

"A value of integral type or enumeration type can be explicitly
converted to a pointer. A pointer converted
to an integer of sufficient size (if any such exists on the
implementation) and back to the same pointer type
will have its original value; ___mappings between pointers and
integers are otherwise implementation-defined___." (my emphasis)

So it's up to the implementation what it does when casting 297239 to a
pointer. Casting the --val back to a pointer (in the previous example)
is similarly implementation defined.

Tom

[Ioannis Vranos]

JKop wrote:

So what do you think of the following, does it exhibit UB in your opinion?:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239);
}
In my own opinion, it does *not* exhibit UB.

It invokes implementation defined behaviour.

However
long x;

long *p=&x;

p--;

is undefined behaviour.

Some explanation on this: A pointer type is not required to be
implemented as an integer type.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[JKop]

Ioannis Vranos posted:

JKop wrote:

So what do you think of the following, does it exhibit UB in your
opinion?:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239); }
In my own opinion, it does *not* exhibit UB.

It invokes implementation defined behaviour.

For the love of Christ it does nothing!
-JKop

[Ioannis Vranos]

JKop wrote:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239); }
In my own opinion, it does *not* exhibit UB.

It invokes implementation defined behaviour.

For the love of Christ it does nothing!

It invokes implementation defined behaviour. This style is used in many
systems to access specific portions of memory that provide specific
functionality.
The assignment is implementation defined, with no side effects. However
if the assignment is not valid, any attempt to dereference the pointer
invokes undefined behaviour.
This is all "legal" stuff. The standard tries to provide as much
guarantees as possible, portably.
So for example, this assignment being implementation defined guarantees
that your program will not crash or something by this assignment alone.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Richard Herring]

In message <7O************ *******@news.in digo.ie>, JKop <NU**@NULL.NULL >
writes

Ioannis Vranos posted:

JKop wrote:

So what do you think of the following, does it exhibit UB in your
opinion?:

int main()
{
long* p_blah = reinterpret_cas t<long* const>(297239); }

In my own opinion, it does *not* exhibit UB.

It invokes implementation defined behaviour.

For the love of Christ it does nothing!

Hardly "nothing". It initialises a pointer with a bit pattern that may
not represent a valid hardware address. On some platforms which have
dedicated "address registers" and check their validity, that may be
sufficient to generate some kind of hardware exception.

--
Richard Herring