On Wed, 24 Aug 2016, Adam C. Emerson wrote: > On 24/08/2016, Matt Benjamin wrote: > > Mark Nelson called attention to this topic again yesterday in #ceph-devel. > > > > We favor retaining the ability to re-declare specific asserts such that they are, as with assert in general historically, compiled out. I think it's reasonable if this is a marked case. > > > > That seems to imply that if ceph_assert is the unmarked case, it won't be compiled out, so is essentially ceph_assert_always, as below (or else that form should be used...it's a little long). > > If we want to go for brevity, we could have ceph_assert() be the > unmarked case that functions just like assert macro. > > Then we could use something like ceph_demand() (ceph_ultimatum? > ceph_blackmail?) to indicate the case that isn't compiled out. > > Personally, I would just like to get rid of Ceph's assert.h and its > unending war with every other header file in the world. At one point > killed off the header and linked in an object that overrode > __assert_fail. This worked very well, though it would require handling > every C library implementation we're compiled against. This is appealing, except: > > Note that using the system assert isn't a total disaster: system > > assert will trigger an abort, which will trigger the SIGABRT handler > > which *also* dumps a stack trace to the debug log. The problem is > > that it doesn't show the assertion condition and line number. I think not getting the assertion condition and line number in the ceph log is a deal breaker. I would go for ceph_abort (abort with message in log etc), ceph_assert (may get compiled out in the future), and ceph_demand (never compiled out). sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
