from
all AAAA trial, then all A trial
to
try AAAA and A for each trial
TODO: more fix for the case where IPv4 mapped IPv6 addr is disabled
Reviewed by: ume
some reason. This will prevent an infinite loop if (say) a sigalarm is
being scheduled at a more frequent interval than the poll timeout.
PR: 2191, 8847, 10553
and gids bigger than 16 bits. Added checks for uids and gids that are
bigger than 32 bits.
Approved by: jkh (partly, this fix is bigger than I first intended)
optimization that generates code our current as doesn't understand.
The result is bad code that damages dynamic symbol locations at
runtime. Ouch. See PR bin/16862 and discussion in -current.
This change will be backed out when gcc and gas are back in sync.
PR: Fixes bin/16862, but not the underlying problem.
Submitted by: bde
Approved by: jdk
-Added more description.
-Many grammer fix.
-Fix hard sentence break.
-Many other man style fix.
Thanks for bde finding out the problem.
Thanks for sheldon for the patient and thorough review.
:-)
Submitted by: bde
Reviewed by: sheldonh
This
This feature allows you to specify if mmap'd data is included in
an application's corefile.
Change the type of eflags in struct vm_map_entry from u_char to
vm_eflags_t (an unsigned int).
Reviewed by: dillon,jdp,alfred
Approved by: jkh
Sorry for the flapping, but no change will be done for 4.0 anymore.
Official standard will be published around April or later.
If different format would be adopted at that time, then support for
the new format will be added to the succeeding FreeBSD 4.x.
Approved by: jkh
run out of KVM through a mmap()/fork() bomb that allocates hundreds
of thousands of vm_map_entry structures.
Add panic to make null-pointer dereference crash a little more verbose.
Add a new sysctl, vm.max_proc_mmap, which specifies the maximum number
of mmap()'d spaces (discrete vm_map_entry's in the process). The value
defaults to around 9000 for a 128MB machine. The test is scaled for the
number of processes sharing a vmspace (aka linux threads). Setting
the value to 0 disables the feature.
PR: kern/16573
Approved by: jkh
fit in the static buffer. This fix causes it to look like there is no
data available, which is also wrong but is better than dumping core.
PR: bin/10344
Reviewed by: billf
Approved by: jkh
-Should not error return when rresvport_af() failed for one of dest
addrs resolved by getaddrinfo().
Should retry until all dest addr fail.
Approved by: jkh
(shortend format, etc)
Current KAME getaddrinfo() supports only d.d.d.d format IPv4
addr. But traditionally inet_aton() and etc support other formats.
(shortend format and octal/deciaml/hex format)
Aboud this,
-As far as the discussion on freebsd-current, many people
think traditional format should also be supported by getaddrinfo().
-X/Open spec requires getaddrinfo() also support those
traditional IPv4 format.
-RFC2553 say nothing about it.
-As the result of confirmation in ietf/ipng list, there is
no clear concensus yet, and the reply was, "RFC2553 update
and X/Open spec will be in sync"
So takeing these conditions into account, I think
getaddrinfo() should also support traditional IPv4 format.
Specified by: Marc Schneiders <marc@oldserver.demon.nl>
Approved by: jkh
KAME scoped addr format is changed recently.
before: addr@scope
now: scope%addr
Because the end of IPv6 numeric addr is tend to be truncated in
`netstat -rn ` output, so placing scope part at starting of addr
will be convenient.
Approved by: jkh
Obtained from: KAME project
of the C++ stdlib. Our ctype.h uses symbols of the form _<X> to denote the
various character classes. Our ctype.h also extends the usual ctype.h
offering by adding the "_T" (special) class. Problem is parts of the STL
also use the symbol "_T" as its parameterized type. These two uses are
incompatible.
Thus change the form of the symbols used in ctype to something that fixes
the current problem and is less likely to cause conflicts in the future.
Requested by: Tomoaki NISHIYAMA <tomoaki@biol.s.u-tokyo.ac.jp>
Ok'ed by: JKH
interface, and statically link them to the programs using them.
These functions, upon reflection and discussion, are too generically
named for a library interface with such specific functionality.
Also the api that they use, whilst ok for private use, isn't good
enough for a libc function.
Additionally there were complications with the build/install-world
process. It depends heavily upon xinstall, which got broken by
the change in api, and caused bootstrap problems and general mayhem.
There is work in progress to address future problems that may be
caused by changes in install-chain tools, and better names for
{g|s}etflags can be derived when some future program requires them.
For now the code has been left in src/lib/libc/gen (it started off
in src/bin/ls).
It's important to provide library functions for manipulating file
flag strings if we ever want this interface to be adopted outside
of the source tree, but now isn't necessarily the right moment
with 4.0-release just around the corner.
Approved: jkh
