PROBLEM:	(CLD MGO102122, QAR 45686)	(Patch ID: OSF375-350217)
********
This patch fixes a memory leak problem that occurs when strxfrm() 
or wcsxfrm() executes in a locale that allows one character to 
substitute for another during collation. 

An example is the de_DE.ISO8859-1 locale, in which "ss" is equivalent to 
and may be substituted for the German sharp s. In such a locale, 
each invocation of strxfrm() or wcsfrm() causes some amount of heap memory 
to be leaked.  When you apply this patch, the memory leak no longer occurs.

PROBLEM:	(QAR 38929)		(Patch ID: OSF375-350217)
********
This patch also fixes some incorrect behavior in the __do_replacement() 
function, which is used by both strxfrm() and strcoll(). Before the fix, 
 __do_replacement() might use the same string pointer for the source 
and destination strings in the strcpy() function.  Results were unpredictable. 
In addition, __do_replacement() did not test the output buffer size to
determine if the resulting string would indeed fit in the output buffer. 

PROBLEM:	(QAR 45694)		(Patch ID: OSF375-350222)
********
This patch fixes a problem in the fnmatch() routine's single-byte 
and multibyte versions, which incorrectly match '?' to a null character.  
As a result, a filename pattern like "???" could match not only a filename 
containing "aaa", but also one containing "a" or "aa".  Because the find 
command uses fnmatch() for filename pattern matching, there is a chance that
data files may be removed unintentionally.  An example is as follows:

 % find . -name 'data???' -exec rm {} \;

This command could inadvertently remove files named "data1", "data10",  
and so forth.

NOTE: The problem fixed by this patch occurs only when you use locales 
      other than the default C locale.

PROBLEM:	(HPAQ46E01)	(Patch ID: OSF375-350236)
********
 sendmail would generate a core dump with a segmentation fault.  

The stripped sendmail does not contain a symbol table so the core dump is 
hard to interpret.  To determine whether this problem exists on your system, 
run the following test: 

(1) On the system being tested, telnet to port 25.  

(2) Enter illegal commands and check whether sendmail generates a core dump.

PROBLEM:	(QAR 46198)	(Patch ID: OSF375-350253)
********
The setlocale() function included in Digital UNIX releases earlier 
than Version 4.0 may sometimes pass a null pointer to the free() function. 

This is not harmful if site applications use the memory allocation package 
 (malloc() and free() functions) bundled in the Digital UNIX C Library. 
However, if site applications use a locally developed memory allocation
package or one included as part of a layered product, passing a null pointer 
to free() may cause the applications to fail. 

To avoid this problem, this patch installs a version of setlocale() 
that checks a pointer for null before passing the pointer to free().

PROBLEM:	(BRO100738)	(Patch ID: OSF375-350279)
********
When testing applications on a BSD-style device such as /dev/tty0h, the
ttyslot function returns a number matching the index into the /var/adm/utmp
file.  However, when running the same program on an SVR4-style device such
as /dev/lat/622, the ttyslot function always returns zero.  The problem can
be indentified easily by running the sample test program included here.

Copy the following program to ttyslot_test.c:

#include <sys/ioctl.h>
#include <stdio.h>
#include <string.h>
#include <utmp.h>

main()
{
        printf("ttyslot() = %d\n", ttyslot());
        exit(1);
}

Error messages may vary, depending on which applications are being run.
When connected to a system over an SVR4-style LAT device the application
calls the ttyslot function to locate the entry in the /var/adm/utmp file.
The ttyslot function returns zero in error because it fails to match the
control terminal.  When you connect to a system over a LAT device and make
a ttyslot function call to locate the entry in the /var/adm/utmp file for
the control terminal of the current process, ttyslot() returns zero in
error because it fails to match the control terminal.

PROBLEM:        (CLD: USG-03550, QAR: 46537)    (Patch ID: OSF375-360053)
********
The problem occurs when a machine has a large number (hundreds) of
"getty" processes running and executes a shutdown.

The machine may take excessively long to shut down (i.e. half an hour).

PROBLEM:	(CLD-00805)	(Patch ID: OSF375-360082-1)
********
A potential security vulnerability has been discovered in BIND
 (Domain Name Service), where under certain circumstances,
system integrity may be compromised.

This may be in the form of improper file or privilege management.

Digital has corrected this potential vulnerability.

PROBLEM:        (QAR 53135, QAR 44398)  (Patch ID: OSF375-350412)
********
This patch fixes a TCP/IP problem that can occur with programs linked
with the libc library.  These programs may return a value of (-1)
when calling the svc_tcp() function.

This problem occurs because a return value, EINTR, is ignored in the
readtcp() and writetcp() functions.  The patch involved checking for
this return before continuing a readtcp() and writetcp().

PROBLEM:        (QAR 54708, CLD MCSM71N73)      (Patch ID: OSF375-350449)
********
The printing of a string with a specified precision could result
in a segmentation fault.

In this case, the C Standard does NOT require a NULL terminated input.

PROBLEM:    (CLDs: TKTQ22519, UVO104025. QAR 45258)  (Patch ID: OSF375-002)
********
Identifying limitations of original date command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The date command was not able to accurately set the date past the year 1999.  

For example:

Display current date:
$ date
Tue Jul 16 11:01:50 EDT 1996

Attempt to set the date to 12:55 PM, January 1, 2000
$ date 0101125500
Thu Feb  7 19:24:02 EST 2036

Enhancements to the date command for Year 2000 support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The date command has been enhanced to support setting the system date
past the year 1999, providing customers with the ability to begin
testing their software for potential century rollover problems.  The
changes are outlined in the following sections.

Syntax

The following formats are valid for setting the system date
using the date command.

o Using the XPG4-UNIX format:

  date mmddHHMM[yy]

o Using one of three Digital formats:

  date mmddHHMM[[cc]yy][.ss]
  date [[cc]yy]mmddHHMM[.ss]
  date mmddHHMM[.ss[[cc]yy]]

The following definitions apply:

mm   is the month number
dd   is the number of the day in the month
HH   is the hour in the day
MM   is the number of minutes
ss   is the number of seconds
yy   is the last two digits of the year
cc   is the first two digits of the year

Note: that the LC_TIME variable, if it is defined, controls the
      ordering of the day (dd) and month (mm) numbers in these formats.  
      The default order is the month (mm) followed by the day (dd).

o Optional Century [cc] Input

Each of the Digital formats for the date command allow the
optional input of the century (first two digits of the year).
This century field is optional to ensure that input formats
previously accepted by the date command are still supported.

Currently, the XPG4-UNIX format mmddHHMM[yy] does not have a
century field.  This is consistent with current X/Open
specifications regarding the date command.  The century field
will be added to this format in a future release of Digital
UNIX once this new field is officially supported in future
revisions of X/Open's UNIX specification.

o Handling of Two-Digit Year Input

When the year is specified by using two digits (as in the
XPG4-UNIX format or when the [cc] field is omitted from the
Digital formats), the century is determined in the following
manner: if the specified two-digit year is between 69 and 99
inclusive, the 20th century is assumed (that is, 19yy),
otherwise the 21st century is assumed (that is, 20yy).

The algorithm above is consistent with current drafts of
forthcoming X/Open UNIX specifications regarding two-digit
year handling in various system interfaces and commands,
including the date command.  This algorithm is based on the
standard UNIX epoch (12:00:00 AM Jan 1, 1970 UTC), minus one
year to account for different time zones.  Internal UNIX time
handling is based on the number of seconds since this epoch.

o Handling of Ambiguous Input

If the input string is ambiguous, that is, if the format
cannot be conclusively determined from the data, the date
command will issue a warning to STDERR and assume the
mmddHHMM[[cc]yy][.ss] format.  To avoid ambiguous input, use
one of the three Digital formats and specify the [cc] field.

Examples

To set the date to 09:34:00 AM Jan 7, 2000:

Using the mmddHHMM[yy] XPG4-UNIX format:

# date 0107093400

Using the mmddHHMM[[cc]yy][.ss] Digital format:

# date 010709342000
# date 0107093400.00
# date 010709342000.00

Using the [[cc]yy]mmddHHMM[.ss] Digital format:

# date 0001070934
# date 200001070934
# date 200001070934.00

Using the mmddHHMM[.ss[[cc]yy]] Digital format:

# date 01070934.0000
# date 01070934.002000

An example of ambiguous input:

# date 0101010000

This input could be recognized as one of the following formats:

mmddHHMM[[cc]yy][.ss]   meaning 01:00:00 AM Jan 1, 2000
[[cc]yy]mmddHHMM[.ss]   meaning 12:00:00 AM Jan 1, 2001

In this case, the date command will display a warning and
assume the mmddHHMM[[cc]yy][.ss] format, setting the date to
01:00:00 AM Jan 1, 2000.

PROBLEM:	(QAR 50276, QAR 53348)	(Patch ID: OSF375-085)
********
This patch fixes a problem in which the 'date' command is unable to
set the date to January 1, 1970 00:00:00 GMT or February 29, 2000.

To reproduce the problem, do the following:

root# TZ=:GMT ; export TZ
root# date 01010000.0070

PROBLEM:	(HPXQ87072, QAR 46521)	(Patch ID: OSF375-360064)
********
This patch allows system managers to both set and obtain quotas
for users and groups which are numeric when using the edquota, vedquota,
quota and vquota programs. It also provides new options to allow them to
specify userids and groupids.

In the past, when the input to these commands was a numeric username or
groupname, the commands would either report that the name couldn't be found,
or would interpret it as the wrong user or group
(when the name coincidentally matched a valid userid or groupid).

For circumstances where the user wishes to specify userid or groupid the
-U and -G options have been added.

This correction also extends the edquota and vedquota prototype
option to allow convenient use of names and ids. In the past a numeric
argument to the "-p" option was incorrectly considered an id, not a name.
Now, the argument to "-p" will always refer to a name while the argument
to the new option "-P" will refer to an id.

Examples

To apply the quotas of user1 to user2, specifying both by their names:
    edquota -p user1name user2name

To apply the quotas of user1 (specified by id), to user2 (specified by id):
    edquota -P user1id -U user2id

Also, note that new versions of the message catalogue files are issued
for each of the programs. These must be updated only if they are on the
system.

PROBLEM:        (GOZ100846)     (Patch ID: OSF375-101)
********
If the server to which an auditd daemon has been configured to send
its audit information becomes unavailable, the local auditd daemon
cpu usage rises dramatically.

PROBLEM:        (QAR 52255,QAR 52836,QAR 55617) (Patch ID: OSF375-110)
********
This patch fixes a problem in which RPC client functions do not correctly
handle system calls interrupted by a signal (EINTR errors).

If a multi-threaded RPC client process catches a signal, a read or write to
an RPC socket can get interrupted, and the RPC operation fails.

PROBLEM:        (QAR 57089)     (Patch ID: OSF375-111)
********
Commands vquota, vedquota, quota, edquota, libc, date, and nslookup will
sometimes display the incorrect error message for non-english locales.


PROBLEM:      (QAR 47388,QAR 51864,QAR 52427,QAR 58881)  (Patch ID: OSF375-152)
********
This patch fixes a problem with the statvfs function.
statvfs returns an incorrect status when the file system is full.

PROBLEM:  (BCGM41776, QAR 63443)    (Patch ID: OSF375-236)
********
This patch fixes a problem with the edquota utility, which prevented a user
from creating quotas for UIDs or GIDs that did not already exist in the
/etc/passwd or /etc/group files.

PROBLEM:  (QAR 59367)    (Patch ID: OSF375-187)
********
This patch adds automatic detection of a cdfs file system for the mount(8) 
command.