[apparmor] [patch] more gcc 5 errors
John Johansen
john.johansen at canonical.com
Tue Feb 17 23:31:13 UTC 2015
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
More information about the AppArmor
mailing list