Hi again, On 2021-04-12 at 19:31 +0200, Samuel Thibault <[email protected]> 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 _______________________________________________ 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
