Re: [PATCH] Ensure __BYTE_ORDER is always set

> I think we could do this with something like the patch below, which
> checks two things:
>
>   1. When we expand the ewah, it has the same number of bits we claimed
>      in the on-disk header.
>
>   2. The ewah header matches the number of objects in the packfile.
>
> The first catches a corruption in the ewah data itself, and the latter
> when the header is corrupted. You can test either by breaking the
> endian-swapping. :)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index ae0b57b..a31e529 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -130,6 +131,31 @@ static struct ewah_bitmap *read_bitmap_1(struct bitmap_index *index)
>                 return NULL;
>         }
>
> +       /*
> +        * It's OK for us to have too fewer bits than objects, as the EWAH

> +        * writer may have simply left off an ending that is all-zeroes.
> +        *
> +        * However it's not OK for us to have too many bits, as that would
> +        * entail touching objects that we don't have. We are careful
> +        * enough to avoid doing so in later code, but in the case of
> +        * nonsensical values, we would want to avoid even allocating
> +        * memory to hold the expanded bitmap.
> +        *
> +        * There is one exception: we may "go over" to round up to the next
> +        * 64-bit ewah word, since the storage comes in chunks of that size.
> +        */
> +       expected_bits = index->pack->num_objects;
> +       if (expected_bits & 63) {
> +               expected_bits &= ~63;
> +               expected_bits += 64;
> +       }
> +       if (b->bit_size > expected_bits) {
> +               error("unexpected number of bits in bitmap: %"PRIuMAX" > %"PRIuMAX,
> +                     (uintmax_t)b->bit_size, (uintmax_t)expected_bits);
> +               ewah_pool_free(b);
> +               return NULL;
> +       }
> +
>         index->map_pos += bitmap_size;
>         return b;
>  }
> --