[xemacs-hg @ 2005-10-25 08:32:40 by ben] more mc-alloc-related factoring; make it hard to do the wrong thing postgresql/postgresql.c, postgresql/postgresql.h: MC-Alloc refactoring. ldap/eldap.c, ldap/eldap.h: MC-Alloc refactoring. alloc.c, buffer.c, console.c, emacs.c, file-coding.c, lrecord.h, lstream.c, mule-charset.c, print.c, scrollbar-gtk.c, scrollbar-msw.c, scrollbar-x.c, scrollbar.c, symbols.c, symeval.h, unicode.c, window.c, xemacs.def.in.in: rename `struct lcrecord_header' to `struct old_lcrecord_header'; likewise for `old_basic_alloc_lcrecord', `old_free_lcrecord', `old_zero_lcrecord', `old_zero_sized_lcrecord', `old_copy_lcrecord', `old_copy_sized_lcrecord', `old_alloc_lcrecord_type'. Created new LISPOBJ_STORAGE_SIZE() used only on objects created through allocation of Lisp-Object memory instead of basic xmalloc()/xfree(). This is distinguished from malloced_storage_size(), for non-Lisp-Objects. The definition of LISPOBJ_STORAGE_SIZE() can reduce down to malloced_storage_size() when not MC-ALLOC, but with MC-ALLOC it's a different function. The whole point other than cleaning up the use of LISPOBJ_STORAGE_SIZE is to make it harder to accidentally use the old kind (lowercase) of function in new code, since you get a compile error.

#define noname_width 28
#define noname_height 28
static char noname_bits[] = {
 0x00,0x10,0x00,0x00,0xaa,0x84,0x52,0x05,0x00,0x22,0x08,0x00,0x92,0x08,0x82,
 0x04,0x40,0xa0,0x28,0x00,0x14,0x0a,0x02,0x05,0xc0,0x20,0x18,0x00,0x8a,0x89,
 0x92,0x04,0x20,0x03,0x4c,0x00,0x09,0x56,0x16,0x05,0x20,0x0c,0x03,0x00,0x0a,
 0x91,0xa1,0x04,0x20,0xf4,0x08,0x02,0x09,0x41,0x82,0x00,0x20,0x74,0x28,0x02,
 0x0a,0x99,0x83,0x00,0x20,0x0c,0x09,0x0a,0x89,0x46,0xa6,0x00,0x20,0x03,0x0c,
 0x02,0x8a,0x51,0x99,0x00,0xa0,0x00,0x10,0x0a,0x08,0x94,0x84,0x00,0x42,0x40,
 0x10,0x02,0x10,0x12,0x85,0x00,0x42,0x08,0x10,0x0a,0x10,0x82,0xa4,0x00,0x42,
 0x28,0x02,0x02,0x90,0x82,0x90,0x00};