From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Scott Lurndal  wrote:   
   >Lew Pitcher  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(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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)