On Sat, Oct 17, 2009 at 8:07 AM, Ingo Schwarze <schwa...@usta.de> wrote: > Matt Fisher wrote on Thu, Oct 15, 2009 at 11:39:39PM -0400: >> Stuart Henderson referred me to the tech list for this question. >> >> Here's a diff showing one line of possible cruft deleted from m4. >> This is one of 9 similar occurrences I've found in the src tree. > > I guess you are changing semantics.
Yes, yes that would. <...> > As far as i understand, that means: > "In case SIGINT is being ignored at the time m4 is invoked, > continue ignoring it. > In case it is not being ignored at startup time, > replace the existing handler by the function onintr." See, Ingo, you're thinking about what the change means. Matt, do you understand *why* that code was originally added to m4? Do you understand the circumstances under which it actually had an effect? Have you investigated whether those circumstances still occur? If the answers to those questions are "yes", then you should say so and back it up. If not, why should we apply a diff to remove code from someone who doesn't know why the code is there? As is, I believe you don't understand why that code was added, don't understand when it was triggered, and don't know whether or not it could still be triggered. >> A few days back I asked the misc list if such code should be *added*. > > As an aside, you didn't say where, or why. > >> Theo replied this isn't necessary in BSD. > > No, Theo wrote: > > "I assume you are talking about resetting the signals when > they are caught. That is not required in BSD unix." > > It is *now* clear this was _not_ what you were talking about, > so Theo's answer doesn't apply. > In fact, you gave no context, so it was not obvious what you > were talking about. Well, IIRC, he cited a usenix paper that described why this code was needed. From Theo's reply I would assume (there's that word again) that he didn't chase the link. I suspect Theo was talking about BSD changing the behavior of signal() to not reset signals on entry to the handler, but that's not what this code is about. The job control semantics (process-groups, etc) that BSD added *are* relevant, but are not the entire picture. >> So I've concluded that >> existing code like this could in fact be deleted. > > At least for the case at hand, i doubt that, but i do not know > that much about signal handling, so i would certainly not dare > to attempt cleanups in that region. I do know signals pretty well and I doubt it as well. >> Is that right? >> Anybody want to see more diffs for deleted cruft? If they lack research like this one, I don't want to see them either. Philip Guenther
