Do all arrays have to have a pad byte after them?
Valentin Bonnard
bonnardv@pratique.fr
Tue Nov 17 09:50:00 GMT 1998
Hyman Rosen wrote:
>
> Dave Brolley writes:
> > While comparing the pointers one past the end is defined, dereferencing
> > them is not.
That's _not_ very clear actually.
> > There is no need for a padding byte to actually be allocated
> > in memory. Even so, I would expect the test to print "failed" when
> > compiled with most compilers.
>
> I repeat the quote from the standard, section 5.10 -
>
> Two pointers of the same type compare equal if and only if they are
> both null, both point to the same object or function, or both point
> one past the end of the same array.
>
> And here's my code:
>
> extern "C" int printf(const char *, ...);
> int main()
> {
> struct { char a[8], b[8]; } z;
> bool b = &z.a[8] == &z.b[0];
> printf("%s\n", b ? "failed" : "succeeded");
> }
>
> Now, &z.a[8] points one past the end of array z.a, and &z.b[0] points
> at z.b[0].
Yes
> If these two pointers compare equal, then the compiler is
> in violation of the "only if" part of the quoted section.
No
> I know most compilers will fail this, including egcs. That's why I reported this
> as a bug. Is my analysis incorrect?
If it were correct, it would be a language layer problem, and that's
not really appropriate here (that would be more appropriate in
comp.std.c++).
But you failed to prove your point:
- (1) that both pointers don't point one-past-the-end
- and (2) that both pointers don't point to the first element
I dislike the current wording, because in such cases it isn't
clear when a one-past-the-end is dereferencable, not because
it breaks egcs (it does not).
<CUTING HAIRS>
BTW, your example isn't valid because the function ::printf
might not exists, and if it does, it can have C++ linkage.
So your code has undefined behaviour.
Moral: don't declare yourself standard functions or types.
</CUTS>
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
More information about the Gcc-bugs
mailing list