[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,0x04,0x08,0x00,0x54,0x41,0x42,0x05,0x00,0x24,0x08,0x00,0x25,0x09,0x92,
 0x04,0x10,0xa0,0x40,0x00,0x04,0x09,0x12,0x04,0x50,0x44,0x88,0x00,0x05,0x11,
 0xfe,0x04,0x10,0x40,0x41,0x02,0xe4,0x17,0x12,0x00,0xf0,0x43,0xfe,0x09,0x25,
 0x13,0x20,0x02,0xfc,0x5f,0x85,0x00,0xa8,0x0f,0xfe,0x04,0xb2,0x96,0x10,0x00,
 0xe8,0x23,0x44,0x05,0xc2,0x81,0xfe,0x00,0x90,0x28,0x00,0x04,0x44,0x82,0xaa,
 0x00,0x01,0x20,0xfe,0x04,0x54,0x85,0x00,0x01,0x00,0x20,0x48,0x00,0x92,0x84,
 0xfe,0x0a,0x20,0x28,0x84,0x00,0x8a,0x82,0x10,0x02,0x00,0x20,0x84,0x00,0x52,
 0x92,0x10,0x0a,0x04,0x04,0x8a,0x00};