Refactoring done in r317703 broke -c, -l, and -L flags implying
suppression of match printing. Fortunately this is just a matter of not
doing any printing of the resulting matches and context printing was not
broken in this refactoring.
Add some regression tests since this area may still see further
refactoring, include different context flags as well even though they
were not broken in this case.
PR: 219077
Submitted by: Kyle kevans91@ksu.edu
Reported by: markj
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10607
-w flag matching with an empty pattern was generally 'broken', allowing
matches to occur on any line whether or not it actually matches -w
criteria.
This fix required a good amount of refactoring to address. procline()
is altered to *only* process the line and return whether it was a match
or not, necessary to be able to short-circuit the whole function in case
of this matchall flag. -m flag handling is moved out as well because it
suffers from the same fate as context handling if we bypass any actual
pattern matching.
The matching context (matches, mostly) didn't previously exist outside
of procline(), so we go ahead and create context object for file
processing bits to pass around. grep_printline() was created due to
this, for the scenarios where the matches don't actually matter and we
just want to print a line or two, a la flushing the context queue and
no -o or --color specified.
Damage from this broken behavior would have been mitigated by the fact
that it is unlikely users would invoke grep -w with an empty pattern.
This was identified while checking PR 105221 for problems it this may
cause in BSD grep, but PR 105221 is *not* a report of this behavior.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Differential Revision: https://reviews.freebsd.org/D10433
Work in progress (D10315) is going to make egrep_empty_invalid an
actually invalid regex, to be consistent with the equivalent BRE "{"
behavior, when using regex(3).
Any non-0 exit value is acceptable, depending on how the installed grep
interprets the expression. GNU grep interprets it as non-matching, and
in the future BSD grep will interpret it is an error.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10572`
-w and -v flag matching was mostly functional but had some minor
problems:
1. -w flag processing only allowed one iteration through pattern
matching on a line. This was problematic if one pattern could match
more than once, or if there were multiple patterns and the earliest/
longest match was not the most ideal, and
2. Previous work "fixed" things to not further process a line if the
first iteration through patterns produced no matches. This is clearly
wrong if we're dealing with the more restrictive -w matching.
#2 breakage could have also occurred before recent broad rewrites, but
it would be more arbitrary based on input patterns as to whether or not
it actually affected things.
Fix both of these by forcing a retry of the patterns after advancing
just past the start of the first match if we're doing more restrictive
-w matching and we didn't get any hits to start with. Also move -v flag
processing outside of the loop so that we have a greater change to match
in the more restrictive cases. This wasn't strictly wrong, but it could
be a little more error prone.
While here, introduce some regressions tests for this behavior and fix
some excessive wrapping nearby that hindered readability. GNU grep
passes these new tests.
PR: 218467, 218811
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10329
The test suite currently lacks basic sanity checks to ensure that egrep,
fgrep, and grep are actually matching the right expression types, i.e. passing
the right flags to regcomp(3). Amend the test suite to make sure that not only
are the individual versions doing the right thing, but also that we don't have some
kind of frankenregex situation happening where egrep is accepting a BRE or
grep an ERE.
I've chosen to not expand the 'basic' test but to add the 'grep_sanity' checks
to their own test case since this is testing for more than just 'grep matches things',
but actual expression types.
Differential Revision: D10444
Reviewed by: emaste, ngie
Submitted by: Kyle Evans <kevans91@ksu.edu>
Tested with: bsdgrep, gnu grep (base, ports)
Sponsored by: Dell EMC Isilon
They're no longer needed after recent fixes made to bsdgrep(1).
Submitted by: Kyle Evans <kevans91@ksu.edu> (via a previous diff in D10433)
Sponsored by: Dell EMC Isilon
r316477 broke zero-length matches when not using the -o flag, by
skipping over them entirely.
Add a regression test so that it doesn't break again in the future.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reviewed by: cem emaste ngie
Differential Revision: https://reviews.freebsd.org/D10333
Create additional tests to cover regressions that were discovered by
PRs linked to reviews D10098, D10102, and D10104.
It is worth noting that neither bsdgrep(1) nor gnugrep(1) in the base
system currently pass all of these tests, and gnugrep(1) not quite being
up to snuff was also noted in at least one of the PRs.
PR: 175314 202022 195763 180990 197555 197531 181263 209116
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reviewed by: cem, ngie, emaste
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10112
Restore the stock (upstream) code under an #else block, so it's easier
for me to visualize and understand the code that needs to be upstreamed.
MFC after: 2 months
X-MFC with: r316178, r316179, r316180
Sponsored by: Dell EMC Isilon
msgsnd(2)'s msgsz argument does not describe the full structure, only the
message component.
Reported by: Coverity
CIDs: 1368703, 1368711
Sponsored by: Dell EMC Isilon
msgsnd's msgsz argument is the size of the message following the 'long'
message type. Don't include the message type in the size of the message
when invoking msgsnd(2).
Reported by: Coverity
CID: 1368712
Sponsored by: Dell EMC Isilon
This is no longer required as of r315616, as the test is no longer
built/installed.
This is being done to diff reduce with NetBSD.
Sponsored by: Dell EMC Isilon
Add a clock_nanosleep() syscall, as specified by POSIX.
Make nanosleep() a wrapper around it.
Attach the clock_nanosleep test from NetBSD. Adjust it for the
FreeBSD behavior of updating rmtp only when interrupted by a signal.
I believe this to be POSIX-compliant, since POSIX mentions the rmtp
parameter only in the paragraph about EINTR. This is also what
Linux does. (NetBSD updates rmtp unconditionally.)
Copy the whole nanosleep.2 man page from NetBSD because it is complete
and closely resembles the POSIX description. Edit, polish, and reword it
a bit, being sure to keep any relevant text from the FreeBSD page.
Reviewed by: kib, ngie, jilles
MFC after: 3 weeks
Relnotes: yes
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D10020
The reasoning for this is the same as r276046: to ease MFCing the tests
to ^/stable/10 .
This was accidentally missed in r313439
MFC after: 1 week
X-MFC with: r313439
Sponsored by: Dell EMC Isilon
This function allows the caller to specify the reference clock
and choose between absolute and relative mode. In relative mode,
the remaining time can be returned.
The API is similar to clock_nanosleep(3). Thanks to Ed Schouten
for that suggestion.
While I'm here, reduce the sleep time in the semaphore "child"
test to greatly reduce its runtime. Also add a reasonable timeout.
Reviewed by: ed (userland)
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D9656
There are some potential issues with the test (as brd@ has pointed out
elsewhere) with precision, etc not being set before the test, but as
always, more research is required.
The docs and the behavior mismatch; as noted in the bug, the behavior
for hsearch_r matches Linux, whereas the docs seem to match NetBSD
requirements wise.
PR: 216872
It was used for nitems, but I converted it to __arraycount later, and
is already pulled in by header pollution on FreeBSD as well as NetBSD
ala sys/cdefs.h
unlinking them at the beginning of the testcase
This is a lot more intelligent in cleaning up the semaphores if the testcase
fails before sem_unlink is called.
Contributed back as bin/51872 upstream.
