Re: daily: vim problem again

[Paul Dufresne]

This looks like one of these moments I think I am brighter than I am... but 
here my reasoning of the problem so far:

I am using https://github.com/bminor/glibc/blob/master/malloc/malloc.c

In it we see:

 > chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  |             Size of previous chunk, if unallocated (P clear)  |
 >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  `head:' |             Size of chunk, in bytes                     |A|0|P|
 >  mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  |             Forward pointer to next chunk in list             |
 >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  |             Back pointer to previous chunk in list            |
 >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  |             Unused space (may be 0 bytes long)                .
 >  .                                                               .
 >  .                                                               |
 > nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  `foot:' |             Size of chunk, in bytes                           |
 >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  |             Size of next chunk, in bytes                |A|0|0|
 >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >  The P (PREV_INUSE) bit, stored in the unused low-order bit of the
 >  chunk size (which is always a multiple of two words), is an in-use
 >  bit for the *previous* chunk.  If that bit is *clear*, then the
 >  word before the current chunk size contains the previous chunk
 >  size, and can be used to find the front of the previous chunk.
 >  The very first chunk allocated always has this bit set,
 >  preventing access to non-existent (or non-owned) memory. If
 >  prev_inuse is set for any given chunk, then you CANNOT determine
 >  the size of the previous chunk, and might even get a memory
 >  addressing fault when trying to do so.
 >  The A (NON_MAIN_ARENA) bit is cleared for chunks on the initial,
 >  main arena, described by the main_arena variable.  When additional
 >  threads are spawned, each thread receives its own arena (up to a
 >  configurable limit, after which arenas are reused for multiple
 >  threads), and the chunks in these arenas have the A bit set.  To
 >  find the arena for a chunk on such a non-main arena, heap_for_ptr
 >  performs a bit mask operation and indirection through the ar_ptr
 >  member of the per-heap header heap_info (see arena.c).
 > 


So Size of chunk, have the 3 lower bits with flags... so to get the size you 
would shift the value 3 bits to the right, righ?

But the definition given is:

#define PREV_INUSE 0x1
#define IS_MMAPPED 0x2
#define NON_MAIN_ARENA 0x4

/*
   Bits to mask off when extracting size
   Note: IS_MMAPPED is intentionally not masked off from size field in
   macros for which mmapped chunks should never be seen. This should
   cause helpful core dumps to occur if it is tried by accident by
   people extending or adapting this malloc.
 */
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)

/* Get size, ignoring use bits */
#define chunksize(p) (chunksize_nomask (p) & ~(SIZE_BITS))

/* Like chunksize, but do not mask SIZE_BITS.  */
#define chunksize_nomask(p)         ((p)->mchunk_size)


Am I so wrong?