On Sun, May 27, 2018 at 3:19 AM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> Hi Richard,
>
> On Wed, May 09, 2018 at 04:51:13PM -0700, Richard Sharpe wrote:
>> Hi folks,
>>
>> I have an application where I want to change the specification of an
>> HF entry or two, and found proto_deregister_field.
>>
>> It would seem that I can deregister a field and then register a new
>> version of it ... as long as I am careful.
>>
>> What is the cost of doing this?
>>
>> Is an alternative to register a fixed array but modify the entries?
>
> What was the use case for this dynamic field update? What property were
> you interested in?
>
> I am not sure how well dynamic field (de)registration is supposed to
> work. It is causing some memory leaks and I am worried that trying to
> solve those can result in other memory safety issues (use-after-free).
This is in relation to the radiotap headers for HE and HE-MU (and more).
The issue is that there are fields in those headers that are unknown
unless the appropriate known bit is set to true elsewhere in the
header.
The approach I took initially was to have two header types:
1. One for when the field was known, and
2. One for when the field was unknown where the search string had unknown in it
I would then use the appropriate HF in the code.
However, people have complained that this is weird.
My thinking was:
1. I don't like it when fields are not dissected, and
2. By using a different search string when a field is unknown we would
not get false positives (usually the field is 0, but 0 is usually also
a valid value wen the field is known.)
An alternative is to change the label associated with the field to
include the word unknown, but I don't think you can have two HF fields
with the same search string in them, so I wanted to explore
dynamically changing hf structures.
However, doing that now reintroduces the problem that searching on a
field with the value 0 can result in false positives.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
