>>8
instead let the caller allocate it first and pass you the pointer to initialize it,
Sometimes that's fine, but other times I think this complicates things, let's say you're calling a complex function that reads some user input of unspecified size and generates a large complex nested, maybe even cyclic structure from it. Are you going to query that function for all the needed sizes and how to build the object? I think it's easier, faster and safer to have the function allocate the object for you, and give you a free/destroy function which you can use to deallocate the object and all its children, without needed knowledge about the internals of the object and thus preserving encapsulation. Most high-level languages work like this. While it may be true that such languages tend to have garbage collectors, nothing prevents you from calling the destroy function manually once you no longer need the object. If non-local transfer of control happens, things do get a lot more hairy, but not by too much (try{}finally{},
UNWIND-PROTECT,
dynamic-wind or similar should be used for cleanup).