One of many newbie questions from me... Cant find the info I'm looking for.

If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

--
:wq
Mike Sanders

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for.

If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, seem to specify exactly _why_ SIG_DFL is named that way. Presumably because other abbreviations would somehow conflict or possibly be confused with existing nomenclature (SIGUSR1 and SIGUSR2, for instance, are user-DEFined signals, and SIG_DEF might confuse someone who isn't entirely familiar with
the nomenclature), or because (like many abbreviations in Unix, "DeFauLt"
made more sense to someone.

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 8 Nov 2025 19:28:20 -0000 (UTC), Lew Pitcher wrote:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, seem to specify exactly _why_ SIG_DFL is named that way. Presumably because other abbreviations would somehow conflict or possibly be confused with existing nomenclature (SIGUSR1 and SIGUSR2, for instance, are user-DEFined signals, and SIG_DEF might confuse someone who isn't entirely familiar with the nomenclature), or because (like many abbreviations in Unix, "DeFauLt" made more sense to someone.

Thanks again Lew. I'm running with: [D]e[F]ault [L]evel in my // comments.

--
:wq
Mike Sanders

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-11-08, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, seem to specify exactly _why_ SIG_DFL is named that way.

It's not named SIGNAL_DEFAULT probably in order to harmonize with
strpbrk, which is not named string_pointer_to_break.

Programmers long ago loved creating "bumper stumpers" by removing
vowels and some consontants too.

I agree with them; I positively never want to write shit like

#include <standard_input_ouput.header>

or work in any tech stack where that is the norm.

The superfluous "std" should have been omitted from <stdio.h>; other
standard headers do not carry a reminder that they are standard, like <string.h>, <math.h> or <assert.h>.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 11/8/2025 12:14 PM, Kaz Kylheku wrote:

On 2025-11-08, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym? >>

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that >> signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >> seem to specify exactly _why_ SIG_DFL is named that way.

It's not named SIGNAL_DEFAULT probably in order to harmonize with
strpbrk, which is not named string_pointer_to_break.

Programmers long ago loved creating "bumper stumpers" by removing
vowels and some consontants too.

:^)

lol. For some reason it reminds me of the PPC instruction, EIEIO. ;^)

I agree with them; I positively never want to write shit like

#include <standard_input_ouput.header>

or work in any tech stack where that is the norm.

The superfluous "std" should have been omitted from <stdio.h>; other standard headers do not carry a reminder that they are standard, like <string.h>, <math.h> or <assert.h>.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-11-08, Michael Sanders <porkchop@invalid.foo> wrote:

