[BRLTTY] Low-level BrlAPI questions

Aura Kelloniemi kaura.dev at sange.fi
Thu Apr 15 00:58:23 EDT 2021


On 2021-04-15 at 02:43 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Aura Kelloniemi, le mer. 14 avril 2021 22:13:45 +0300, a ecrit:
 > > On 2021-04-14 at 14:27 -0400, Dave Mielke <Dave at mielke.cc> wrote:
 > “
 > regionBegin = regionSize = 0; (update the whole display, DEPRECATED and will
 > be forbidden in next release. You must always express the region you wish to
 > update)
 > ”

 > We warned about forbidding that because we don't really want the
 > andMask/orMask to be only *implicitly* of size cell count. Think what
 > would happen if the display happens to get resized in the middle of all
 > of this.

Very bad things, if the masks are provided, but nothing, if they are not. I
would recommend disallowing the use of masks, if regionSize is zero.

 > But we do not want to pad by default, since existing applications may
 > have been using it to perform partial updates.

To me it seems like if the number of code points in text does not match
regionSize, and exception is triggered and nothing is written, so no
application can benefit of passing too short text values. Supplying too short
mask values will cause invalid memory access.

 > - add a flag field to brlapi_writeArguments_t, which requires bumping
 >   the soname ABI compatibility *and* protocol version.

Another option would be to introduce size values for the masks, in addition to
the regionSize. This would be most scalable.

Also, this does not need to break the protocol, because padding can be applied
in the C client library. And when the padding is applied at the packet
creation time, one extra allocation can be avoided.

 > I believe it'd better be at an intermediate layer, to keep the BrlAPI
 > protocol as simple as possible.

Yes, sure. Maybe I should have been clearer in expressing, that what I want
can be done in the client.

-- 
Aura


More information about the BRLTTY mailing list