On Tue, Feb 17, 2015 at 03:31:13PM -0800, John Johansen wrote: > 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
Well, not really: $ ./apparmor_parser -d -Q tst/simple_tests/unix/ok_shutdown_3.sd ----- Debugging built structures ----- Name: a_profile Profile Mode: Enforce 0x6f8508unix ()addr='@HypotheticalServiceDaemon'0x6f8508, (trunk built with gcc-4.9, same result with gcc-4.6 on ubuntu 12.04.) Anyway, I'm going to go ahead and commit the patch I submitted. -- Steve Beattie <sbeat...@ubuntu.com> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor