[GH-ISSUE #180] Question: data validation (memory handling) #145

New issue

Closed

opened 2026-05-05 11:47:08 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 11:47:08 -06:00

Owner

Originally created by @petricf on GitHub (May 18, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/180

Originally assigned to: @jmcnamara on GitHub.

worksheet_data_validation_cell and worksheet_data_validation_range seem to require the callee to allocate dynamic memory for lxw_data_validation before calling them.

Question 1: Can this structure also placed on stack ?
Question 2: If not - do this functions take over the ownership of this memory and frees it later on ?
Question 3: What happens if you use the same allocated structure at multiple calls (double free at end) ?

Reasoning: For me it is a good behaviour that the memory is allocated at the same area as it is freed. Here: inside xlsxwriter.

I am not sure but i've seen the allocation request for the callee on this two functions only.

Question 4: Is it possible to change the code xlsxwriter in a way to avoid the memory allocation for the callee. For example pass a stack allocated structure and do the allocation inside the called functions. This would avoid the hazard of double free when cleaning up.

Originally created by @petricf on GitHub (May 18, 2018). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/180 Originally assigned to: @jmcnamara on GitHub. worksheet_data_validation_cell and worksheet_data_validation_range seem to require the callee to allocate dynamic memory for lxw_data_validation before calling them. Question 1: Can this structure also placed on stack ? Question 2: If not - do this functions take over the ownership of this memory and frees it later on ? Question 3: What happens if you use the same allocated structure at multiple calls (double free at end) ? Reasoning: For me it is a good behaviour that the memory is allocated at the same area as it is freed. Here: inside xlsxwriter. I am not sure but i've seen the allocation request for the callee on this two functions only. Question 4: Is it possible to change the code xlsxwriter in a way to avoid the memory allocation for the callee. For example pass a stack allocated structure and do the allocation inside the called functions. This would avoid the hazard of double free when cleaning up.

gitea-mirror

2026-05-05 11:47:08 -06:00

closed this issue
added the
question
label

gitea-mirror commented

2026-05-05 11:47:14 -06:00

Author

Owner

@jmcnamara commented on GitHub (May 19, 2018):

Question 1: Can this structure also placed on stack ?

Yes. In fact this is called out in the docs:

Note, in the examples in this document the data_validation variable is shown as dynamically allocated, however an address of a static or automatic variable could also be used. In these cases make sure that the struct members are initialized to zero before setting other parameters.

The part about initialization is important.

Question 2: If not - do this functions take over the ownership of this memory and frees it later on ?

All pointers passed to the APIs are copied internally. The user's copy is untouched. And as usual the user should take care of memory that they allocate.

Question 3: What happens if you use the same allocated structure at multiple calls (double free at end)

See Q2. There is no double free. The example in the docs uses this approach.

Question 4: Is it possible to change the code xlsxwriter in a way to avoid the memory allocation for the callee.

I would be possible. For example the workbook_add*() functions do that now. However, generalizing this out for for every struct used in the APIs would be a lot of work for (what I currently see as) not a lot of benefit when the user can easily create a static or dynamic struct themselves.

One caveat to this is that bugs with uninitialised structs seems to happen more than I like. This is further complicated by the fact that some API structs have undocumented or hidden fields.

One the other hand most people seem to be managing to work with it, for now.

@jmcnamara commented on GitHub (May 19, 2018): > Question 1: Can this structure also placed on stack ? Yes. In fact this is called out in the [docs](http://libxlsxwriter.github.io/working_with_data_validation.html#ww_data_validate_struct): > Note, in the examples in this document the data_validation variable is shown as dynamically allocated, however an address of a static or automatic variable could also be used. In these cases make sure that the struct members are initialized to zero before setting other parameters. The part about initialization is important. > Question 2: If not - do this functions take over the ownership of this memory and frees it later on ? All pointers passed to the APIs are copied internally. The user's copy is untouched. And as usual the user should take care of memory that they allocate. > Question 3: What happens if you use the same allocated structure at multiple calls (double free at end) See Q2. There is no double free. The [example in the docs](http://libxlsxwriter.github.io/data_validate_8c-example.html) uses this approach. > Question 4: Is it possible to change the code xlsxwriter in a way to avoid the memory allocation for the callee. I would be possible. For example the `workbook_add*()` functions do that now. However, generalizing this out for for every struct used in the APIs would be a lot of work for (what I currently see as) not a lot of benefit when the user can easily create a static or dynamic struct themselves. One caveat to this is that bugs with uninitialised structs seems to happen more than I like. This is further complicated by the fact that some API structs have undocumented or hidden fields. One the other hand most people seem to be managing to work with it, for now.