On Mon, Jun 04, 2012 at 11:59:59AM +0200, Florian Weimer wrote:
> What about this?
>
> +This protection mechanism is only a last resort. As a programmer, you
> +must not rely on its presence, but use explicit buffer length checks
> +to avoid buffer overflows. GCC may not be able to determine object
> +sizes with sufficient precision (that is, the reported sizes can be
> +larger than what is actually available at run time), and the accuracy
> +depends on compiler version and options.
That isn't correct. __builtin_object_size, as documented a few lines below
what you are editing, is documented to have 4 different possible values of
second argument, and it can be larger than what is available only for values
0 and 1, for values 2 and 3 it must be equal or smaller only, and if you
want to test whether it is precise, you can compare results of two
__builtin_object_size calls.
> In a sense, GCC *is* wrong, but of course, the problem is unsolvable
> in the general case.
In a very weird sense. The primary design goal of this feature is that
it is very cheap lightweight check, so no mudflap or similar instrumenting
of all pointers, changing the ABI of all function calls that pass around
pointers, changing the layout of structures etc. and no large on the side
hash tables. Even for simple:
char buf[64];
strcpy (buf + (foo ? 4 : 8), bar);
__builtin_object_size can only return one value, so that would be
60 as upper bound and 56 as lower bound in the ideal case here.
Jakub
