On Sat, May 28, 2011 at 11:42:37PM +0100, Julio Merino wrote: > On 5/28/11 10:46 PM, Christos Zoulas wrote: > >In article<20110528161256.ab89817...@cvs.netbsd.org>, > >Matthias Scheler<source-changes-d@NetBSD.org> wrote: > >[...] > >>+ assert(close(fd) == 0); > > > >Please don't create assertions that contain code, because compiled with > >-DNDEBUG they vanish. > > Are these test code? If so, just replace assert by one of: > > - ATF_REQUIRE(boolean_expression) > - ATF_REQUIRE_EQ(expected_value, actual_value) > > like: > > ATF_REQUIRE(pipe(fds) != 0); > ATF_REQUIRE_EQ(1, write(fds[1], "", 1));
Actually, the assert() define (and similar) are often less than useful since they don't give any indication of why things are wrong. The ATF_REQUIRE_EQ() might be more useful (I've not looked at its definition), but it ought to be possible to use something like: #define CHECK(type, fmt, v1, op, v2) \ do { \ type _v1 = (v1), _v2 = (v2); \ if (!((_v1) op (_v2))) \ check_error(#v1, #op, #v2, __LINE__, fmt, _v1, _v2); \ } while (0); #define CHECK_I(v1, op, v1) CHECK(int, "%d", v1, op, v2) So check_error() can print the both values of the erronous test. David -- David Laight: da...@l8s.co.uk