Re: [PATCH] Updated buffer overflow protection patch

[Diego Novillo <dnovillo at redhat dot com>]

On Wed, 2004-10-27 at 13:12, Jakub Jelinek wrote:

> gets is not a builtin (and not sure why it should be).  This is something
> that can be trivially dealt in the headers, so the compiler doesn't need
> to be involved.
> 
I meant the builtins we already know about.  But it's more of a minor
issue.  If the glibc folks are happy with it, I don't mind too much.


> I think it is better to keep policy decision in libc's hands
> (or aux library with <string.h>/<stdio.h> using #include_next),
> I don't see what we would gain by hardcoding it in GCC.
> 
Fair enough.

> If it is not computed on-demand, then all pointers need to have object sizes
> computed 4 values (maximum object size, maximum subobject size, minimum
> object size, minimum subobject size).
> 
Yes, they do.  Much as they all have alias/points-to info even if
they're not seemingly used.  Remember that other transformations may
suddenly cause you to care about these attributes.

> > Hmm?  I thought the second argument for __bos was a boolean?  We have
> 
> It is not, it is an integer from 0 to 3 (well, essentially a bitmask).
> 
Then you are lying in doc/extend.texi ;)

What's this bit mask then?

> > the capability of counting number of iterations in a loop.  If the loop
> > is countable, you could easily deduce what would be the value of p at
> > the end (Sebastian, Zdenek, is this correct?)
> 
> __bos can be used also within the loop, plus it should handle uncountable
> loops as well.
>
Oh, absolutely.  In which case you'd have to fold it into -1.


> I'd appreciate that.  I'll try to help as soon as you have something.
> gcc.dg/builtin-object-size-{1,2,3,4,5}.c tests cover __bos quite a lot,
> so it will be easy to find out if the new implementation covers at least
> all the cases as my current one and whether it covers even more things.
> 
Sure.  Could you send me an updated patch?  The one I have didn't apply
cleanly.


> For me the more important part is the use visible interface, how exactly
> the propagator works is only an implementation detail that can be changed
> in the future when needed.  __bos is always allowed to return a safe
> "don't know" value, therefore in the future __bos can handle more cases
> precisely.
> 
Agreed.  At this point, I think that we could try it out internally and
see about adding it on 4.1.  You will need another maintainer to go over
the builtin-specific parts.  Not my area of approval.


Diego.