Appreciation; signal handling issues; typo in linux/unix flags translation?

[OnesuchDev]

I assume you meant "unixflags & 8" here? https://github.com/taviso/123elf/blob/f851cb239a6242f9b5a8497dbe8209d2069f037b/wrappers.c#L166

I think this project is hilarious and an incredible technical achievement. I wonder whether the wrappers from it could help put Xinuos out of business people stuck using SCO OpenServer/UnixWare transition to Linux if they have lost source code to their applications. This might actually be even easier for newer software that uses ELF, since you could use wrappers around glibc (and/or potentially code from illumos) to generate a libc.so replacement that would translate structures/constants/etc.

[OnesuchDev]

Also, your signal wrapper should use sysv_signal. https://linux.die.net/man/3/sysv_signal For BSDs (where I don't think it exists) you could take it from glibc: https://elixir.bootlin.com/glibc/glibc-2.29/source/sysdeps/posix/sysv_signal.c

In some places it's stated that Linux uses sysv signal semantics but (depending on #defines) this is only true for the syscall itself and not the glibc wrapper around it. https://man7.org/linux/man-pages/man2/signal.2.html

There is a bunch of weirdness related to SIGCHLD on Linux vs BSD but for the sake of your own sanity I wouldn't think about it unless it actually comes up in the BSD port. https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062276.html https://lkml.iu.edu/hypermail/linux/kernel/9606.2/0080.html

[taviso]

Oops - yes, that looks like a bug - thanks! Huh, I wonder what needed that flag that hasn't been working properly... that must have been before I started adding tests to check for breakage.. oops :)

I wasn't familiar with sysv_signal() - I agree it makes sense to switch to it, I can't remember if I needed any hacks to get signals working reliably, but maybe that will save me from needing some in future!

[OnesuchDev]

I just read about sigpause (which 123 uses according to nm) - its behavior is entirely different in glibc/BSD compared to SysV.

"The classical BSD version of this function appeared in 4.2BSD. It sets the process's signal mask to sigmask. UNIX 95 standardized the incompatible System V version of this function, which removes only the specified signal sig from the process's signal mask." https://linux.die.net/man/3/sigpause

To fix it on Linux, create a wrapper that just calls the original sigpause, and in the source file compiling the wrapper, before including anything, define _SVID_SOURCE.

Also gsignal/ssignal don't work right on Linux https://man7.org/linux/man-pages/man3/gsignal.3.html - I guess you would have to reimplement them.

In the next couple days I might look at the other functions 123 uses and see if I find more issues.

[rruhle]

Would this affect the spreadsheet function @@(), which doesn't work in Linux?

[taviso]

Hmm, do you have an example formula that doesn't work?

I use it sometimes, e.g. @@("A1") works, and ranges like @SUM(@@("A1..B1")) works here.

[rruhle]

Managing range names, or checking names for a range becomes harder when not shown in status bar.

Since @cell(attributes) won't reveal range names, the legacy DOS 123 spreadsheet function @@() showed any names created for a cell address in top left status bar.

While Linux shows the same referenced value at cell location containing @@() function, only cell address appears in top left status bar, no range name(s).

The more range names created, the harder it becomes to find or check a named range with the alternative key sequence F5, F3, F3, and scrolling thru all range names to locate the intended cell address.

[taviso]

Hmm, I wasn't familiar with that!

I know that in POINT mode if you choose a range that has a name, and press F3, 123 will enter the name, does that help?

We could add a new attribute like @CELL("name", D6) in the next release if that would be useful? I guess the question is what to do if that cell/range doesn't have a name, or has multiple names!

Maybe we could just return ERR unless there is exactly one match?

[rruhle]

If earlier mentioned code wrappers are not causing spreadsheet function status anomaly, then my discussion can be moved or postponed to avoid hijacking the original question regarding code wrappers.

I created new issue named "Function status missing range name"