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 -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
