Skip to content
  • pwendler's avatar
    Revert r23909 (0ce7a4dc): fix pointer arithmetic in predicate analysis but break bit fields · 53d381fb
    pwendler authored
    That commit added support for bit fields in structs
    by converting all pointer addresses to bits.
    Instead of a byte-adressable heap we now had a bit-adressable heap,
    and all pointer adresses were multiplied by 8.
    That commit forgot (at least) one case where it was necessary to switch
    from bytes to bits:
    would need to use `getBitSizeof()` instead of `getSizeof()`.
    This breaks pointer arithmetic such as `p + 1` and was reported as #422.
    However, if we fix this now, we see another problem:
    `(char*)p - 1)` gives a different result than `(size_t)p - 1`,
    because in the former the value of `p` is decremented by 8 (bits),
    whereas in the latter the value of `p` is decremented by 1.
    C code that assumes that these two expressions produce the same value
    is treated incorrectly, which can be seen
    (after changing getPointerTargetSizeLiteral)
    for example in ldv-sets/test_mutex_true-unreach-call.i.
    Yet another problem is that the size of pointers in formulas
    was not increased, but of course pointers for a bit-adressable heap
    are 3 bits longer than pointers for a byte-addressable heap.
    This means that pointer values overflow too early currently
    (though of course pointer overflow is undefined behavior).
    Especially because of the resulting difference between pointer
    arithmetic and int arithmetic, I see no chance of really fixing all
    issues with the bit-adressable heap,
    and thus this reverts r23909 and restores a byte-addressable heap.
    This fixes #422 but breaks support for bit fields,
    at least for those bit fields that are on the heap or which the
    predicate analysis treats as if they were on the heap
    (e.g., if there is aliasing of the struct).
    I hope that I found all locations that r23909 changed
    and all locations where code that assumes a bit-addressible heap
    was added in the meantime.
    I checked all callers of `TypeHandlerWithPointerAliasing.getBitSizeof()`
    and `.getBitOffset()`.
    In all these cases bit fields should now be safely ignored and reads
    would be assumed to be non-deterministic, so this should only be
    imprecise and not unsound (which the current solution is).
    git-svn-id: 4712c6d2-40bb-43ae-aa4b-fec3f1bdfe4c