From mboxrd@z Thu Jan  1 00:00:00 1970
From: Florian Weimer <fw@deneb.enyo.de>
To: mike stump <mrs@windriver.com>
Cc: eager@mvista.com, gcc@gcc.gnu.org, jsm28@cam.ac.uk
Subject: Re: Buffer Overflow Attacks
Date: Wed, 31 Oct 2001 10:01:00 -0000
Message-id: <87668vk6rp.fsf@deneb.enyo.de>
References: <200110182359.QAA00865@kankakee.wrs.com>
X-SW-Source: 2001-10/msg01612.html

mike stump <mrs@windriver.com> writes:

> Well, I can't comment on the exact code you gave, but I can comment on
> C++ and code like this:
> 
> struct foo {
>   char c[31];
>   int i;
    int j;

(Otherwise the argument below is wrong, especially if sizeof(int)
equals sizeof(char).)

> } f;
> 
>   *(((char*)&f)+32) and *(((char*)&f)+33) are allowed.

Yes, that's right even for C.  But this doesn't help in the case I
originally presented.  While we certainly have (&(f.c[30])) equal to
(((char *)&f) + 30) (they both refer to the same object), it occured
to me that &(f.c[32]) is indeed undefined, but (((char *)&f) + 32) is
defined.  It's a bit funny that if two objects which compare equal
show such different behavior, but I think that's way it's specified in
the standard.

So I have to retract my original claim that it was impossible to do
buffer overflow checks in such cases.  After all, a pointer in C-speak
(or "address", as in "address-of operator") is not very similar to a
machine address.