This self-written compiler warning, which is hopefully going to be
committed into LLVM sources soon, warns about potentially missing
`static' keywords, similar to -Wmissing-prototypes.
- bin/pax: Move external declaration of chdname and s_mask into extern.h.
- bin/setfacl: Move setfacl.c-specific stuff out of setfacl.h.
- sbin/mount_fusefs: Remove char *progname; use getprogname().
- others: add `static' where possible.
are too long. Filenames escaping this test are caught later on,
so the bug doesn't cause any breakage.
Document the correct ustar limitations in pax. As I have no access
to the IEEE 1003.2 spec, I can only assume that the limitations
imposed are in fact correct.
Add regression tests for the filename limitations imposed by pax.
MFC after: 3 weeks
pax(1) was trying to copy the back-referenced data from
the match pattern, not the matched data.
PR: bin/118132
Obtained from: Debian bug #451361
Reviewed by: jilles
MFC after: 3 weeks
All the elements of these structs are char anyway, so it won't hurt
performance.
Bump warns back up to the default.
# we likely should have CTASSERTS to make sure they are the right size.
# but with libarchive based tar maybe we shouldn't bother.
symlinks after setting the owner. As a result, mode
and timestamp were not restored. This patch corrects the
problem by simply removing the short-circuit for symlinks
and using lchown()/lchmod()/lutimes() always for restoring
metadata.
PR: bin/91316
Submitted by: Jaakko Heinonen
Reviewed by: Joerg Sonnenberger
MFC after: 14 days
wording makes it look like pax archives > 32256 bytes are not
POSIX-compliant! Correct this to state that pax archives with
block sizes > 32256 are not POSIX compliant...and settle our fears.
PR: docs/97059
Reviewed by: Giorgos Keramidas <keramida>
WRT handling file and link names that reach the allowed
maximum for old tar and ustar archive formats.
PR: bin/40466
Submitted by: Cyrille Lefevre <email in the PR> (portions)
Reviewed by: freebsd-arch (silence)
MFC after: 1 month
rev 1.18, but not documented in the man page) caused a failed chdir.
Otherwise, one can easily overwrite files.
Submitted by: Robert Nagy <robert@openbsd.org>
Obtained from: OpenBSD
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
Instead use %ju and cast the argument.
WFORMAT=0 is still required in the Makefile because gcc warns about
some strftime() calls (I don't think this behaviour is useful.)
Tested on: sparc64, alpha, i386
