boringssl/include
David Benjamin 93a034a7d7 CBBs are in an undefined state after an operation failed.
Our CBB patterns do not make it safe to use a CBB after any operation
failed. Suppose one does:

  int add_to_cbb(CBB *cbb) {
    CBB child;
    return CBB_add_u8(cbb, 1) &&
           CBB_add_u8_length_prefixed(cbb, &child) &&
           CBB_add_u8(&child, 2) &&
           /* Flush |cbb| before |child| goes out of scoped. */
           CBB_flush(cbb);
  }

If one of the earlier operations fails, any attempt to use |cbb| (except
CBB_cleanup) would hit a memory error. Doing this would be a bug anyway,
since the CBB would be in an undefined state anyway (wrote only half my
object), but the memory error is bad manners.

Officially document that using a CBB after failure is illegal and, to
avoid the memory error, set a poison bit on the cbb_buffer_st to prevent
all future operations. In theory we could make failure +
CBB_discard_child work, but this is not very useful and would require a
more complex CBB pattern.

Change-Id: I4303ee1c326785849ce12b5f7aa8bbde6b95d2ec
Reviewed-on: https://boringssl-review.googlesource.com/8840
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-07-19 20:51:51 +00:00
..
openssl CBBs are in an undefined state after an operation failed. 2016-07-19 20:51:51 +00:00