Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with signames.c generation (SIGRTMIN, &c.) #2

Open
okdana opened this issue Jul 2, 2018 · 0 comments
Open

Issues with signames.c generation (SIGRTMIN, &c.) #2

okdana opened this issue Jul 2, 2018 · 0 comments
Labels

Comments

@okdana
Copy link
Owner

okdana commented Jul 2, 2018

(workers/43134 [mentioned])

The way zsh generates its list of recognised signals (signames1.awk -> signames2.awk -> signames.c) isn't ideal:

  1. When zsh can't find the definition for a signal in between the min and the max, it just puts the number in its place. This is useful in some ways — it ensures that subsequent signal numbers aren't affected by the missing ones, and in the event that the signal actually is valid it ensures that we at least recognise the signal by number, even if we don't know the name.

    However, it's not useful when the signal is actually undefined. In that case, we have a scenario where zsh thinks a signal exists when it doesn't at all. This is (was) especially noticeable on AIX, which leaves signals 26 and 40 through 59 undefined. In terms of platforms that people actually give a shit about, it isn't currently a problem, but it would be if we addressed the following points.

  2. zsh does not support SIGRT* signals on any platform (except SIGRTMIN on Solaris). That's because...

  3. zsh can not generate signals which are defined in terms of other macros, expressions, or function calls:

    // Example from glibc
    #define SIGRTMIN __SIGRTMIN
    // Example from OpenIndiana
    #define SIGRTMIN ((int)_sysconf(_SC_SIGRT_MIN))

    I don't see a way around this except to actually compile something from C to evaluate those macros. That'll require a few changes to the signames.c-generation pipe-line.

  4. In order to properly support SIGRT* signals, we'll also need to generate the intervening ones, and we'll need to give them symbolic names. Some systems use names like SIGRTMIN+1 whilst others use SIGRT1. I guess we should probably support both.

References:

@okdana okdana added enhancement unreported Not reported to the ML question labels Jul 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant