On 02/17/2015 12:07 PM, Seth Arnold 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 <[email protected]> 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. What >> of all the other places we have a similar pattern? Why are they passing > > Acked-by: Seth Arnold <[email protected]> > for both trnuk and 2.9. > > I don't think I've seen many functions take or return 'ostream' as a > parameter; perhaps the Better Solution is to make an af_rule::operator<<() > method instead, so it'll feel more C++-ey. > > But I think that can wait. > Actually we already do, do that
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); the problem is that, << only gets you 1 output and we have different output cases. Also because how C++ is setup using operator<< is actually an external fn, that is match off of the fn template so often we just make it a wrapper around one of the dump or output methods -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
