bug#53136: 28.0.90; segfault in lock_file

[Paul Eggert]

On 1/11/22 05:16, Po Lu wrote:

>  > Fixing each place individually is a time bomb: no one will remember
>  > that after enough time has passed, and we will add bugs.
>
>  > The only alternative is to filter errno via some macro, which will do
>  > nothing on all platforms but Haiku, where it will map them to Posix
>  > values. Butt-ugly, but it's not our fault.
>
> Hmm, perhaps gnulib can do something in this area? Paul, any ideas?
> Thanks in advance.

Here are three possibilities:

1. Carefully audit the many hundreds of use of errno values in Emacs and 
make sure they still work even on Haiku, updating Gnulib accordingly. I 
think we agree this is a big and continuing maintenance hassle. I just 
did a bit more of this sort of thing in filelock.c (please see attached) 
and would rather not do more.


2. Change Gnulib so that on Haiku Gnulib wraps errno-producing functions 
called by Emacs (and by Gnulib), so that they negate errno before 
returning. Gnulib would also wrap errno.h so that errno constants are 
positive. This would affect only calls from Emacs code; it wouldn't 
affect calls from Haiku libraries, so file dialogs would continue to work.

Unfortunately this would be a maintenance hassle too. I suppose we could 
adjust Gnulib to wrap only the errno-producing functions that Emacs 
cares about, either directly or indirectly via Gnulib. However, I expect 
there are some such functions not in the standard library, and I doubt 
whether we'd want to change Gnulib to wrap random functions in random 
libraries. For these functions, we'd need to modify Emacs much as we 
already modified filelock.c.


3. Compile Emacs code with B_USE_POSITIVE_POSIX_ERRORS, and use linker 
magic only on this code; do not use linker magic on library code (e.g., 
-ltracker) so that Haiku library code uses the original functions. That 
way, Emacs source code proper would need to worry about negative errno 
values only in haiku*.c files that call Haiku-specific libraries. If 
this is feasible, it should be much less work and more maintainable. 
Could you look into that?

0001-Clean-up-filelock-code-related-to-errno.patch
Description: Text Data