On 02/17/2015 12:33 PM, Steve Beattie 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. > > I agree about thrashing around in the dark and I don't really like > dropping the return value on the floor, either. > >> What of all the other places we have a similar pattern? Why are >> they passing > > Well, we don't actually have other places that invoke a method that > returns an ostream reference (unless I overlooked something). In a > simple grep, it looked like every time we called a method in a << > pipeline, what was returned was a data item to be output directly. > I may have missed a variable of type ostream& (a la the 'os' variable > that the commit Seth made addressed), but nothing jumped out at me. > 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); -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
