Re: master ed84f24a21: Make `signal-process' allow completing over signal names

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> +DEFUN ("signal-names", Fsignal_names, Ssignal_names, 0, 0, 0,
> +       doc: /* Return a list of known signal names on this system.  */)
> +  (void)
> +{
> +  char name[SIG2STR_MAX];
> +  Lisp_Object names = Qnil;
> +  for (int i = 0; i < 255; ++i)
> +    {
> +      if (!sig2str (i, name))
> +	{
> +	  names = Fcons (build_string (name), names);
> +	}
> +    }
> +  return names;
> +}
> +

Shouldn't the "255" be NSIG instead? And what about systems where POSIX
signal handling doesn't really apply, such as MS Windows and MS-DOS?

Thanks.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Shouldn't the "255" be NSIG instead? And what about systems where POSIX
> signal handling doesn't really apply, such as MS Windows and MS-DOS?

I just punt to gnulib.  Presumably it gets all this right, and if not,
it's a bug in gnulib.  (I guess there are systems with on OS sig2str,
too, but the same applies there.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I just punt to gnulib.  Presumably it gets all this right, and if not,
> it's a bug in gnulib.

gnulib doesn't specify the largest signal number to be 255, right?

> (I guess there are systems with on OS sig2str, too, but the same
> applies there.)

They don't exist, AFAICT sig2str is a gnulib extension.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> I just punt to gnulib.  Presumably it gets all this right, and if not,
>> it's a bug in gnulib.
>
> gnulib doesn't specify the largest signal number to be 255, right?

Oh, you mean the loop ends one too early?  Yes, that's true.  Can't have
new code without at least one off-by-one error; that's illegal.

>> (I guess there are systems with on OS sig2str, too, but the same
>> applies there.)
>
> They don't exist, AFAICT sig2str is a gnulib extension.

That was my original assumption, but we apparently check the OS for
sig2str via autoconf, I discovered yesterday.  config.h:

/* Define to 1 if you have the `sig2str' function. */
/* #undef HAVE_SIG2STR */


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, you mean the loop ends one too early?  Yes, that's true.  Can't have
> new code without at least one off-by-one error; that's illegal.

I also meant that the loop should end at NSIG - 1, or SIGRTMAX, instead
of an arbitrary number (254).

> That was my original assumption, but we apparently check the OS for
> sig2str via autoconf, I discovered yesterday.  config.h:
>
> /* Define to 1 if you have the `sig2str' function. */
> /* #undef HAVE_SIG2STR */

Ah, now I remember.  It also exists on some proprietary Unices and very
old versions of GNU/Linux.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Oh, you mean the loop ends one too early?  Yes, that's true.  Can't have
>> new code without at least one off-by-one error; that's illegal.
>
> I also meant that the loop should end at NSIG - 1, or SIGRTMAX, instead
> of an arbitrary number (254).

I wasn't able to convince myself that SIGRTMIN/MAX was defined on all
systems (the ones that have an OS-defined sig2str), so I just used
magical numbers (that are way too big on any OS) instead.  But if you
want to adjust, please go ahead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I wasn't able to convince myself that SIGRTMIN/MAX was defined on all
> systems (the ones that have an OS-defined sig2str), so I just used
> magical numbers (that are way too big on any OS) instead.  But if you
> want to adjust, please go ahead.

What about NSIG? It should be more portable than SIGRTMAX, but I don't
know if it's available on every platform we support.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> What about NSIG? It should be more portable than SIGRTMAX, but I don't
> know if it's available on every platform we support.

I think NSIG is a GNU/Linux thing, while SIGRTMIN/MAX is Posix?  But I
don't know.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think NSIG is a GNU/Linux thing, while SIGRTMIN/MAX is Posix?  But I
> don't know.

Yes, but AFAIU POSIX doesn't specify anything about which number is
assigned to SIGRTMIN.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Daniel Martín]

Po Lu <luangruo@yahoo.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> +DEFUN ("signal-names", Fsignal_names, Ssignal_names, 0, 0, 0,
>> +       doc: /* Return a list of known signal names on this system.  */)
>> +  (void)
>> +{
>> +  char name[SIG2STR_MAX];
>> +  Lisp_Object names = Qnil;
>> +  for (int i = 0; i < 255; ++i)
>> +    {
>> +      if (!sig2str (i, name))
>> +	{
>> +	  names = Fcons (build_string (name), names);
>> +	}
>> +    }
>> +  return names;
>> +}
>> +
>
> Shouldn't the "255" be NSIG instead? And what about systems where POSIX
> signal handling doesn't really apply, such as MS Windows and MS-DOS?
>

In the same header that defines SIG2STR_MAX there is SIGNUM_BOUND.  It
is defined depending on the availability of other macros, including
NSIG.  Couldn't it be used instead?

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Daniel Martín <mardani29@yahoo.es> writes:

