Pekka Enberg wrote: >>--- /dev/null 2003-09-23 21:59:22.000000000 +0400 >>+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642 +0400 >>+/* initialise new pool */ >>+reiser4_internal void >>+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ , >>+ size_t obj_size /* size of objects in @pool */ , >>+ int num_of_objs /* number of preallocated objects */ , >>+ char *data /* area for preallocated objects */ ) >>+{ >>+ reiser4_pool_header *h; >>+ int i; >>+ >>+ assert("nikita-955", pool != NULL); > > These assertion codes are meaningless to the rest of us so please drop > them.
As someone who spends time debugging reiser3 issues, I've grown accustomed to the named assertions. They make discussing a particular assertion much more natural in conversation than file:line. It also makes difficult to reproduce assertions more trackable over time. The assertion number never changes, but the line number can with even the most trivial of patches. That said, one of my gripes with the named assertions in reiser3 (and reiser4 now) is that the development staff changes over time. There are many named assertions in reiser3 that refer to developers no longer employed by Hans. The quoted one is a perfect example. Hans, would it be acceptable to you to keep only numbered assertions and keep a code responsbility list internal to namesys? It would serve a dual purpose of keeping the idea of named assertions, but also remove a huge number of strings that bloat the implementation. -Jeff -- Jeff Mahoney SuSE Labs