PROBLEM:  (79556) (PATCH ID: OSF445-001)
********


The output string for the swprintf() interface was not NULL terminated.


PROBLEM:  (79876) (PATCH ID: OSF445-023)
********


If the "where" or "t" ladebug command does not show all the currently active
functions, it may be because of this problem. The program being debugged had
to have been built with "split procedures", which is done via options in the
om and spike tools. For spike, split procedures are generated if profiling is
specified. For om, split procedures are generated if profiling AND the
-split_procedure option are specified.

PROBLEM:  (TKTR30011, 78909) (PATCH ID: OSF445-025)
********


If a code segment contained a gmtime() call between calls to tzset(),
or any function specified to call tzset() (such as localtime(), mktime(),
strftime(), etc) , the tzname[0] array could contain erroneous time
zone data referring to the "GMT" zone abbreviation instead of the local
time zone, as specified in the TZ environment variable or default time
zone for the system.

PROBLEM:  (62211) (PATCH ID: OSF445-031)
********


This fix increases the length of the user names for rsh and rexec to allow for
NT interoperabilty.

PROBLEM: (72100, 74961, 75971, 77080,
          77288, 79588) (PATCH ID: OSF445-112)
********
Threaded applications which make extensive use of synchronization objects
(mutexes, condition variables) may encounter performance and scaling
regressions when run on some EV6 SMP machines.  Customers encountering
these regressions may observe negative scaling, decreased application
throughput and increased CPU utilitzation, as the number of EV6 CPUs
is increased.  This version of DECthreads contains changes to the
implementation of synchronization objects and thread scheduling around
those objects to improve performance on all SMP systems.  No functional
or interface changes were made.


PROBLEM: (BCSM807S5) (PATCH ID: OSF445-108)
********
Some applications assume that initial allocations of memory from the C
run-time library's malloc() function will return zero-filled memory. The
problem is that malloc() and free() often write into the first 16 bytes of
the allocated memory.
This change to malloc() zeros out the first 16 bytes in the allocated memory.
The result is that memory allocated prior to any call to free() -- and prior
to any other run-time library function that might call free -- should be zero
filled.