> In the same header that defines SIG2STR_MAX there is SIGNUM_BOUND.  It
> is defined depending on the availability of other macros, including
> NSIG.  Couldn't it be used instead?

If I understand correctly, SIG2STR_MAX is also defined by the OS
sig2str:

/* Don't override system declarations of SIG2STR_MAX, sig2str, str2sig.  */
#ifndef SIG2STR_MAX

So we're free to use SIG2STR_MAX on all systems (because it's either
defined by gnulib or the OS).  Is the same the case for SIGNUM_BOUND?
(It might just be defined by gnulib.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Jun 2022 09:20:26 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > +DEFUN ("signal-names", Fsignal_names, Ssignal_names, 0, 0, 0,
> > +       doc: /* Return a list of known signal names on this system.  */)
> > +  (void)
> > +{
> > +  char name[SIG2STR_MAX];
> > +  Lisp_Object names = Qnil;
> > +  for (int i = 0; i < 255; ++i)
> > +    {
> > +      if (!sig2str (i, name))
> > +	{
> > +	  names = Fcons (build_string (name), names);
> > +	}
> > +    }
> > +  return names;
> > +}
> > +
> 
> Shouldn't the "255" be NSIG instead? And what about systems where POSIX
> signal handling doesn't really apply, such as MS Windows and MS-DOS?

I admit that I don't understand the purpose and the intended uses of
this new primitive.  Is it there only for signal-process or more
generally for read-signal-name or even more generally for providing
the exhaustive list of names of all the signals known to the OS?

If it's only for signal-process, then is it really useful to produce a
completion table of 63 or 255 signal names, quite a few of which
cannot be usefully delivered to another process?  Perhaps it would be
better to have a much shorter (system-dependent) list of signals that
can be delivered to processes on each system?  IOW, if this is
supposed to be a convenience feature, then why not provide the user
with a convenient short list of signals that he/she would reasonably
consider delivering, and leave the rest to numbers?

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I admit that I don't understand the purpose and the intended uses of
> this new primitive.  Is it there only for signal-process or more
> generally for read-signal-name or even more generally for providing
> the exhaustive list of names of all the signals known to the OS?

It's for read-signal-name.

> If it's only for signal-process, then is it really useful to produce a
> completion table of 63 or 255 signal names, quite a few of which
> cannot be usefully delivered to another process?  Perhaps it would be
> better to have a much shorter (system-dependent) list of signals that
> can be delivered to processes on each system?  IOW, if this is
> supposed to be a convenience feature, then why not provide the user
> with a convenient short list of signals that he/she would reasonably
> consider delivering, and leave the rest to numbers?

I don't know how to determine which ones are reasonable to consider
delivering, so punting to gnulib seems like a more long term solution.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't know how to determine which ones are reasonable to consider
> delivering, so punting to gnulib seems like a more long term solution.

The problem is gnulib doesn't say that there are 255, or 256, or 254
signals.  How about using SIGNUM_BOUND instead?

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The problem is gnulib doesn't say that there are 255, or 256, or 254
> signals.  How about using SIGNUM_BOUND instead?

I think we've been over this before?  Isn't that just a gnulib thing,
which will break on systems where we use the OS version?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think we've been over this before?

I must've missed that.

> Isn't that just a gnulib thing, which will break on systems where we
> use the OS version?

IIUC we always include the gnulib header (signal.h is the header that
defines sig2str on systems where that is present), so it won't break no
matter which implementation of sig2str is being used.

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> IIUC we always include the gnulib header (signal.h is the header that
> defines sig2str on systems where that is present), so it won't break no
> matter which implementation of sig2str is being used.

I don't follow.  SIGNUM_BOUND is only defined in sig2str.h, so it won't
be bound if we use the OS sig2str.  (Unless the OS one also defines a
header that includes that, but I have no idea whether that's the case or
not.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't follow.  SIGNUM_BOUND is only defined in sig2str.h, so it won't
> be bound if we use the OS sig2str.  (Unless the OS one also defines a
> header that includes that, but I have no idea whether that's the case or
> not.)

And we've now spent more time on this issue which emphatically Does Not
Matter In The Very Least (it's the upper bound -- on a very tiny loop --
used only in an interactive spec in a command) than on everything else
in Emacs over the last few months, so I'm bowing out of this one.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't follow.  SIGNUM_BOUND is only defined in sig2str.h, so it won't
> be bound if we use the OS sig2str.  (Unless the OS one also defines a
> header that includes that, but I have no idea whether that's the case or
> not.)

The OS sig2str is defined in signal.h.  sig2str.h only exists in gnulib.

Further more, gnulib headers regularly override only "parts" of the
system headers, in order to make up for missing (or incorrectly defined)
features.  Any .h file in lib/ is included preferentially.