[BRLTTY] Low-level BrlAPI questions

[Aura Kelloniemi]

Hi again,

On 2021-04-12 at 19:31 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Yes, but strerror_r is available in posix 2001, and gai_strerror is not
 > said to be non-threadsafe, so I guess it means it has to be.  I guess we
 > can thus safely assume that we can build a brlapi_strerror_r from that
 > that is threadsafe on all current systems.

Great! I'll be using it once it lands.

Another thing:

The BrlAPI server is pretty strict about the lengths of various values passed
to it for a write operation. E.g. it "throws" an internal exception, if the
text to be written does not exactly match the size of the written region.

Even though I appreciate correctness in every possible situation a lot, I
would like to dispute the usefulness of this checking:

Because it is non-trivial to find out the length of a text string, its length
will be calculated in many places – in brlapi__writeText, in the server, maybe
somewhere else before rendering to dots. At least the BrlAPI's calculation
could be dropped, if the server accepted texts of any length, and in case the
text is too long the server would truncate it, and if it is too short, the
text would be padded with empty cells (which may be a different thing from the
space character, depending on the user's braille table).

This could be applied to the masks as well. andMask could be padded with the
value 255 (not to interfere with anything else that gets written) and orMask
could be padded with zeros.

But why? Counting the length in BrlAPI client of course is not so
time-consuming. But as I am writing a binding, which does not directly create
the BrlAPI packets, but rather calls the brlapi__write function (which makes a
copy of all input values), I need to do an extra copy all user-supplied arrays
to pad them. I definitely want to support padding/truncation, so that the
caller does not need to worry about passing too short input, as most likely
what they want is that the rest of the display (or display region) will remain
empty.

Doing an extra allocation, copy and deallocation just to add some padding
feels like waste of resources. I could of course create the write packet my
self, and this way the extra copy done by brlapi__write would be elided, but I
think that using brlapi__write is a much better solution to guarantee
forward-compatibility.

On the other hand, dropping this checking in the server (and adding
padding/truncation there) would not negatively affect the client programmer.
Of course it means that some minor rendering issues could be detected a bit
later, but as most programmer already use BrlAPI functions which support
padding/truncation, there is no loss of safety here.

So I'm asking, could the restrictions on text and mask lengths be lifted?

-- 
Aura