Aura Kelloniemi, le mar. 11 mai 2021 18:35:53 +0300, a ecrit: > On 2021-05-11 at 09:52 +0200, Samuel Thibault <[email protected]> > wrote: > > Aura Kelloniemi, le mar. 11 mai 2021 09:49:04 +0300, a ecrit: > > > And what about a field (at the end of the struct) that tells the maximum > size > > > of the parameter value array (in bytes or elements)? Or is there already > a way > > > to know how much space to allocate for a parameter value? > > > The current count field is to provide this information. > > > For variable values, brlapi_getParameter returns the actually needed > > size, so you can re-allocate a bigger buffer. Or to avoid a round-trip > > you can use getParameterAlloc which immediately allocates the proper > > size. > > getParameterAlloc knows the maximum possible size of a parameter
No it doesn't, it receives the message in a max-message-size buffer, then allocates a buffer of the right size and copies the data into it. > – it does not > need to do any round-tripping. Is there a reason why this information couldn't > be available somewhere – a global constant (BRLAPI_PARAM_VALUE_MAX_SIZE) or > preferably per-parameter in its properties. That would make it hardcoded once for good, and it'd be a very large value (BRLAPI_MAXPACKETSIZE is 4096). Is it really what we want? > If you are to add a flag which tells that an array has a variable size, > couldn't the current .count field tell the maximum possible size? > Or can the value be arbitrarily big (in which case unnecessary > allocation should be avoided)? There are cases such as keycodes where it can be arbitrarily big. There is the protocol-specific maximum size mentioned above, but we want to be able to bump that if ever needed, without breaking everything. > And then I'll ask about the case where .siArray == false: > > Shouldn't this too be very simple? The parameter will hold just one value – > i.e. one int, one bool, one char, nothing that is variable-length. Do you > disagree? That is what is currently implemented, and that I proposed to keep as such, possibly enhanced with a helper that tells for each type how many bytes it is. Samuel _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
