[apparmor] [patch] more gcc 5 errors

[John Johansen]

On 02/17/2015 12:07 PM, Seth Arnold wrote:
> On Tue, Feb 17, 2015 at 11:44:42AM -0800, John Johansen wrote:
>> On 02/17/2015 11:36 AM, Steve Beattie wrote:
>>> On Thu, Feb 12, 2015 at 12:40:41PM -0800, Seth Arnold wrote:
>>>> (I don't have an easy way to test the build with gcc-5, so this may not be
>>>> exhaustive.)
>>>
>>> Even with the fix applied, the parser still fails to build with gcc-5,
>>> with the errors:
>>>
>>>   http://paste.ubuntu.com/10278117/
>>>
>>> The following patch lets the parser build both under gcc-5 and gcc-4.9.
>>> I'm not sure why gcc-5 thinks the types returned by dump_XXXX are wrong.
>>>
>>> Signed-off-by: Steve Beattie <steve at nxnw.org> for both trunk and 2.9.
>>
>> The patch is fine but this sure feels like thrashing about in the dark,
>> it doesn't actually change the return value just stops using it. What
>> of all the other places we have a similar pattern? Why are they passing
> 
> Acked-by: Seth Arnold <seth.arnold at canonical.com>
> for both trnuk and 2.9.
> 
> I don't think I've seen many functions take or return 'ostream' as a
> parameter; perhaps the Better Solution is to make an af_rule::operator<<()
> method instead, so it'll feel more C++-ey.
> 
> But I think that can wait.
> 
Actually we already do, do that

rule.cc:std::ostream &operator<<(std::ostream &os, rule_t &rule)
rule.h:std::ostream &operator<<(std::ostream &os, rule_t &rule);

libapparmor_re/expr-tree.cc:ostream &operator<<(ostream &os, uchar c)
libapparmor_re/expr-tree.cc:ostream &operator<<(ostream &os, const NodeSet &state)
libapparmor_re/expr-tree.cc:ostream &operator<<(ostream &os, Node &node)
libapparmor_re/expr-tree.h:ostream &operator<<(ostream &os, uchar c);
libapparmor_re/expr-tree.h:ostream &operator<<(ostream &os, const NodeSet &state);
libapparmor_re/expr-tree.h:ostream &operator<<(ostream &os, Node &node);

libapparmor_re/hfa.cc:ostream &operator<<(ostream &os, const CacheStats &cache)
libapparmor_re/hfa.cc:ostream &operator<<(ostream &os, const ProtoState &proto)
libapparmor_re/hfa.cc:ostream &operator<<(ostream &os, const State &state)
libapparmor_re/hfa.h:ostream &operator<<(ostream &os, const State &state);

the problem is that, << only gets you 1 output and we have different output cases.
Also because how C++ is setup using operator<< is actually an external fn, that
is match off of the fn template so often we just make it a wrapper around one
of the dump or output methods