piece of historical behavior, not a current bug. Also, while here, add a
bit about disk write-back caches and point to dkctl/scsictl.
Bump date. (first time since 1993!)
which apparently don't exist as instructions, with a sequence of
std / ld instructions.
Also remove the attempted include of ldstm.S which we don't have.
these files use __weak_alias causes build failures under OpenBSD,
because the OpenBSD __weak_alias macro expects the caller to supply a
semicolon, but the NetBSD __weak_alias macro supplies its own semicolon.
Attempt to fix this by avoiding the use of __weak_alias during a tools
build.
Received from OpenBSD via US-CERT as VU #590371.
Original OpenBSD commit log:
> revision 1.42
> date: 2009/02/11 13:24:05; author: otto; state: Exp; lines: +9 -1
> Avoid level going negative on deep (i mean really deep) dirs. Reported
> by Maksymilian Arciemowicz. ok kettenis@ millert@
included in ext_frach, it needs to be masked off when testing for an
infinity value. Fixes the ieeefp/infinity regression test on the 68060
which clears the explicity integer bit when loading an infinity value.
the error value itself - so move it from ASM to NOERR. Pointed out by
Nick. I have no idea how/if this ever could have worked, but I would swear
I realy tested it when I last touched it! Fixes the sys/fs/posix_fadvise
regression test.
when looping over the current list of sockets we're connected to,
use getpeername() not getsockname() to find out who the remote
end is. avoid spurious close()s and (rare) failure.
apparently known as ISC bug #18625, and fixed in libbind 6.0
numeric addresses. The documentation appears to say this works, and some
other systems support it -- more importantly, why should it _not_ work? If
it does not, getaddrinfo() cannot be used as a general-purpose textual to
binary address conversion utility function; yet it is the only such function
we have in the system, since inet_pton() requires a priori knowledge of the
address family.
This change also causes getaddrinfo() with NULL hint (expressly documented
as working) to work properly for numeric addresses.
-since getdevmajor(3) is now binary compatible again with <=5.0
there is no need to rename, I've just left a __getdevmajor50 symbol
temporarily for those who track -current
-update manpage
devmajor_t/devminor_t, as proposed on tech-kern.
This avoids 64-bit arithmetics and 64-bit printf formats in parts
of the kernel where it is not really useful, and helps clarity.
statically initialized _DefaultRuneLocale.rl_wctrans field.
so we can re-const-ify _DefaultRuneLocale.
pkgsrc/shells/standalone-tcsh should be rebuild,
because it's staticaly linked binary.
The problem is that the tm_year field of "struct tm" is just an "int"
(per POSIX), and thus time_t values > 2^31*60*60*24*365 cannot
be converted. This made mktime(3) fail even if no such large time values
were passed in by user code because the algorithm does a binary search
over the time_t range which fails if a probe value cannot be converted.
To fix this, limit the time_t range to be scanned to 55 bits (which
is a bit on the safe side, but still good until y570855533).
This is more a stopgap fix, the overflow should be checked for
at other places as well (eg localtime(3)), and there are some more
limitations in timezone parsing code.
The new rune code abuses __UNCONST to lazily initialize _RuneLocale. If
that happens to be the _DefaultRuneLocale which is const, the program will
core-dump because it will attempt to write to read-only memory. Catch this
and clone a copy of the locale and return it. The reason we don't see
everything core-dumping is because our shared library code probably loads
the text segment COW so it works (Is there an mprotect missing somewhere?).
But on statically linked binaries this is not the case and we die.
XXX[1]: Vet the code so that we are sure that there is no more of that
happening trying to get rid of much of the __UNCONST'ing.
XXX[2]: This needs to be fixed for 5.0 and all related fixes.
XXX[3]: There is one place in the code where _DefaultRuneLocale is treated
specially, does the patch break things?
libnbcompat already contains empty fparseln.lo
so previous fix doesn't work correctly.
i've just added broken fparseln check to configure script.
2. reworking cross build breakage under FreeBSD/MacOS X.
FreeBSD/MacOS X still have public /usr/include/runetype.h
derived from 4.4BSD-Lite. so i renamed out private header from
src/lib/libc/locale/runetype.h to src/lib/libc/locale/runetype_local.h
to solve this problems.
3. fix build breakage when CITRUS=no was set.
ok'ed by core and releng.
(thanks for agc@, snj@ and i'm sorry for long time patience).
[libc]
- localeio.[ch] and lc*.[ch] in src/lib/libc/locale was replaced by
new locale-db implementation using citrus_db backend,
see src/lib/libc/citrus/citrus_lc_*.[ch].
- add citrus_bcs_strtou?l.c. don't use strtou?l locale implementation
internally, because they're locale-aware function.
- add some stubs for multi-locale issue, see {current,global}_locale.c.
- remove some obsolete file, setrunelocale.c, ___runetype_mb.c.
- remove __savectype() from ctypeio.[ch].
[tools]
- mklocale(1): add new option ``-t'' that generates new style
LC_{MONETARY,NUMERIC,TIME,MESSAGES} locale-db format.
- chrtbl(1): added ctypeio.[ch] for __savectype().
[locale-db]
- added en_US.US-ASCII locale.
- removed some shareable locale definition file:
en_US.US-ASCII -> en_US.ISO8859-1, en_US.UTF-8
zh_CN.eucCN -> zh_CN.GB18030
and more...see src/share/locale/*/Makefile.
- remove obsoleted locale sr_YU, added new locale sr_ME, sr_RS.
- change locale name ja_JP.ISO2022-JP* -> ja_JP.ISO-2022-JP*
for X11's locale.alias file alignments.
- fix regression test, wrong wcs?width(3), NAN/INF usage.
i tested release-build following arch:
i386, amd64, hpc{mips,arm,sh}, sparc64, vax.
citrus_lc_*.[ch] also can read old-plain-text style locale-db.
so that backward compatibility is keeped, but lc*.[ch] can't read
new citrus_db'ed locale-db and localeio.c never check sanity,
so forward compatibility is broken ;-<
old mklocale(1) doesn't know -t option, so you have to rebuild toolchain.
I had added a getaddrinfo()/getnameinfo() lookup to obtain an FQDN even
if gethostname() would return only the local part of the hostname.
I did not really consider that many systems do not have FQDNs and more
importantly that the calls introduce a high latency (timeout) when DNS
is not available.
On the other hand I do not (or no longer) think that using a non-FQDN is
such a big problem here. Those users/admins that do collect logs from
different hosts and want an FQDN should notice the problem quickly
enough and can easily fix it by correctly setting their hostname.
