Mojo C bindings library pt1: MojomBuffer

mojo/public/c/bindings/lib/buffer.c

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "mojo/public/c/bindings/buffer.h"
+
+#include <assert.h>
+#include <stddef.h>  // for NULL
+
+void* MojomBuffer_Allocate(struct MojomBuffer* buf, size_t num_bytes) {
+  assert(buf);
+
+  static const size_t kAlignment = 8;
+  const size_t bytes_used = buf->num_bytes_used;
+  // size = num_bytes aligned to 8 bytes:
+  const size_t size = (num_bytes + (kAlignment-1)) & ~(kAlignment-1);

[viettrungluu, 2016/06/15 15:00:58]

Note that this will lead to sadness if num_bytes is very large (so that
num_bytes + (kAlignment-1) overflows).

[vardhan, 2016/06/15 15:48:00]

oof.  i think its better to make it a uint32_t rather than a size_t (makes the
limit more clear, and is also more accurate).

+  if (bytes_used + size > buf->buf_size || bytes_used + size <= bytes_used)

[viettrungluu, 2016/06/15 15:00:57]

nit: <= -> <. There's no reason to not allow "allocations" of 0 bytes to
succeed.

[vardhan, 2016/06/15 15:48:00]

Allocations of 0 seem like a programmatic error -- if i return a non-null
pointer, the user shouldn't use it, so whats the point?  we also don't have a
free(), so there's nothing they could do with it, so I was thinking lets just
not allow it?

[viettrungluu, 2016/06/15 15:59:49]

It's not necessarily a programmatic error for cases when num_bytes is computed;
it can often simplify logic.

For comparison, it's often convenient to memcpy() or memset() 0 bytes. (It's
extremely inconvenient that the standard doesn't actually allow the pointers to
be null in those cases, though that's nearly never stopped anyone from doing
it.)

[vardhan, 2016/06/15 16:10:21]

Done.

+    return NULL;
+
+  buf->num_bytes_used += size;
+  return buf->buf + bytes_used;
+}