On Sat, 8 Nov 2025 19:28:20 -0000 (UTC), Lew Pitcher wrote:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym? >>

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that >> signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >> seem to specify exactly _why_ SIG_DFL is named that way. Presumably because >> other abbreviations would somehow conflict or possibly be confused with
existing nomenclature (SIGUSR1 and SIGUSR2, for instance, are user-DEFined >> signals, and SIG_DEF might confuse someone who isn't entirely familiar with >> the nomenclature), or because (like many abbreviations in Unix, "DeFauLt"
made more sense to someone.

Thanks again Lew. I'm running with: [D]e[F]ault [L]evel in my // comments.

That is likely apocryphal; since L is present in "default", the
simplest hypothesis is that the L in DFL is that one.

The argument in question is a handler not a level. That has an L,
but not in the leading position, making the revised origin hypothesis [D]e[F]ault hand[L]ing is even more farfetched.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 8 Nov 2025 20:17:28 -0000 (UTC), Kaz Kylheku wrote:

Thanks again Lew. I'm running with: [D]e[F]ault [L]evel in my // comments.

That is likely apocryphal; since L is present in "default", the
simplest hypothesis is that the L in DFL is that one.

The argument in question is a handler not a level. That has an L,
but not in the leading position, making the revised origin hypothesis [D]e[F]ault hand[L]ing is even more farfetched.

Yeah my take adds a word which is less than optimal...

--
:wq
Mike Sanders

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Michael Sanders <porkchop@invalid.foo> writes:

One of many newbie questions from me... Cant find the info I'm looking for.

If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

It never would have occurred to me that SIG_DFL was anything other
than an abbreviation for SIGnal_DeFauLt.

It's clear enough that SIG_ERR means SIGnal_ERRor, and SIG_IGN
means SIGnal_IGNore. SIG_DFL follows the same pattern of SIG_XXX,
but doesn't take the first three letters of the word it abbreviates
-- probably because DEF suggests "definition" rather than "default".

There are plenty of cases where C identifiers are abbreviations not
taken from the first letters of a word. See strcmp (STRing CoMPare),
sqrt (SQuare RooT), etc.

(Pedantic quibble: It's not really an acronym, which is a word formed
from the initials of several words, like laser, radar, or scuba).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 08 Nov 2025 14:57:35 -0800, Keith Thompson wrote:

(Pedantic quibble: It's not really an acronym, which is a word formed
from the initials of several words, like laser, radar, or scuba).

Mnemonic? I don't know...

--
:wq
Mike Sanders

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-11-08, Michael Sanders <porkchop@invalid.foo> wrote:

On Sat, 08 Nov 2025 14:57:35 -0800, Keith Thompson wrote:

(Pedantic quibble: It's not really an acronym, which is a word formed
from the initials of several words, like laser, radar, or scuba).

Mnemonic? I don't know...

DFL is a pretty common abbreviation of "default".

Search for identifiers starting with "dfl" or "DFL" (or any mixutre of these) in a project of mine that is maybe 90-100 KLOC.

That's just one project by one author.

ChangeLog-2009-2015: * gc.c (MALLOC_DELTA_THRESH): Macro remaned to DFL_MALLOC_DELTA_THRESH.
gc.c:#define DFL_MALLOC_DELTA_THRESH (16L * 1024 * 1024)
gc.c:#define DFL_STACK_LIMIT (128 * 1024L)
gc.c:#define DFL_MALLOC_DELTA_THRESH (64L * 1024 * 1024)
gc.c:#define DFL_STACK_LIMIT (16384 * 1024L)
gc.c:alloc_bytes_t opt_gc_delta = DFL_MALLOC_DELTA_THRESH;
gc.c: gc_stack_limit = gc_stack_bottom - DFL_STACK_LIMIT / sizeof (val); lib.c: dfl:
lib.c: goto dfl;
lib.c: val dfl = env->v.vec[2];
lib.c: return if3(pos, ref(rng, pos), dfl);
lib.c: cons_bind (hash, dfl, env);
lib.c: return if3(cell, cdr(cell), dfl);
lib.c:val relate(val domain_seq, val range_seq, val dfl_val)
lib.c: return if3(missingp(dfl_val),
lib.c: if3(null(dfl_val),
lib.c: func_f1(cons(hash, dfl_val), do_relate_hash_dfl)), lib.c: func_f1(vec(domain_seq, range_seq, dfl_val, nao), lib.h:val relate(val domain_seq, val range_seq, val dfl_val);
lib.h:#define default_arg(arg, dfl) if3(null_or_missing_p(arg), dfl, arg) lib.h:#define default_arg_strict(arg, dfl) if3(missingp(arg), dfl, arg) match.c: cons_bind (var, dfl, car(iter));
match.c: int is_dfl = (dfl != noval_s);
match.c: strictly_new_bindings = acons(var, dfl, strictly_new_bindings);
match.c: cons_bind (var, dfl_val, car(iter));
match.c: if (dfl_val == noval_s) {
match.c: c->bindings = acons(var, dfl_val, c->bindings);
match.c: val dfl = cadr(var);
match.c: val dfl_ex = expand(dfl, nil);
match.c: ptail = list_collect(ptail, if3(dfl == dfl_ex,
match.c: var, list(sym, dfl_ex, nao))); match.c: cons_bind (var, dfl, car(iter));
match.c: int is_dfl = (dfl != noval_s);
match.c: strictly_new_bindings = acons(var, dfl, strictly_new_bindings);
stdlib/getopts.tl:(defmeth opts lambda (me key : dfl)
stdlib/getopts.tl: (iflet ((o [me.opt-hash key])) o.arg dfl))
stdlib/match.tl: (let ((dfl-cnt 0))
stdlib/match.tl: (inc dfl-cnt))]]] stdlib/match.tl: (< dfl-cnt 2)
stdlib/match.tl: (or (zerop dfl-cnt)
stdlib/place.tl: dfl-sym)
stdlib/place.tl: (,dfl-sym ,',default)) stdlib/place.tl: ,dfl-sym)))
stream.c: int dfl_precision = 0, dfl_digits = 0, print_base = 0;
stream.c: if (!dfl_digits)
stream.c: dfl_digits = c_num(cdr(lookup_var(nil, print_flo_digits_s)), self);
stream.c: precision = dfl_digits;
stream.c: if (!dfl_precision)
stream.c: dfl_precision = c_num(cdr(lookup_var(nil,
stream.c: precision = dfl_precision;
txr.1:.code "[o \(dqv\(dq dfl]"
txr.1:.codn dfl .

I do not believe I'm influenced by SIG_DFL, or if so, certainly
not to a more significant degree by that than other exposure to "dfl"
in the wild.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym?

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >seem to specify exactly _why_ SIG_DFL is named that way.

Signal _names_ use the 'SIG' prefix.

Signal _actions_ use an underscore (SIG_IGN, SIG_DFL, SIG_BLOCK, SIG_SETMASK, SIG_UNBLOCK). SIG_IGN, SIG_DFL values are defined such that they are unlikely to be
a valid program address on the target architectures (see PDP-11 definitions below).

The naming is defined, but not explicitly discussed in the SVID, Vol 1, Third Edition
signal(BA_OS) section (the third edition also introduced sigaction(2)).

or because (like many abbreviations in Unix, "DeFauLt"

made more sense to someone.

That seems most likely. DEF might appear to mean DEFine, to
those not familiar with Unix signals.

Unix v6 treated the handler address as "default action"
when the address value was 0, and an odd address
meant the same as SIG_IGN.

/ C library -- signal

/ signal(n, 0); /* default action on signal(n) */
/ signal(n, odd); /* ignore signal(n) */
/ signal(n, label); /* goto label on signal(n) */
/ returns old label, only one level.



--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-11-08, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym? >>

From the C11 draft standard (yes, I know, but that's the most current I have)

7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that >> signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >> seem to specify exactly _why_ SIG_DFL is named that way.

It's not named SIGNAL_DEFAULT probably in order to harmonize with
strpbrk, which is not named string_pointer_to_break.

It's more likely that it was, in the context of 1970s unix,
kept within the limits of the compiler and assembler (for which
only 8 characters were significant).

On the PDP-11, a handler argument of zero meant default action
and an odd handler argument indicated the signal should be
ignored (PDP-11 instruction addresses were 16-bit aligned).

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 09 Nov 2025 21:46:55 +0000, Scott Lurndal wrote:

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym? >>

From the C11 draft standard (yes, I know, but that's the most current I have) >>
7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >>seem to specify exactly _why_ SIG_DFL is named that way.

Signal _names_ use the 'SIG' prefix.

Signal _actions_ use an underscore (SIG_IGN, SIG_DFL, SIG_BLOCK, SIG_SETMASK, SIG_UNBLOCK). SIG_IGN, SIG_DFL values are defined such that they are unlikely to be
a valid program address on the target architectures (see PDP-11 definitions below).

The naming is defined, but not explicitly discussed in the SVID, Vol 1, Third Edition
signal(BA_OS) section (the third edition also introduced sigaction(2)).

or because (like many abbreviations in Unix, "DeFauLt"

made more sense to someone.

That seems most likely. DEF might appear to mean DEFine, to
those not familiar with Unix signals.

Unix v6 treated the handler address as "default action"
when the address value was 0, and an odd address
meant the same as SIG_IGN.

Interestingly, the signal() function first appeared in AT&T Unix Version 4, without <signal.h> and it's associated SIG* definitions.
(see https://dspinellis.github.io/unix-v4man/v4man.pdf)

Instead, the manual page for the signal() function states

signal(sig, func)
int (*func)();

...

In C, if func is 0 or 1, the action is as described above.[1]
If func is even, it is assumed to be the address of a function
entry point. When the signal occurs, the function will be called.

[1] in reference to the syscall, described previously, that stated
(of the syscall "value" argument, analogous to the C function "func")
"If value is 0, the default system action applies to the signal.
This is processes termination with or without a core dump. If
value is odd, the signal is ignored."

Interestingly, Version 4 Unix signal() depended on the knowledge
of the alignment of function code; valid functions were non-zero
addresses aligned to even byte boundaries, permitting the zero and
odd-address values to be used as metadata such as "use the default"
or "ignore this signal".

I presume that the signal names and SIG_ values were formalized
in Version 5, but have yet to see either the manpage or the
contents of /usr/include/signal.h from that version of Unix.


[snip]

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10er3lt$3gj90$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

I presume that the signal names and SIG_ values were formalized
in Version 5, but have yet to see either the manpage or the
contents of /usr/include/signal.h from that version of Unix.

There's no mention of them even in the 6th edition manual, so presumably
they were introduced in 7th edition (which certainly had them).

-- Richard

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

On Sun, 09 Nov 2025 21:46:55 +0000, Scott Lurndal wrote:

Neither the C standard, nor the Posix standards or Unix manuals before that, >>>seem to specify exactly _why_ SIG_DFL is named that way.

Signal _names_ use the 'SIG' prefix.

Signal _actions_ use an underscore (SIG_IGN, SIG_DFL, SIG_BLOCK, SIG_SETMASK,
SIG_UNBLOCK). SIG_IGN, SIG_DFL values are defined such that they are unlikely to be
a valid program address on the target architectures (see PDP-11 definitions below).

The naming is defined, but not explicitly discussed in the SVID, Vol 1, Third Edition
signal(BA_OS) section (the third edition also introduced sigaction(2)).

or because (like many abbreviations in Unix, "DeFauLt"

made more sense to someone.

That seems most likely. DEF might appear to mean DEFine, to
those not familiar with Unix signals.

Unix v6 treated the handler address as "default action"
when the address value was 0, and an odd address
meant the same as SIG_IGN.

Interestingly, the signal() function first appeared in AT&T Unix Version 4, >without <signal.h> and it's associated SIG* definitions.
(see https://dspinellis.github.io/unix-v4man/v4man.pdf)

Instead, the manual page for the signal() function states

signal(sig, func)
int (*func)();

...

In C, if func is 0 or 1, the action is as described above.[1]
If func is even, it is assumed to be the address of a function
entry point. When the signal occurs, the function will be called.

[1] in reference to the syscall, described previously, that stated
(of the syscall "value" argument, analogous to the C function "func")
"If value is 0, the default system action applies to the signal.
This is processes termination with or without a core dump. If
value is odd, the signal is ignored."

Interestingly, Version 4 Unix signal() depended on the knowledge
of the alignment of function code; valid functions were non-zero
addresses aligned to even byte boundaries, permitting the zero and >odd-address values to be used as metadata such as "use the default"
or "ignore this signal".

I presume that the signal names and SIG_ values were formalized
in Version 5, but have yet to see either the manpage or the
contents of /usr/include/signal.h from that version of Unix.

I don't think signal.h existed in V5 or V6. The signal system
call was completely written in assembler. The v6 source tree I'm
looking at doesn't have any man pages, a man command or signal.h.

The v7 man page for signal(2) does include "SIG_DFL".

DESCRIPTION
A signal is generated by some abnormal event, initiated either by user
at a typewriter (quit, interrupt), by a program error (bus error, etc.),
or by request of another program (kill). Normally all signals cause
termination of the receiving process, but a signal call allows them ei-
ther to be ignored or to cause an interrupt to a specified location.
Here is the list of signals with names as in the include file.

SIGHUP 1 hangup
SIGINT 2 interrupt
SIGQUIT 3* quit
SIGILL 4* illegal instruction (not reset when caught)
SIGTRAP 5* trace trap (not reset when caught)
SIGIOT 6* IOT instruction
SIGEMT 7* EMT instruction
SIGFPE 8* floating point exception
SIGKILL 9 kill (cannot be caught or ignored)
SIGBUS 10* bus error
SIGSEGV 11* segmentation violation
SIGSYS 12* bad argument to system call
SIGPIPE 13 write on a pipe or link with no one to read it
SIGALRM 14 alarm clock
SIGTERM 15 software termination signal
16 unassigned

The starred signals in the list above cause a core image if not caught
or ignored.

If func is SIG_DFL, the default action for signal sig is reinstated;
this default is termination, sometimes with a core image. If func is
SIG_IGN the signal is ignored. Otherwise when the signal occurs func
will be called with the signal number as argument. A return from the
function will continue the process at the point it was interrupted. Ex-
cept as indicated, a signal is reset to SIG_DFL after being caught.
Thus if it is desired to catch every such signal, the catching routine
must issue another signal call.

When a caught signal occurs during certain system calls, the call termi-
nates prematurely. In particular this can occur during a read or
write(2) on a slow device (like a typewriter; but not a file); and dur-
ing pause or wait(2). When such a signal occurs, the saved user status
is arranged in such a way that when return from the signal-catching
takes place, it will appear that the system call returned an error sta-
tus. The user's program may then, if it wishes, re-execute the call.

The value of signal is the previous (or initial) value of func for the
particular signal.

After a fork(2) the child inherits all signals. Exec(2) resets all
caught signals to default action.


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 10 Nov 2025 14:47:56 +0000, Richard Tobin wrote:

In article <10er3lt$3gj90$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

I presume that the signal names and SIG_ values were formalized
in Version 5, but have yet to see either the manpage or the
contents of /usr/include/signal.h from that version of Unix.

There's no mention of them even in the 6th edition manual, so presumably
they were introduced in 7th edition (which certainly had them).

You appear to be correct.

The Unix Heritage Society (tuhs.org) has (admittedly incomplete) records
for both the 6th Edition and 7th Edition Unix.

The 6th Edition manpage for signal() still discusses the signal-handler function in terms of zero/odd/even addresses. (tuhs doesn't have a record
of the 6th Edition /usr/include sources).

OTOH, the 7th Edition manpage for signal() discusses the signal-handler function in terms of SIG_IGN and SIG_DFL. Additionally, tuhs includes
the /usr/include source for signal.h, which has the macros for the
various signals along with SIG_IGN and SIG_DFL.

So it appears that SIG_IGN and SIG_DFL were formalized as part of
7th Edition Unix.

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <jZ7QQ.808705$6_hb.715065@fx46.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

On Sat, 08 Nov 2025 19:01:00 +0000, Michael Sanders wrote:

One of many newbie questions from me... Cant find the info I'm looking for. >>>
If SIG_IGN is an acronym for signal ignore, then what does DFL mean?
I've know (well I presume) it restores default behavior, but the acronym? >>

From the C11 draft standard (yes, I know, but that's the most current I have) >>
7.14.1.1 The signal function
2. ... If the value of func is SIG_DFL, default handling for that
signal will occur.

Neither the C standard, nor the Posix standards or Unix manuals before that, >>seem to specify exactly _why_ SIG_DFL is named that way.

Signal _names_ use the 'SIG' prefix.

Signal _actions_ use an underscore (SIG_IGN, SIG_DFL, SIG_BLOCK, SIG_SETMASK, >SIG_UNBLOCK). SIG_IGN, SIG_DFL values are defined such that they are unlikely to be
a valid program address on the target architectures (see PDP-11 definitions below).

The naming is defined, but not explicitly discussed in the SVID, Vol 1, Third Edition
signal(BA_OS) section (the third edition also introduced sigaction(2)).

Symbolic constants for `SIG_IGN` and `SIG_DFL` appear to arrive
between the 6th and 7th editions of research Unix. From volume
2 of the UPM, in a document entitled, "Unix Programming", one
reads the following:

```
The include file
.UL signal.h
gives names for the various arguments, and should always be included
when signals are used.
Thus
.P1
#include <signal.h>
...
signal(SIGINT, SIG_IGN);
.P2
causes interrupts to be ignored, while
.P1
signal(SIGINT, SIG_DFL);
.P2
restores the default action of process termination.
```

The rationale behind the names is not, to my knowledge,
explained anywhere, but it seems obvious that `SIG_DFL` refers
to "default". As mentioned, signals have no concept of a
"level" (unlike, say, prioritized interrupts) so that does not
apply here.

or because (like many abbreviations in Unix, "DeFauLt"

made more sense to someone.

That seems most likely. DEF might appear to mean DEFine, to
those not familiar with Unix signals.

Unix v6 treated the handler address as "default action"
when the address value was 0, and an odd address
meant the same as SIG_IGN.

/ C library -- signal

/ signal(n, 0); /* default action on signal(n) */
/ signal(n, odd); /* ignore signal(n) */
/ signal(n, label); /* goto label on signal(n) */
/ returns old label, only one level.

This code is retained in the v7 C library (despite being
assembler; though that's mostly for the trap into the kernel).

The kernel code that distinguishes between `SIG_IGN` and
otherwise is a bit subtle, but is in `issig` in `sys/sig.c`:

```
while(p->p_sig) {
n = fsig(p);
if((u.u_signal[n]&1) == 0 || (p->p_flag&STRC))
return(n);
p->p_sig &= ~(1<<(n-1));
}
```

Sending a signal in Unix is indirect; the sender simply sets a
bit on the target process's signal state. The process delivers
the signal itself the next time it is run. If the low bit of
the signal handler for the pending signal is set when the
process goes to check, then the pending bit for that signal is
simply cleared.

- Dan C.


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)