[BRLTTY] Low-level BrlAPI questions

[Samuel Thibault]

Aura Kelloniemi, le mar. 11 mai 2021 18:35:53 +0300, a ecrit:
> On 2021-05-11 at 09:52 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> 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