Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
It may not do the right thing with these obviously wrong inputs, but at
least it won't smash the stack.
Reported by: Coverity (CWE-120)
CIDs: 1006697, 1006698
Sponsored by: Dell EMC Isilon
Call `Delete(..)` (a free(3) wrapper) on `name` when bailing from the
function.
Submitted by: Tom Rix <trix@juniper.net>
Reviewed by: ngie
Differential Revision: D10097
Sponsored by: Dell EMC Isilon, Juniper
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
and finish the job. ncurses is now the only Makefile in the tree that
uses it since it wasn't a simple mechanical change, and will be
addressed in a future commit.
Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.
Reviewed by: ru
Approved by: philip, ed (mentors)
Some Exchange systems wrap lines over 75 characters long while converting
messages to quoted-printable, preventing ctm_rmail from reassembling
emailed deltas. For a negligible loss of encoding efficiency, this change
allows ctm deltas to once more pass through Exchange undamaged.
for storing the "diff -n" output. Some files (eg ports/INDEX,v) are too
big nowadays to fit on the stack.
Submitted by: Stephen Montgomery-Smith <stephen@math.missouri.edu>
I am the maintainer of CTM. There is a problem that when very large deltas
are created, that the program ctm_smail, which is responsible for mailing
the deltas out, will instead create a single message that says the delta
is too large. However, if the -q option is set, instead of placing this
message in the queue (as it would have done with the deltas), it mails it
out directly. This conflicts with the current working of CTM in that the
email address is set as %%REPLACE-ME%% so that the created mailing pieces
can be signed by gnu-pgp, and then have the mailing address changed.
This fix means that if the -q option is set, and the delta is too large,
the "too large" message is placed in the queue.
Also, I made the "too large" message a little more up to date.
Submitted by: Stephen Montgomery-Smith <stephen@math.missouri.edu>
PR: bin/50328
MFC After: 2 weeks
applying corrupt deltas, but has never (to my knowledge) caught any sort
of corruption, but instead has caused failures on correct deltas several
times. I don't see any way to make the check useful, so it's gone.
Submitted by: Stephen Montgomery-Smith <stephen@math.missouri.edu>
PR: 50461
MFC after: 7 days
hack, thereby allowing future extensions to the structure (e.g., for extended
attributes) without rebreaking the ABI. FTSENT now contains a pointer to the
parent stream, which fts_compar() can then take advantage of, avoiding the
undefined behavior previously warned about. As a consequence of this change,
the prototype of the comparison function passed to fts_open() has changed
to reflect the required amount of constness for its use. All callers in the
tree are updated to use the correct prototype.
Comparison functions can now make use of the new parent pointer to access
the new stream-specific private data pointer, which is intended to assist
creation of reentrant library routines which use fts(3) internally.
Not objected to in spirit by: -arch
umask was less restrictive. This was caused by the use of mkstemp()
which internally passes a mode of 0600 to open(). Fix this by
explicitly chmod'ing the files to (0666 & ~umask).
PR: bin/16119
Submitted by: Sascha Blank <blank@uni-trier.de>
