This puts it on the same footing as cvsup. It's been suggested on
numerous occasions that I shouldn't have imported it in the first place,
and now that sup has outlived it's usefulness..... Boom!
kind of expressions caused a dereferencation of an uninitialized malloc
area, yielding wrong expression evaluation at best, and core dumps at
worst (malloc.conf -> AJ):
find ... ! \( expr1 ! expr2 \) ...
style and b) the wrong logic. Should be strstr(s, "##") != NULL. (Note
that the passwd.adjunct stuff has not been merged into 2.2 so this bug
is not in that branch.)
this is the main reason why we want them as diffs.) Also, ask them to
explicitly state files that are added or deleted (lazy committers like me
often forget to "cvs add" or "cvs remove").
we need now.
Don't assume that file descriptor can't be 0 (many places)
Protect FD_* macros from being used with negative descriptors
Shorten MS EXT show help to fit 80 cols
dangerous! Signal handlers themself must be fixed to not call malloc,
but no pended handlers, it will be correct fix. In finite case each signal
handler can set some variable which will be analized later, but calling
handler functions manually is too dangerous (f.e. signals not blocked while
the handler or handlers switch executed in this case). Of course this
code can be fixed instead of removing, but it not worth fixing in any case.
Should go into 2.2
In addition sig.c code shows following dangerous fragments (there can be more,
but I stop after two):
This fragment
if (fn == SIG_DFL || fn == SIG_IGN) {
handler[sig-1] = (sig_type)0;
<------------- here
signal(sig,fn);
} else {
cause NULL pointer reference when signal comes
"here", but more worse fragment is below:
void handle_signals() {
int sig;
if (caused)
for (sig=0; sig<__MAXSIG; sig++, caused>>=1)
if (caused&1)
(*handler[sig])(sig+1);
}
caused is bitmask which set corresponding bit on each signal coming.
And now imagine, what happens when some signal comes (bit sets) while loop
is executed (see caused>>=1 !!!)
In this light carrier drop situation was (as gdb shows)
1. SIGSEGV in handle_signals because some junk called as *handler reference.
2. Since SIGSEGV was pended too (== never happens),
it can cause various range of disasters.
