summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2014-07-13 02:41:55 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-07-28 10:14:33 -0700
commitfe24d396e1b8d2eedbc07f626af3dcd2b14e6012 (patch)
tree91fb1e84826e61b7f5932abc54b1146e337f4b19 /.mailmap
parentalloc: write out allocator definitions (diff)
downloadtgif-fe24d396e1b8d2eedbc07f626af3dcd2b14e6012.tar.xz
move setting of object->type to alloc_* functions
The "struct object" type implements basic object polymorphism. Individual instances are allocated as concrete types (or as a union type that can store any object), and a "struct object *" can be cast into its real type after examining its "type" enum. This means it is dangerous to have a type field that does not match the allocation (e.g., setting the type field of a "struct blob" to "OBJ_COMMIT" would mean that a reader might read past the allocated memory). In most of the current code this is not a problem; the first thing we do after allocating an object is usually to set its type field by passing it to create_object. However, the virtual commits we create in merge-recursive.c do not ever get their type set. This does not seem to have caused problems in practice, though (presumably because we always pass around a "struct commit" pointer and never even look at the type). We can fix this oversight and also make it harder for future code to get it wrong by setting the type directly in the object allocation functions. This will also make it easier to fix problems with commit index allocation, as we know that any object allocated by alloc_commit_node will meet the invariant that an object with an OBJ_COMMIT type field will have a unique index number. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions