Replace use of driver_send_term() with erl_drv_send_term()
Replace use of deprecated functions in test cases

driver_send_term() replaced by erl_drv_send_term().
driver_output_term() replaced by erl_drv_output_term().
Fix documentation
Add 'port_count' and 'port_limit' to system_info/1 spec
Add workaround for CentOS/RedHat writev bug to inet_drv
Clean up and make the fix work on windows.

Thanks to Tony Rogvall.
Report spec discrepancy on mismatching lists

This patch enables Dialyzer to detect cases where a function has a specification
for a return type containing some list with elements different than the ones
Dialyzer's own algorithm can infer e.g. a function specified to return [atom()]
when actually [[atom()]] is returned.

Previously Dialyzer remained silent, under normal operation, seeing that these
two types have the empty list as a common element, so they were not 'completely
irrelevant'.
Change proposed scheduler wakeup strategy to be the default
Add +stbt erl command line switch
make/fakefop: adapt to make/otp.mk.in changes
make/fakefop: update copyright years
make/fakefop: do not report what file is written
make/fakefop: slightly change placeholder text
make/fakefop: repair pdf structure and make content static
Use share flags for all file operations on Windows

Some file operations provided by the Erlang file module
didn't open the target file with all the file share flags.
This made some concurrent file operations against the
same file fail on Windows, while on other platforms such
as GNU/Linux or Mac OS X they succeed. The operations will
fail only if they're performed concurrently by different
threads (async IO threads or scheduler threads).

For example, one Erlang process does a file:delete/1 call
while another Erlang process is doing a filelib:file_size/1
call. This made the former process get an eacces error from
the file:delete/1 call. On GNU/Linux or Mac OS X the call would
succeed. Another example is if one Erlang process attempts to
open a file for reading while another one is in the middle of
a file:read_file_info/1 call (after it opened the file and
before it closed the file).

It's easy to verify that if a file is not open with all the
share flags, it's impossible for other threads (even if they
belong to the same OS process) to open the file while the
file is not closed by the first thread.
The following test program shows this:

 #include <windows.h>
 #include <iostream>

// Must be an existing file
//#define SHARE_FLAGS (FILE_SHARE_READ)

static DWORD WINAPI MyThreadFunction(LPVOID lpParam);
static char *lastError();

int main(int argc, char *argv[])
{
    DWORD   threadId;
    HANDLE  threadHandle, hFile;

    hFile = CreateFile(FILENAME, GENERIC_READ, SHARE_FLAGS, NULL,
                       OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        std::cerr << "File open error from main: " <<
		lastError() << std::endl;
        return 1;
    }
    std::cout << "Main thread opened file successfully" << std::endl;

    threadHandle = CreateThread(NULL, 0, MyThreadFunction, NULL, 0, &threadId);
    if (threadHandle == INVALID_HANDLE_VALUE) {
        std::cerr << "Thread create error from main: " <<
		lastError() << std::endl;
        return 1;
    }
    WaitForSingleObject(threadHandle, INFINITE);
    CloseHandle(threadHandle);
    CloseHandle(hFile);
    return 0;
}

static DWORD WINAPI MyThreadFunction( LPVOID lpParam )
{
    HANDLE hFile;

    hFile = CreateFile(FILENAME, GENERIC_READ, SHARE_FLAGS, NULL,
                       OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        std::cerr << "File open error from second thread: " <<
		lastError() << std::endl;
        return 1;
    }
    std::cout << "Second thread opened file successfully" << std::endl;
    CloseHandle(hFile);
    return 0;
}

static char *lastError()
{
    static char *buf = NULL;
    DWORD dw = GetLastError();

    if (buf != NULL) {
        LocalFree((LPTSTR) &buf);
    }
    FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM |
                  FORMAT_MESSAGE_IGNORE_INSERTS,
                  NULL, dw, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                  (LPTSTR) &buf, 0, NULL);
    return buf;
}

Rnning this program with SHARE_FLAGS set to 0 (as efile_fileinfo()
does for e.g.), shows that the second thread is unable to open the
file:

    C:\cygwin\home\fdmanana\tmp>touch foo.bar
    C:\cygwin\home\fdmanana\tmp>threads_fopen_test.exe
    Main thread opened file successfully
    File open error from second thread: The process cannot access the
    file because it is being used by another process.

Changing the program's SHARE_FLAGS to FILE_SHARE_READ, shows that
both threads are able to open the file:

    C:\cygwin\home\fdmanana\tmp>touch foo.bar
    C:\cygwin\home\fdmanana\tmp>threads_test.exe
    Main thread opened file successfully
    Second thread opened file successfully

Same logic applies to opening files for writing or deleting and
renaming files while they're open by some other thread that didn't
specify the flags FILE_SHARE_WRITE and FILE_SHARE_DELETE.
compiler: Eliminate internal consistency failure in binary matching

The following code:

  check(<<"string">>, a1) ->
    one;
  check(_, a2) ->
    two;
  check(undefined, a3) ->
    three.

produces an internal consistency failure:

  check: function check/2+17:
    Internal consistency check failed - please report this bug.
    Instruction: {test,is_eq_exact,{f,7},[{x,0},{atom,undefined}]}
    Error:       {match_context,{x,0}}:

Actually, in the current implementation of the run-time system,
comparing a match context to an atom is safe, so I briefly considered
updating the beam_validator to let this code pass through. I
abandoned that approach because not all terms would be safe to
compare to a match context, and the implementation might change
in the future.

Therefore, fix this problem by not allowing any matching of non-variables
(in the argument position for binary being matched) following binary
matching. That solution is simple and safe, and since this kind of
code seems to be rare in practice, there is no need to pursue any
more compilicated solution.

Reported-by: Viktor Sovietov
Add search to Erlang shell's history

Search mode can be entered by pressing ctrl-r. Enter terms and press
ctrl-r again to search backwards, or ctrl-s to then search forward (if
you terminal doesn't eat up that one). Press enter to execute the line,
or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to
exit search mode while remaining on the last found line. Exiting is also
possible by pressing the escape key twice.

The search mode is a simpler version of the one available in bash or
zsh shells.

This adds a few modes to the shell (search, on top of none and meta) in
group.erl for history search, and a few more in edlin.erl to change the
meaning of control sequences while searching.
Use async threads by default
Raise default reader group limit to 64
handle_pref_algs with correct return values