[apparmor] [patch] more gcc 5 errors

[John Johansen]

On 02/17/2015 12:33 PM, Steve Beattie 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.
> 
> I agree about thrashing around in the dark and I don't really like
> dropping the return value on the floor, either.
> 
>> What of all the other places we have a similar pattern? Why are
>> they passing
> 
> Well, we don't actually have other places that invoke a method that
> returns an ostream reference (unless I overlooked something). In a
> simple grep, it looked like every time we called a method in a <<
> pipeline, what was returned was a data item to be output directly.
> I may have missed a variable of type ostream& (a la the 'os' variable
> that the commit Seth made addressed), but nothing jumped out at me.
> 
well we actually have a lot of the pattern where ostream & is returned
but those (with the patches applied) don't end up using their return
value.
  ie. we invoke dump(os) but don't do  os << dump(os)

We do have instances where the returned ostream reference is used they
are all operator<< but that shouldn't matter as it is just a fn, unless
gcc 5 is special casing the << operator fn

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);