home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 241,878 of 243,242   
   Lew Pitcher to Scott Lurndal   
   Re: SIG_DFL   
   09 Nov 25 22:13:18   
   
   From: lew.pitcher@digitalfreehold.ca   
      
   On Sun, 09 Nov 2025 21:46:55 +0000, 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)).   
   >   
   >   
   > ,> 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  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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca