| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
They are useless and don't match the style of the header.
While here adjust the comment with tabs.
Suggested by: kevinlo
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our setpgrp(2) differs from the specified by POSIX, which
only has one argument, and is only meant for compatibility
with BSD.
Reference:
http://pubs.opengroup.org/onlinepubs/009695399/functions/setpgrp.html
Pointed-out in: openbsd-tech (2014-09-16)
MFC after: 6 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've looked at the GCC sources and I now understand what's going wrong.
THe C11 keywords are simply nonexistent when using C++ mode. They are
marked as C-only in the parser. This is absolutely impractical for
multiple reasons:
- The C11 keywords do not conflict with C++ naming rules. They all start
with _[A-Z]. There is no reason to make them C-only.
- It makes it practically impossible for people to use these keywords in
C header files and expect them to work from within C++ sources.
As I said in my previous commit message: GCC is by far the weirdest
compiler that I've ever used.
|
|
|
|
|
|
|
|
|
|
|
| |
As GCC also gained support for the C11 keywords over time, we can patch
up <sys/cdefs.h> to not define these anymore. This has the advantage
that error messages for static assertions are printed natively and that
_Alignas() will work with even a type outside of C11 mode.
All C11 keywords are supported with GCC 4.7 and higher, with the
exception of _Thread_local and _Generic. These are only supported as of
GCC 4.9.
|
|
|
|
|
|
|
|
|
|
|
|
| |
bsearch_b is the Apple blocks enabled version of bsearch(3).
This was added to libc in Revision 264042 but the commit
missed the declaration required to make use of it.
While here move some other block-related functions to the
BSD_VISIBLE block as these are non-standard.
Phabric: D638
Reviewed by: theraven, wollman
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change extends all of the functions present in the <pthread.h> and
<threads.h> headers to have lock annotations. This will allow Clang to
warn about the following:
- Locking a function twice,
- Unlocking a function without a mutex being locked,
- Forgetting to unlock a mutex before returning,
- Destroying or reinitializing a mutex that is currenty locked,
- Using an unlocked mutex in combination with a condition variable.
Enabling these annotations already allowed me to catch a bug in one of
our userspace tools (r270749).
|
|
|
|
|
|
|
|
|
| |
Back in 2011 obrien has added the #define macro in sys/sys/stddef.h to
guard ptrdiff_t. Add similar protection to the identical code in
include/stddef.h.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
MFC after: 1 week
|
|
|
|
| |
Obtained from: ISC
|
|
|
|
|
|
|
| |
While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.
Obtained from: NetBSD (hcreate.c, CVS Rev. 1.7)
|
|
|
|
|
|
|
|
| |
The current ordering of this header is a feature as it
is more consistent with POSIX.
Also adding gratuitous newlines is not elegant.
Pointed out by: bde
|
|
|
|
|
| |
MFC after: 3 days
Obtained from: NetBSD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- In the unionfs case, opendir() and fdopendir() read the directory's full
contents and cache it. This cache is not refreshed when rewinddir() is
called, so rewinddir() will not notice updates to a directory. Fix this
by splitting the code to fetch a directory's contents out of
__opendir_common() into a new _filldir() function and call this from
rewinddir() when operating on a unionfs directory.
- If rewinddir() is called on a directory opened with fdopendir() before
any directory entries are fetched, rewinddir() will not adjust the seek
location of the backing file descriptor. If the file descriptor passed
to fdopendir() had a non-zero offset, the rewinddir() will not rewind to
the beginning. Fix this by always seeking back to 0 in rewinddir().
This means the dd_rewind hack can also be removed.
While here, add missing locking to rewinddir().
CR: https://phabric.freebsd.org/D312
Reviewed by: jilles
MFC after: 1 week
|
|
|
|
|
|
|
| |
Some ports assume GSS-API is supported when they find the headers.
PR: 189156
Submitted by: Garrett Cooper <yanegomi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX.1-2008 specifies that those two functions should be declared by
including <strings.h>, not <string.h> (the latter only has strcoll_l()
and strxfrm_l()):
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcasecmp.html
Obtained from: DragonFlyBSD
Reviewed by: theraven
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CUSE library is a wrapper for the devfs kernel functionality which
is exposed through /dev/cuse . In order to function the CUSE kernel
code must either be enabled in the kernel configuration file or loaded
separately as a module. Currently none of the committed items are
connected to the default builds, except for installing the needed
header files. The CUSE code will be connected to the default world and
kernel builds in a follow-up commit.
The CUSE module was written by Hans Petter Selasky, somewhat inspired
by similar functionality found in FUSE. The CUSE library can be used
for many purposes. Currently CUSE is used when running Linux kernel
drivers in user-space, which need to create a character device node to
communicate with its applications. CUSE has full support for almost
all devfs functionality found in the kernel:
- kevents
- read
- write
- ioctl
- poll
- open
- close
- mmap
- private per file handle data
Requested by several people. Also see "multimedia/cuse4bsd-kmod" in
ports.
|
|
|
|
|
| |
L_cuserid is supposed to be exposed only for old POSIX, or in the default
(expose everything) environment.
|
|
|
|
|
|
|
|
|
| |
or __POSIX_VISIBLE.
Whenever <sys/cdefs.h> sets __BSD_VISIBLE to non-zero, it also sets
__POSIX_VISIBLE and __XSI_VISIBLE to the newest version supported.
No functional change is intended.
|
|
|
|
| |
from the latter.
|
|
|
|
| |
YESSTR and NOSTR are obsolete and are only in old SUS.
|
|
|
|
|
|
|
| |
intended to build with any C compiler.
Reviewed by: pfg
MFC after: 3 weeks
|
|
|
|
|
|
| |
-fms-extensions.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
| |
AppleTalk was a network transport protocol for Apple Macintosh devices
in 80s and then 90s. Starting with Mac OS X in 2000 the AppleTalk was
a legacy protocol and primary networking protocol is TCP/IP. The last
Mac OS X release to support AppleTalk happened in 2009. The same year
routing equipment vendors (namely Cisco) end their support.
Thus, AppleTalk won't be supported in FreeBSD 11.0-RELEASE.
|
|
|
|
|
|
|
|
|
|
|
| |
IPX was a network transport protocol in Novell's NetWare network operating
system from late 80s and then 90s. The NetWare itself switched to TCP/IP
as default transport in 1998. Later, in this century the Novell Open
Enterprise Server became successor of Novell NetWare. The last release
that claimed to still support IPX was OES 2 in 2007. Routing equipment
vendors (e.g. Cisco) discontinued support for IPX in 2011.
Thus, IPX won't be supported in FreeBSD 11.0-RELEASE.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
was approved in 2010 by Wim Coekaerts, Senior Vice President, Linux and
Virtualization at Oracle Corporation.
|
|
|
|
|
|
|
|
| |
Part of VT(9) project merge.
Reviewed by: nwhitehorn
MFC_to_10_after: re approval
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
with the explicit permission of Sun Microsystems in 2009.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
good. This caused libc to spoof the ports libiconv namespace and
provide a colliding libiconv.so.3 to fool rtld. This should have
been removed some time ago.
|
|
|
|
| |
Reviewed by: glebius
|
|
|
|
|
|
|
|
|
|
| |
in net, to avoid compatibility breakage for no sake.
The future plan is to split most of non-kernel parts of
pfvar.h into pf.h, and then make pfvar.h a kernel only
include breaking compatibility.
Discussed with: bz
|
|
|
|
|
|
|
|
|
|
| |
to allow a call of the macro to be labelled as in:
label:
pthread_cleanup_pop();
Reviewed by: imp
MFC after: 3 days
|
|
|
|
|
|
|
| |
only by root can cause install problems, especially over nfs.
Submitted by: jilles@
Approved by: re (gjb)
|
|
|
|
| |
Approved by: re (gjb)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
newvers.sh. Pass it in from include/Makefile. If it isn't passed in,
fall back to the old logic of using dirname $0.
Using dirname $0 does not yield the path to the script if it was
sourced in from another script in another directory; you end up with
the parent script's path. That was causing newvers.sh to look one
level below the FreeBSD src/ directory when building osreldate.h and it
may find something like a git or svn repo there that has nothing to do
with FreeBSD.
PR: 174422
Approved by: re ()
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
This would cause detection of old versions of SVN to cause fatal errors
instead of being caught and handled, which would make the build fail if
the tree had been checked out with an older version of SVN (e.g. 1.6).
Discussed with: gjb
Approved by: re (marius)
|
|
|
|
|
|
|
|
|
|
| |
may come in from the environment and reflect the user's interactive shell.
Using bare "sh" is the dominant pattern in existing makefiles.
MFC this together with r255775.
Approved by: re ()
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
| |
than launching the script directly and relying on #! to launch the shell.
This avoids problems when the source is mounted with the noexec flag.
MFC this together with r255775.
Approved by: re (kib)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
newvers.sh into a temporary subshell with inline make rules.
Using a separate script fixes a variety of problems, including establishing
the correct dependencies in the makefiles. It also eliminates a problem
with the way newvers.sh uses `realpath $0`, because $0 expands differently
within a script sourced into a rule in a makefile depending on the version
of make and of /bin/sh being used. The latter can cause build breakage in a
cross-build environment, and can also make it difficult to compile 10.0 on
older pre-10.0 systems.
PR: 160646 174422
Submitted by: Garrett Cooper <yaneurabeya@gmail.com>
Approved by: re (gjb)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
hrs@ provided this verison of the patch and showed me where all the needed
changes were to be made outside of gpioctl.c
Approved by: re (hrs)
MFC after: 2 weeks
|
|
|
|
|
| |
This broke any C89 ports that defined bool themselves, including things
like gcc, gtk, and so on.
|
|
|
|
|
|
|
| |
function, but returns directory file descriptor instead of closing it.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
Sponsored by: Google Summer of Code 2013
|
|
|
|
|
|
|
|
| |
I removed functionality not proposed for POSIX in Austin group issue #411.
A man page (my own) and test cases will follow in later commits.
PR: 176233
Submitted by: Jukka Ukkonen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extensions and also tried to be link time compatible with ports libiconv.
This splits that functionality and enables the parts that shouldn't
interfere with the port by default.
WITH_ICONV (now on by default) - adds iconv.h, iconv_open(3) etc.
WITH_LIBICONV_COMPAT (off by default) adds the libiconv_open etc API, linker
symbols and even a stub libiconv.so.3 that are good enough to be able
to 'pkg delete -f libiconv' on a running system and reasonably expect it
to work.
I have tortured many machines over the last few days to try and reduce
the possibilities of foot-shooting as much as I can. I've successfully
recompiled to enable and disable the libiconv_compat modes, ports that use
libiconv alongside system iconv etc. If you don't enable the
WITH_LIBICONV_COMPAT switch, they don't share symbol space.
This is an extension of behavior on other system. iconv(3) is a standard
libc interface and libiconv port expects to be able to run alongside it on
systems that have it.
Bumped osreldate.
|
|
|
|
|
| |
These are like mkstemp() and mkstemps() but allow passing open(2) flags like
O_CLOEXEC.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but ACM formula we use have internal state (and return value) in the
[1, 0x7ffffffe] range, so our RAND_MAX (0x7fffffff) is never reached
because it is off by one, zero is not reached too.
Correct both RAND_MAX and rand(3) return value, shifting last one
to the 0 by 1 subtracted, resulting POSIXed [0, 0x7ffffffd(=new RAND_MAX)]
range.
2) Add a checks for not overflowing on too big seeds. It may happens on
the machines, where sizeof(unsigned int) > 32 bits.
Reviewed by: bde [1]
MFC after: 2 weeks
|