Re: [PATCH] enable -Wformat-length for dynamically allocated buffers (pr 78245)

[Jeff Law <law at redhat dot com>]

On 11/29/2016 08:22 PM, Martin Sebor wrote:
> > > > That said, I defer to you on how to proceed here.  I'm prepared
> > > > to do the work(*) but I do worry about jeopardizing the chances
> > > > of this patch and the others making it into 7.0.
> > > So would it make sense to just init/fini the b_o_s framework in your
> > > pass and for builtin expansion?
> >
> > I think that should work for the sprintf checking.  Let me test it.
> > We can deal with the memxxx and strxxx patch (53562) independently
> > if you prefer.
>
> Attached is a modified patch that calls {init,fini}_object_sizes()
> from the gimple-ssa-sprintf pass instead.
>
> While this works fine, I do like the approach of making the calls
> in a single function better because it makes for a more robust API.
> Decoupling the init/fini calls from the compute_object_size()
> function that depends on them having been made makes the API easier
> to accidentally misuse by calling one while forgetting to call one
> or both of the other two.
It's not ideal, nor is the prospect of caching and potentially not 
invaliding properly.

I've started tackling these kinds problems by wrapping everything into a 
class with suitable ctors/dtors and methods.  With everything locked 
down inside a class, the only way to access the subsystem is by 
instantiating a suitable object (which obviously gives us control over 
init/fini).  The problem then boils down to not having that instantiated 
object live across passes, which usually isn't a problem in GCC :-)

I suggested it as a possibility, but wasn't going to demand it without 
knowing much more about the code in tree-object-size and how well it 
could be encapsulated.

ANyway, I'll take another look at the patch.  My recollection was that 
the only issue at hand was the init/fini/caching aspects.


jeff