have no CURFILE anymore so we cannot print a file name or line number.
When ParseSkipLine() returns NULL (it does this when it has detected an
EOF in an .if block) try to pop the input stack and process the next line
- Fix ifconfig commands. Replace 'mekmitasdigoat' with
'foobar'. While the former is more cool, the latter
makes example lines shorter.
Wording by: scottl
MFC after: 3 days
Parse_File(). Remove a comment and a piece of code comming from
ancient times when the if-directive read like #if and not .if.
Correctly analyze the first character of a line.
structure - it is just the strlen() of noPrint. Inline JobCondPassSig()
in the only function JobPassSig() using it. Fix the argument types
of JobPrintCommand(). Better parsing for the .SHELL target keywords.
protocol. RFCOMM is a SOCK_STREAM protocol not SOCK_SEQPACKET. This was a
serious bug caused by cut-and-paste. I'm surprised it did not bite me before.
Dunce hat goes to me.
MFC after: 3 days
debug.mpsafevm=1 by default on sparc64,
ixgb(4) MPSAFE,
core dump of natd(8) w/ -reverse fixed,
libarchive zip support improved, and
rexecd(8) root login problem fixed.
EA bit is set in hdr->length (16-bit length). This currently has no effect
on the rest of the code. It just fixes the debug message.
MFC After: 3 weeks
we have a non-NULL args.rule. If the same packet later is subject to "tee"
rule, its original is sent again into ipfw_chk() and it reenters at the same
rule. This leads to infinite loop and frozen router.
Assign args.rule to NULL, any time we are going to send packet back to
ipfw_chk() after a tee rule. This is a temporary workaround, which we
will leave for RELENG_5. In HEAD we are going to make divert(4) save
next rule the same way as dummynet(4) does.
PR: kern/79546
Submitted by: Oleg Bulyzhin
Reviewed by: maxim, andre
MFC after: 3 days
to root cause on exactly how this happens.
- If the assert is disabled, we presently try to handle this case, but the
BUF_UNLOCK was missing. Thus, if this condition ever hit we would leak
a buf lock.
Many thanks to Peter Holm for all his help in finding this bug. He really
put more effort into it than I did.
* Handles entries with compressed size >2GB (signed/unsigned cleanup)
* Handles entries with compressed size >4GB ("ZIP64" extension)
* Handles Unix extensions (ctime, atime, mtime, mode, uid, etc)
* Format-specific "skip data" override allows ZIP reader to skip
entries without decompressing them, which makes "tar -t"
a lot faster.
* Handles "length-at-end" entries generated by, e.g., "zip -r - foo"
Many thanks to: Dan Nelson, who contributed the code and test files for
the first three items above and suggested the fourth.
the register values coming back from sigreturn(2). Normally this wouldn't
matter because the 32 bit environment would truncate the upper 32 bits
and re-save the truncated values at the next trap. However, if we got
a fast second signal and it was pending while we were returning from
sigreturn(2) in the signal trampoline, we'd never have had a chance to
truncate the bogus values in 32 bit mode, and the new sendsig would get
an EFAULT when trying to write to the bogus user stack address.