[apparmor] [patch] more gcc 5 errors

[John Johansen]

On 02/17/2015 03:15 PM, Steve Beattie wrote:
> On Tue, Feb 17, 2015 at 01:10:34PM -0800, John Johansen wrote:
>> 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);
> 
> I'm probably about to expose to the world once again my complete lack of
> understanding of C++ types and operators, but I *think* the distinction
> is that when we have something like:
> 
>   os << dump(os);
> 
> the resulting function call looks like:
> 
>   operator<<(os, dump(os));
> 
> which would have types
> 
>   ostream &operator<<(ostream &os, ostream &os)
> 
yeah, basically, I don't think our use of dump returning ostream&
is a good use. the << operator is infix and transforms the code
which you don't get with the direct fn/method call.  So it becomes
hard to correctly mix dump() with <<

  dump(cerr, ...) << "foo";

is good but
  cerr << dump(cerr, ...) << foo;

is not, because as you said it results in << calling

  ostream &operator<<(ostream &, ostream&) instead of

ostream &operator<<(ostream &, type)

> as opposed to e.g. calling:
> 
>   os << state;
> 
> which would be
> 
>   operator<<(os, state);
> 
> and with types
> 
>   ostream &operator<<(ostream &os, const State &state)
> 
yeah basically, I'm just baffled why it ever worked

> I'm *guessing* gcc-4.9 maybe had some glue that would paper over
> that, but searching online hasn't turned up anything that I can see
> that references any changes in behavior here. (Nothing obvious at
> https://gcc.gnu.org/gcc-5/changes.html jumps out at me.)
> 
Maybe, but it has worked in I think 3.x and 4.x