complain about paths starting with `-', by not calling getopt(3).
Submitted by: Tim J. Robbins <tim@robbins.dropbear.id.au>
Obtained from: NetBSD (partially)
MFC after: 1 month
Previous commit included a large improvement to the salt generation to
help obfuscate information that is otherwise leaked. No real risks
involved, but this feels better, and does not use srandom[dev]().
after making test(1) a sh(1) builtin; sh(1) coredumps when you run
something like this:
sh -c 'test ! `true 1`'
The cause is that the test(1) code totally depends on the presence of
two extra cells at the end of argv that are filled with NULL's. The
reason why the bug hasn't been exposed would be because the C startup
code kindly prepares argv with some extra zeroed cells for a program.
I know this is not the best fix, but since there are argv++'s without
boundary checks everywhere, I'd rather patch it up like this
(preparing a copy of argv with extra NULL's) for the moment.
MFC after: 3 days
from old signal handlers. This is simpler and faster, and fixes (new)
sigreturn(2) when %eip in the new signal context happens to match the
magic value (0x1d516). 0x1d516 is below the default ELF text section,
so this probably never broken anything in practice.
locore.s:
In addition, don't build the signal trampoline for old signal handlers
when it is not used.
alpha:
Not fixed, but seems to be even less broken in practice due to more
advanced magic. A false match occurs for register #32 in mc_regs[].
Since there is no hardware register #32, a false match is only possible
for direct calls to sigreturn(2) that happen to have the magic number
in the spare mc_regs[32] field.
DOCDISTFILES if defined. No impact should happen with this change.
DOCDISTFILES is introduced by rev. 1.541, to point the directory that
contains the distfiles for ports/textproc/docproj. It's good, but
we also build ports/sysutils/mkisofs during the release (if MAKE_ISOS
is defined). It is natural that cdrtools tarball is prefetched, then
copy it under ${CHROOTDIR}/usr/ports/distfiles.
As a result, DOCDISTFILES variable is somewhat abused for non-doc
tarballs; *DOC*DISTFILES is no longger appropriate name for that.
PR: 16843
PR: 34194
Submitted by: murray
MFC after: 6 days
