immediatelly as old code does, now for append modes too.
Real use case for such fallback is impossible (unless specially crafted).
2) Remove now unneded include I forgot to remove in prev. commits.
MFC after: 1 week
The NONE:US-ASCII case isn't necessary. The "NONE:" case will handle
US-ASCII, so let's remove the redundant handling.
Submitted by: marino
Obtained from: DragonflyBSD
The US-ASCII format was getting treated identically to POSIX. It is
supposed to throw an ILSEQ errno if a value of 0x80 or greater is
encountered, so let's bring back the "ASCII" handling.
While here, change nl_codeset to return US-ASCII only when the encoding
really is "US-ASCII". Before "C" and "POSIX" encoding returned this
string, so now they return "POSIX".
Discussed with: ache
Submitted by: marino
Obtained from: DragonflyBSD
as lib/libc/tests/gen
The code in test-fnmatch that was used for generating:
- bin/sh/tests/builtins/case2.0
- bin/sh/tests/builtins/case3.0
has been left undisturbed. The target `make sh-tests` has been moved over
from tools/regression/lib/libc/gen/Makefile to
lib/libc/tests/gen/Makefile and made into a PHONY target
case2.0 and case3.0 test input generation isn't being done automatically.
This needs additional discussion.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
- Remove a leftover printf from when this was a TAP based testcase
- Catch mmap failures properly
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
as lib/libc/tests/net
Also, fix eui64_aton_test:test_str(..). The test was comparing the result
of eui64_aton to a pointer of the expected result.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
provided on amd64, but not i386. Add libm to DPADD/LDADD to unbreak the i386
tinderbox
Pointyhat to: ngie
MFC after: 1 week
X-MFC with: r290538
Sponsored by: EMC / Isilon Storage Division
as lib/libc/tests/stdlib
- Make the code a bit more style(9) compliant
- Convert a sizeof(x)/sizeof(x[0]) to nitems
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
libopenbsd is an internal library which
to bring in compatibility stuff from OpenBSD.
This will allow us to bring in more
OpenBSD utilities into the FreeBSD base system.
We similarly use libnetbsd for bringing in stuff from NetBSD.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D4078
Sorting eucJP text with "sort" resulted in an illegal sequence while
"gsort" worked. This was traced back to mbrtowc handling which was
broken for eucJP (probably eucCN, eucKR, and eucTW as well). This
small fix took hours to figure out. The OR operation to build the
wide character requires an unsigned character to work correctly. The
euc wcrtowc conversion is probably broken upstream in Illumos as well.
Triggered by: misc/freebsd-doc-ja in ports (encoded in eucJP)
Submitted by: marino
Obtained from: DragonflyBSD
The output of "locale charmap" is identical to the result of
nl_langinfo (CODESET) for any given locale. The logic for returning the
codeset was very simplistic. It just returned portion of the locale name
after the period (e.g. en_FR.ISO8859-1 returned "ISO8859-1").
When softlinks were added to locales, this broke. e.g.:
en_US returned ""
en_FR.UTF8 returned "UTF8"
en_FR.UTF-8 returned "UTF-8"
zh_Hant_HK.Big5HKSCS returned "Big5HKSCS"
zh_Hant_TW.Big5 returned "Big5"
es_ES@euro returned ""
In order to fix this properly, the named locale cannot be used to
determine the encoding. This information was almost available in the
rune data. Unfortunately, all the single byte encodings were listed
as "NONE" encoding.
So I adjusted localedef tool to provide more information about the
encoding. For example, instead of "NONE", the LC_CTYPE used by
fr_FR.ISO8859-15 is now encoded as "NONE:ISO8859-15". The locale
handlers now check if the first four characters of the encoding is
"NONE" and if so, treats it as a single-byte encoding.
The nl_langinfo handling of CODESET was adjusting accordingly. Now the
following is returned:
en_US returns "ISO8859-1"
fr_FR.UTF8 returns "UTF-8"
fr_FR.UTF-8 returns "UTF-8"
zh_Hant_HK.Big5HKSCS returns "Big5"
zh_Hant_TW.Big5 returns "Big5"
es_ES@euro returns "ISO8859-15"
as before, "C" and "POSIX" locales return "US-ASCII". This is a big
improvement. The result of nl_langinfo can never be a zero-length
string and it will always exclusively one of the values of the
character maps of /usr/src/tools/tools/locale/etc/final-maps.
Submitted by: marino
Obtained from: DragonflyBSD
Only enable h_raw on x86 targets for today so that a buildworld runs to
completion for clang enabled targets that are not x86. This should be
removed when validation of the sanitizer has occured for all targets
supported by FreeBSD and clang.
as lib/libc/rpc
This testcase requires rpcbind be up in running; otherwise the testcases
will time out and be skipped
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
- Both curitem and curitem (via the names list) was always leaked.
- malloc(3) failures lead to some leaks.
- __bsd___iconv_get_list() failure lead to a crash since its error was not
handles and __bsd___iconv_free_list() is not NULL-safe.
I have slightly refactored this to avoid extra malloc and free logic in cases
of malloc(3) failing.
There are still bad assumptions here that I did not deal with. One of which is
that the data will always have a '/' so the strchr(3) will not return NULL.
Coverity CID: 1130055 1130054 1130053
Libedit's vi mode provides a v command to edit the current line in vi(1)
(hard-coded to vi, in fact).
When Unicode/wide character mode was added, this command started truncating
and/or corrupting the edited text.
This commit fixes v if the text fits into the buffer. If the text is longer,
it is truncated.
PR: 203743
Obtained from: NetBSD (originally submitted by me)
