Do all arrays have to have a pad byte after them?

Valentin Bonnard
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]. 


> If these two pointers compare equal, then the compiler is
> in violation of the "only if" part of the quoted section.


> 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 

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

    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.


Valentin Bonnard      
info about C++/a propos du C++:

More information about the Gcc-bugs mailing list