- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Change the cap_rights_t type from uint64_t to a structure that we can extend
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)

#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);

bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

cap_rights_t rights;

cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by: The FreeBSD Foundation

Close uniq(1) in the capability mode sandbox and limit descriptors using
capability rights.

Add missing static keywords to uniq(1)

Remove the advertising clause from UCB copyrighted files in usr.bin. This
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

Also add $FreeBSD$ to a few files to keep svn happy.

Discussed with: imp, rwatson

Add SIZE_MAX overflow check

1) Reimplement (differently) unlimited line length restricted in prev.
commit.

2) Honor missing the very last \n (if absent) on output.

Remove vestiges of old %-format which prevents build on amd64

1) Rewrite input processing to not exit with error on the first EILSEQ found
in the input data but fallback to "binary equal" check instead.

POSIX says: "The input file shall be a text file", nothing more,
so the text file with illegal sequence is valid input.
BTW, GNU sort does not fails on EILSEQ too.

2) Speedup input processing a bit in complex cases like skipping fields,
chars or ignore case.

3) Enforce the implied LINE_MAX limit (from POSIX definition of "text file"
and POSIX uniq(1) description).

Sync getline() with comm(1):

- Prevent overflowing of the buffer length variable in getline() by
limiting its maximum value.
- Exit if reallocf(3) fails in getline(). Failure was silently
considered as end-of-file.

Reviewed by: ghelmer
Approved by: trasz (mentor)

The input line length limit mentioned on the manual page was removed by
r176119.

Approved by: trasz (mentor)

Fix truncation of lines at LINE_MAX characters by dynamically
extending line buffers.

PR: bin/76578

Fix typo.

o) Correct for missing whitespace.
o) We don't need to check if ifp == stdin to give the filename, since we already
know that ifn will be "stdin" if it is.

Fix confusing misindentation of a closing-brace. (It goes with the switch, not
with the while.)

Document that uniq(1) limits input line length to LINE_MAX characters.

PR: docs/107578
Submitted by: Jan Schaumann, jschauma.at.netmeister.org
MFC after: 3 days

Added the EXIT STATUS section where appropriate.

Remove a bogus check that caused empty lines not to be counted when the
-c option was given.

Noticed by: sf

Add support for multibyte characters.

Mechanically kill hard sentence breaks.

Document the fact that uniq(1) does not recognize multibyte characters.

Mention the environment variables that affect the execution of uniq.
Of particular interest is the fact that LC_COLLATE affects how uniq
determines whether lines are equal. This was the subject of a fairly heated
debate a year or so ago, and it turns out that the current behaviour is
correct and that the standard contained an error.

Now that the standard has been corrected by Cor. 1-2002, refer to 1003.1-2001
instead of the 1992 edition in the Standards section.

mdoc(7) police: markup polishing.

Approved by: re

ANSIify function definitions.
Add some constness to avoid some warnings.
Remove use register keyword.
Deal with missing/unneeded extern/prototypes.
Some minor type changes/casts to avoid warnings.

Reviewed by: md5

Correct the History section; uniq(1) appeared at least as early as V3.
Move the section to after Standards.

Remove redundant description of input_file and output_file arguments.

Use err instead of errx when malloc fails. "malloc" is not a helpful
error message.

Skip fields in the manner required by POSIX, and the way V7 did it.

MFC after: 1 week

Newline characters should not participate in line comparisons. Only apparent
when -s is used or the last line of the file is missing a newline.
Noticed by the textutils test suite.

MFC after: 1 week

Note that this appeared at least as early as PWB UNIX.

Use the literal string 'PWB UNIX', as we still have no .At macro for it.

Back out rev 1.19 because

1) It breaks uniq for real life languages when "substitute" directive used in
the collating table.
2) It breaks uniq usage in tool chain with other localized utilities which
use collate.
3) To follow LC_COLLATE it is directly allowed for uniq
by POSIX P1003.1 Draft7 (7.3.2). It means that rev 1.19 gains no additional
POSIX conformance.

Compare lines with strcmp(), not strcoll(). We are interested only in
equality, not ordering.

Sync usage() with manual page synopsis.

Accept an input file name of "-" to mean standard input, as required by
P1003.2.

Fields should be separated by <blank>s, not <space>s according to P1003.2.

Don't bother trying to handle "-" arguments ourselves, getopt(3) already
does this for us.

Add the word ``fields'' to the description, and change an instance from
fields to num in the SYNOPSIS

Noticed by: keramida

Reword a small part of the uniq(1) manual page to help reduce word
duplication (ie: fields fields).

PR: 38161
Reviewed by: keramida
MFC after: 3 days

Use LC_ALL to pick collate

Noticed by: tjr

remove __P

WARNS=2 is going to become the default, so remove it from here.

Style improvements recommended by Bruce as a follow up to some
of the recent WARNS commits. The idea is:

1) FreeBSD id tags should follow vendor tags.
2) Vendor tags should not be compiled (though copyrights probably should).
3) There should be no blank line between including cdefs and __FBSDIF.

Warns cleanups. Add FreeBSD ID to Makefile.

mdoc(7) police: utilize the new .Ex macro.

Add DIAGNOSTICS section name

fix fatal typo

toupper -> tolower to match changed behaviour of new grep case fold

Cosmetique: use standard prototypes scheme
Back out prev. change: toupper is more compatible with sort -f

toupper->tolower to match what strcasecmp does

Use strcoll to provide the same results as sort and comm
Use LINE_MAX for max line size (as comm does)

$Id$ -> $FreeBSD$

Grammar nits, double negatives

PR: docs/10491
Submitted By: Tom Hukins <tom@eborcom.com>

Localize it

Teach comm(1) and uniq(1) about an option for case-insensitive work.

PR: 3042
Submitted by: graphix@iastate.edu (Kent Vander Velden)

Use err(3) instead of local redefinition.

compare return value from getopt against -1 rather than EOF, per the final
posix standard on the topic.

This commit was generated by cvs2svn to compensate for changes in r23690,
which included commits to RCS files with non-trunk default branches.

This commit was generated by cvs2svn to compensate for changes in r1590,
which included commits to RCS files with non-trunk default branches.