| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
" changes value from '287948901175001088' to '0' "
.. which turns out is a known issue with later gcc's.
eg - https://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00154.html
It was fixed up upstream corelib/gnulib in commit hash
252b52457da7887667c036d18cc5169777615bb0
(eg in https://github.com/coreutils/gnulib/commit/252b52457da7887667c036d18cc5169777615bb0)
TEST PLAN
- compiled/run for gcc-6.4 on amd64
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D26804
Notes:
svn path=/head/; revision=366765
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of changing the whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and focus on fixing bugs in what we have now,
too many small obstacles we have choicing other way, counting ports.
Corresponding libc changes are backed out in r302824.
Notes:
svn path=/head/; revision=302832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to expand whole range at regcomp() stage as we do,
GNU regex allocates separate ranges [start,end] set each character
is checked against, so collation is possible and turned on for ranges here.
When something like that will be implemented or our obsoleted regex code
will be replaced to something like TRE, and in case we decide to use
collation in [a-z] ranges, all changes related to r302512 can be backed out,
but now we need consistency.
Notes:
svn path=/head/; revision=302780
|
| |
|
|
| |
Notes:
svn path=/head/; revision=251437
|
|
|
Notes:
svn path=/head/; revision=251436
|
