If rare conditions such as concurrent conflicting manipulation of the
filesystem occur, fts_read() frees the current FTSENT without adjusting
the pointers in the FTS accordingly. A later fts_close() then frees the
same FTSENT again.
Reported by: pho
Tested by: pho
MFC after: 1 week
* The RFC says (in section 10.1) that only when extbuf is not NULL,
extlen shall be checked, so don't perform this check when NULL is
passed.
* socklen_t is unsigned, so checking extlen for less than zero is
not needed.
Submitted by: swildner@dragonflybsd.org
Reviewed by: Mark Martinec <Mark.Martinec+freebsd@ijs.si>
Reviewed by: hrs
Obtained by: DragonFlyBSD
device is an active kernel console and "off" otherwise. This is designed to
allow serial-booting x86 systems to provide a login prompt on the serial line
by default without providing one on all systems by default.
Comments and suggestions by: grehan, dteske, jilles
MFC after: 1 month
The resolver in libc creates a kqueue for watching a single file descriptor.
This can be done using poll() which should be lighter on the kernel and
reduce possible problems with rlimits (file descriptors, kqueues).
Reviewed by: jhb
As a result, the kernel needs to process shorter pathnames if fts is not
changing directories (if fts follows symlinks (-L option to utilities), fts
cannot open "." or FTS_NOCHDIR was specified).
Side effect: If pathnames exceed PATH_MAX, [ENAMETOOLONG] is not hit at the
stat stage but later (opendir or application fts_accpath) or not at all.
* Set errno to EAFNOSUPPORT if an address is provided which is neither
AF_INET nor AF_INET6.
* Don't modify the arguments.
* Don't smash the stack when provided with a non-zero port.
* Handle the case correctly where the first address provided is
an IPv6 address.
MFC after: 3 days
owning the handle passed to __cxa_finalize() but which are registered
by other dso, when the process is inside exit(3).
Running them makes the destruction order wrong, and there is hope that
such destructors would not call dlclose(3), since it is pointless at
this stage of the process existence.
The change effectively disables the r211706 after the exit(3) is
called.
Reported and tested by: Michael Gmelin <freebsd@grem.de>
Analyzed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
requires process descriptors to work and having PROCDESC in GENERIC
seems not enough, especially that we hope to have more and more consumers
in the base.
MFC after: 3 days
it is all in the one place again. Rename libc/iconv/iconv.c to
bsd_iconv.c. Compile the wrappers into libc.a so that WITHOUT_DYNAMICROOT
works again.
Discussed with: kib (and partly stolen from his patch)
3-clause BSD license as specified by Oracle America, Inc. in 2010.
This license change was approved by Wim Coekaerts, Senior Vice
President, Linux and Virtualization at Oracle Corporation.
when there is an invalid character in the output codeset while it is
valid in the input. However, POSIX requires iconv() to perform an
implementation-defined conversion on the character. So, Citrus iconv converts
such a character to a special character which means it is invalid in the
output codeset.
This is not a problem in most cases but some software like libxml2 depends
on GNU's behavior to determine if a character is output as-is or another form
such as a character entity (&#NNN;).
FreeBSD systems usually implemented this as a third party module and
our implementation hasn't played as nicely with the old way as it could
have.
To that end:
* Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix.
* Provide .symver compatability with existing 10.x+ binaries that
referenced the iconv symbols. All existing binaries should work.
* Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript
at /usr/lib/libc.so.
* Move the "iconv*" wrapper symbols to libc_nonshared.a
This should solve the runtime ambiguity about which symbols resolve
to where. If you compile against the iconv in libc, your runtime
dependencies will be unambiguous.
Old 9.x libraries and binaries will always resolve against their
libiconv.so.3 like they did on 9.x. They won't resolve against libc.
Old 10.x binaries will be satisified by the .symver helpers.
This should allow ports to selectively compile against the libiconv
port if needed and it should behave without ambiguity now.
Discussed with: kib
