Re: Unsigned types are DANGEROUS??
On 14 Mrz., 16:03, Michael Doubez wrote:
On 14 mar, 15:20, SG wrote:
Yes, I think this is a bit of a gray area. Avoid it if you can. If I
recall correctly, pointer arithmetic is restricted to stay inside some
array (including "one element past the end"). Here, n is an array of
arrays. n[1] selects the second array and the additional [-1] steps
out of that 2nd array. If I recall correctly, James Kanze talked about
a possible debugging implementation which would augment pointers to
store additional information to enable runtime checking of index-out-
of-bounds conditions w.r.t. pointer arithmetic and op[]. IIRC, he
claimed this implementation to be conforming. But it would obviously
"break" your example.
An implementation storing data before or after each array would be
problematic indeed.
It would also break n[1][1] == (&n[0][0])[3] which would be
surprising.
I think you misunderstood. I was talking about the possibility of an
implementation that makes raw pointers more intelligent for debugging
purposes. Imagine a "raw pointer" that not only stores the adress but
also a range of possibly valid "indices". A built-in version of
struct raw_pointer {
char* address;
ptrdiff_t begin_idx, end_idx;
};
so-to-speak where an array-to-pointer decay in a case like
void foo(int * r) {
r += 9; // <-- runtime check fails, program aborts
}
void bar() {
int arr[5];
int* p = arr;
int* q = p+1;
foo(p);
}
would make p store the address of the first element along with 0 and 5
as an index pair and q the adress of the second array element with an
index pair -1 and 4.
Now, I'm not aware of any such implementation and I'm not claiming
this to be a good idea. But IIRC James Kanze hinted at something like
this and claimed it to be conforming to the C++ ISO standard.
I could not find a guarantee of continuity of the layout in the
standard to back up that claim and, to my untrained eye, it carefully
steps around the issue.
Well, it would surprize me if sizeof(T[N])==N*sizeof(T) was not
satisfied. But I am not aware of any such guarantee, either.
[...]
Which tends to hint that E1 is however converted into a pointer and no
special treatment is performed because E1 is of array type. In this
case, I expect normal pointer arithmetic applies and a negative
integral part of the subscript operator is acceptable provided you
stay within the underlying object.
As I said, IIRC James Kanze claimed this to be "formally U.B.".
Cheers!
SG