[CDRIVER-3526] Proposal for bson_init_static_from_buffer Created: 07/Feb/20 Updated: 05/Feb/24 |
|
| Status: | Backlog |
| Project: | C Driver |
| Component/s: | libbson |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Trivial - P5 |
| Reporter: | Mark Tarrabain | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | bg-rf, neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Improve Developer Experience |
| Backwards Compatibility: | Fully Compatible |
| Description |
|
I would suggest adding a new API function, bson_init_static_from_buffer which is similar in most ways to bson_new_from_buffer, and in others to bson_init_static, but differs from the latter in that the buffer supplied is not read-only, and from the former in that it does not actually allocate the bson, but instead takes a pointer to one as an extra initial parameter and returns with the bson initialized so that appending to it will utilize the realloc function supplied with the allocation context as a parameter. To that end, the prototype would probably look something like this:
Behaviour for this function would be virtually identical to that of bson_new_from_buffer except that it does not allocate the bson_t, and it sets up the bson so that calling bson_destroy does not attempt to free it, nor does it try to free the buffer it points to. It would, however, if `realloc_func` was not null, call the reallocation function with the current buffer and a size of 0, which bears the responsibility of freeing the memory used. The most obvious use case for such a function would be to allow each bson to have its own memory allocator (presumably accessed via the realloc_func_ctx pointer) without imposing the requirement that all bsons obtain their memory from a single pool, as bson_set_mem_vtable does currently. |
| Comments |
| Comment by Mark Tarrabain [ 03/Jun/21 ] |
|
It has since occurred to me that using the term 'static' in the name might be misleading... perhaps bson_init_from_buffer would be adequate. Paralleling bson_init in naming convention while using most of the same parameters as bson_new_from_buffer, and at the same time not implying that the buffer is supposed to be static and unchanging. |
| Comment by April Schoffer [ 10/Feb/20 ] |
|
We'll aim to put this in 1.17 pending scheduling of other priorities. |
| Comment by Jeremy Mikola [ 07/Feb/20 ] |
|
markt1964@gmail.com: No worries, as "major" is the default selection. We can always adjust during the next triage meeting. |
| Comment by Mark Tarrabain [ 07/Feb/20 ] |
|
I did not intend for the "priority" for this request to be listed as "Major". I apologize profusely for the misunderstanding, and I can respect that this issue would be de-escalated appropriately. |