Patch Name: PHCO_24148

Patch Description: s700_800 11.00 libc cumulative patch

Creation Date: 01/05/25

Post Date: 01/06/15

Hardware Platforms - OS Releases:
	s700: 11.00
	s800: 11.00

Products: N/A

Filesets:
	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	ProgSupport.PROG-AX-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP

Automatic Reboot?: No

Status: General Release

Critical:
	Yes
	PHCO_24148: CORRUPTION ABORT
	PHCO_13283: CORRUPTION

Category Tags:
	defect_repair general_release critical halts_system
	corruption

Path Name: /hp-ux_patches/s700_800/11.X/PHCO_24148

Symptoms:
	PHCO_24148:
	M_BLOCK behavior for malloc not working correctly.
	JAGad55731; 8606186527

	mallinfo(3C) doesn't give correct memory statistics if the
	application is multithreaded and uses multiple arenas.
	JAGad34660; 8606165366

	ptsname corrupts heap SIGBUS may result.
	JAGad46861; 8606177629

	When  environment  variable  TZ is not  set,  the  variables
	tzname[2]   and  timezone  is  set  to  hard  coded   values
	corresponding to Eastern Standard Time.
	JAGab20870;

	valloc  fails  when  memory   available   in   multithreaded
	application.
	JAGad47526; 8606178299

	New feature  and not a defect.  Initialized  TLS  support in
	libc
	JAGad49168; 8606179946

	fstyp returns  "unknown_fstyp" on VxFS version 4 disk layout
	file system
	JAGad57721; 8606188513

	strncasecmp()  behaves  differently  with libc  patches  for
	S-Chinese locale
	JAGad66064; 8606196866

	Trusted  system  calls made on an 11.0 NIS  system  causes a
	SIGSEGV core dump.
	Using  "dns" as a source for  databases  other than  "hosts"
	causes a SIGSEGV core dump.
	JAGad41604; 8606172344

	PHCO_23770:
	For those  PA-32bit  Threaded C Applications  which uses C++
	plugins     and     pthread/cma      calls     in     static
	constructor/destructor,  may happen that destructors will be
	called twice.  Non-threaded  PA-32 bit  applications  do not
	have this problem.
	JAGad55189; SR 8606185984

	PHCO_22923:
	No externally supported method to pthread safe dynamically
	loaded libs.
	JAGab69119; SR 8606102984

	User  cannot use C++ runtime  library on 32 bit  application
	without either using a C++ main program or explicitly invoke
	the C++ runtime  library's  initialization  routine,  _main,
	from  the C ( or  Fortran  ) main  program.
	JAGad41440; SR 8606172179

	gettimeofday is very slow for certain vendors who use it for
	time stamping.
	JAGad44410; SR 8606175166

	Global symbols in libc can conflict with one in program
	causing SIGBUS.  Customer can experience this problem if
	he/she uses his/her own global variable "alpha".  It is very
	likely that customers can have alpha as their global
	variable.
	JAGad33756; SR 8606164457

	sigwait() does not work as cancellation  point if the thread
	is cancelled after it enters __sigwait_sys().
	JAGad39745; SR 8606170481

	memmove() failing for data near to a quadrant boundary.
	JAGac87878; SR 8606129543

	regcomp(3C)  function  fails to detect an  extended  regular
	expression  match  in  the  input  data.For  example,If  the
	pattern is "%|^xyz"  and the string is te%st, it gives Found
	No Match.
	JAGad31456; SR 8606162140

	seekdir core dumps when compiled with -z option
	JAGac78889; SR 8606128089

	Purify reports "Uninitialized Memory reads" in readdir_r
	JAGac95112; SR 8606130241

	Trying to access the freed memory in  closedir.c  is causing
	the core dump.
	JAGad21880; SR 8606152550

	snprintf() does not handle length of zero properly.
	JAGad12471; SR 8606143128

	regerror() may dump core for some values of error code
	JAGad02475; SR 8606133330

	PHCO_22314:
	Data corruption in large malloc.
	JAGad25621; SR 8606156311

	strftime() to slow in multi-threaded applications
	(On V-class systems).
	JAGac86555; SR 8606129009

	JFS 3.3 commands  compiled with a libc stub for acl() system
	call fail on files  larger  than 2GB.  This was  particulary
	noted in setacl and getacl commands,  however any command or
	user  compiled  program  using acl() could be affected.  The
	error code returned is EOVERFLOW.
	JAGad09568; SR 8606140246

	sed(1) hangs in non-C locale for some patterns.
	awk sub pattern does not work well under non-C locales.
	JAGad05149,JAGac56665; SR 8606136018,8606126100

	When the system runs out of memory, call to regcomp(3C) will
	result in bus error.
	JAGad03415; SR 8606134279

	Calling the getgrent or getpwent repeatedly causes core dump
	with  SIGBUS  error  when  there is no  nsswitch.conf  file.
	JAGad11220; SR 8606141866

	strncat truncates string.
	JAGad16345; SR 8606147002

	PHCO_22076:
	The default resolver configurable timeout is large
	(5 Seconds). VUE may take a long  time to come up when
	the  system  is not connected to network.
	JAGaa27175; SR 5003424531

	PHCO_20765:
	Fork fails for threaded applications when an older
	pthread library (11.00 LR) is installed on the system.
	JAGac40398; SR 8606125006

	Threaded programs using third-party mallocs abort.
	JAGac40401; SR 8606125009

	Unsupported mixed dependencies on both archive and
	shared libc fail.
	JAGac40402; SR 8606125010

	Sporadic valloc failure in threaded applications.
	JAGac40711; SR 8606125320

	Multi-threaded applications that create threads
	sequentially encounter excessive process memory growth
	and malloc() failure even when the process heap has
	plenty of free memory.
	JAGac40903; SR 8606125513

	PHCO_20763:
	This is a SP patch version of PHCO_20765.

	PHCO_20555:
	system() is slow in multi-threaded applications,
	possibly leading to unusable systems due to swapping
	activity if called from large 64bit processes.
	JAGab78389

	sigaction() called from a signal handler in a multi-
	threaded application can result in hangs.
	JAGab81794

	In applications using large malloc, malloc can return
	an invalid quad 2 "buffer" that overlays the stack,
	resulting in stack corruption.
	JAGab72262

	Excessive static data for arenas and arena mutexes.
	JAGaa14937

	Inadequate statistics reporting to meet partner needs.
	JAGaa26400

	dirname(3c) causes application death (bus error) due
	to segmentation violation.
	JAGaa62439

	Multithreaded programs deadlocks if they invoke
	popen(3C) and fork(2) in different threads.
	JAGab77826; SR 8606107568

	regcmp(3C) call might fail on 64-bit on if the regular
	expression is huge.
	JAGab71463; SR 8606104124

	VxFS ACL fails with large UID's/GID's (>=0x80000).
	Once the file has one such entry in its ACL list, any
	subsequent acl operations return "Invalid Argument"
	error:

	[ aldan:/mnt ] (90) touch TEST
	[ aldan:/mnt ] (91) setacl -m user:12345678:r-- TEST
	[ aldan:/mnt ] (92) getacl TEST
	acl failed for file "TEST", Invalid argument
	JAGab76091 JAGab76238; SR 8606106738

	Core dump may occur when domain-name is not found in
	the search list specified.
	JAGab72180

	A large number of threaded applications invoking
	getXXbyYY calls on a MT system and running simultaneously
	may hang, when the file table overflows.
	JAGab82346

	rpc calls invoking dns backend will not function
	properly with the new dns backend library libnss_dns.1.
	As a result applications using rpc like CDE and NFS will
	not function properly .
	JAGab68997

	The host address type in the returned hostent structure
	was not being set to correct value when IP address was
	being passed to gethostbyname call.
	JAGab71977

	TZ env var (STD#DST,date1,date2) ignores DST if date1
	greater than date2
	JAGab75719; SR 8606106516

	Under some offset, destination string lengths, and counts
	beyond the terminating null in the source string strncat
	can move fewer than the required number of bytes.
	JAGab84233

	PHCO_20369:
	This is an SP patch version of PHCO_20555.

	PHCO_19691:
	strptime()/mktime() dumps core  for the years
	beyond 2038 when compiled with -z(do not bind
	anything to address zero) option.
	JAGab72590; SR 8606104837

	1. ctype(3C) routines are too slow and the macros
	have too many instructions because they contain
	function calls.
	2. The performance of singlebyte applications using
	the ctype routines needlessly degrades in multibyte
	locales.
	3. strcasecmp(3C) and strncasecmp(3C) are too slow
	compared to other vendors because they rely on
	_tolower(3C) which is a macro mapped to a function
	call.
	JAGaa43050 JAGaa05164

	mktime() does not seem to adjust for change in TZ
	variable.
	JAGaa44810; SR 5003444117

	strptime(3C) returned NULL when processing the date
	string generated by the command "date +%x" for locales
	zh_TW.ccdc and zh_TW.big5.
	JAGaa08262 JAGaa47278

	When calling strncmp with one valid string pointer,
	a null pointer and a length of zero strncmp will return
	the first charater or the negative of the first
	character of the valid string instead of an expected zero.
	SR 5003463463

	If the comparison character for memchr is a negative
	integer memchr will not find the match.
	JAGaa93243

	Strrstr(s1, s2) sometimes claims that a match is found
	when actually there is no match. Consider an example.
	s0 = "ABCDEFG";
	s1 = s0;
	s1 ++; /* s1 points to "BCDEFG" */
	s2 = "ABCDEFG".
	Now strrstr(s1, s2) returns "ABCDEFG", which means
	that a match is found.  It should have returned NULL.
	JAGaa41142

	When attempting to assemble using a 9.X assembler the
	assembler complains about unknown syntax.
	JAGaa62460

	64-bit regexec(3C) returns with large positive numbers
	assigned to pmatch[i].rm_eo, and may cause applications
	coredump.
	JAGaa46130

	An internationalized application leaks memory at every
	setlocale() call to change its locale environment.
	JAGaa06047

	An internationalized application which frequently calls
	setlocale() to change its locale environment encounters
	a serious performance problem.
	JAGaa08086

	A multi-threaded internationalized application fails
	in setlocale() for the restore operation using the buffer
	returned by the previous call to setlocale().
	JAGaa32025

	memcmp() could return an incorrect result if the third
	parameter to memcmp was a negative value.
	JAGaa24067

	VxVM pathnames not recognized by blocktochar()
	JAGab69351; SR 8606103064

	Linking with libc.sl can produce a slower running
	application than linking with libc.a.
	JAGab15584 JAGab16669

	strtod("NaN",ptr) on HPUX 11.0 returns a ptr past the '\0'
	JAGaa05185; SR 4701389726

	glob(3C) cannot handle more than one trailing
	'/' in a path string.
	JAGaa94846; SR 1653297432

	strxfrm does not work correctly for positional
	forward and backward single as well as multi
	byte locales.
	JAGaa95471

	The getcwd() API is slow and accesses remote
	filesystems unnecessarily when there is a mount
	point on the path to the current directory.
	JAGaa01123, JAGaa40237

	The contents of the struct utmp is NULL when end
	of file /etc/utmp is reached, but the struct utmp
	should contain the last utmp entry.
	JAGaa05209

	NaN and Infinity were printed incorrectly in case of
	long double.
	JAGaa86217

	Poor multithreaded malloc performance, primarily
	caused by mutex contention and mutex locking overhead.
	Incorrect malloc statistics. Inadequate statistics
	reporting capability.  64-bit multiarena malloc aborts
	when user specifies _M_ARENA_OPTS.
	JAGaa40240, JAGaa01969, JAGab19981, JAGab16523, JAGab43915
	JAGaa26400, JAGab43837, JAGab53676, JAGab19980

	regexec() finds for "." in empty string "" with
	locales other than C.
	JAGaa53114; SR 4701413906

	PHCO_19491:
	Pre-enable additional filesystem type recognition.
	JAGab68821; SR 8606102818

	PHCO_19391:
	Multithreaded applications hangs if one of the threads
	vforks and does an exec(2) call (except the execve(2)
	call).

	Memory leak in applications using vfork and exec(2)
	calls except execve(2) calls.
	JAGaa55615

	version 4, JFS ACL support is enabled within VxFS.
	The libc patch is to create new APIs for JFS ACL,
	and update existing ACL related interfaces in libc
	aware of the new acl type, JFS ACL.
	JAGaa95281; SR 4701420935

	JFS 3.3 release introduces a new VxFS disk layout,
	version 4.  The new disk layout is used to support
	JFS ACL, JFS Clone FS feature, and has an enhanced
	fsadm shrink capability.  The libc patch is to make
	JFS related interfaces in libc aware of the new disk
	layout.
	JAGaa95281; SR 4701420935

	PHCO_19090:
	If atoi() is passed a string containing a character with
	code value greater than 127 (\x7f), the wrong answer may
	be returned using a 32-bit libc or there may be a
	coredump with a 64-bit libc.
	JAGab25446, JAGaa05164; SR 8606100279

	PHCO_18227:
	When a process is in the kernel and receives a self-sent
	SIGABRT signal via abort(3C), the contents of the callee
	save registers are undefined. This causes DDE unable to
	unwind the core file generated by abort(3C).
	JAGaa43927; SR 5003443143

	strftime(3C) returns week number 52 for 12/27/1999-
	12/31/1999 and 53 for 1/1/2000-1/2/2000.
	JAGaa46298

	malloc is slow for multi-threaded applications.
	JAGaa32680

	Strcoll performance very bad compared to that of 9.x.
	JAGaa00524; SR 1653214346

	Strcoll failure.  Single byte locales did not collate
	properly when an old version of single byte locale (using
	multi-byte routines for single byte locales) is used with
	new version of libc (where single byte routines are used
	for single byte locales). The original change was made in
	10.10.
	JAGaa18768, JAGaa18769

	libcres--new library : Applications that have statically
	linked with libc can experince core dumps if libc.sl
	changes internal call graphs.
	JAGaa43395

	mkfs(hfs) can't handle VxVM volume pathnames
	JAGaa42843

	memchr() perf improvement: memchr() does not perform
	well when static branch prediction is enabled.  memchr()
	causes stack overflow problems for large values of
	length. memchr does 64 bit compare operations on
	32 bit operands.
	JAGaa13890, JAGaa41248

	mktime(3C) sets tm_isdst to 0 when daylight savings
	is in effect for dates past Tuesday January 19 03:14:07
	UTC 2038.  Since strptime(3C) obtains this value from
	mktime(), it also returns the 0 for tm_isdst when daylight
	savings is in effect for those dates.
	JAGaa16206, SR 4701405688, JAGaa23230 SR 4701405696,
	JAGaa23233 SR 4701405720

	strptime() does not check for dates not within the
	supported range of Friday December 13 20:45:52 UTC 1901
	and Friday December 31 23:59:59 UTC 9999.
	JAGaa23231 SR 4701405704, JAGaa23232 SR 4701405712

	In 64-bit HP-UX, getdate(3C) does not check for
	dates not within the supported range of Friday December
	13 20:45:52 UTC 1901 and Friday December 31 23:59:59 UTC
	9999.
	JAGaa26931 SR 4701409581

	PHCO_18103:
	64-bit applications may dump core when attempting to
	use getcwd(3C).
	JAGaa95447

	PHCO_17601:
	Excessive locking of /etc/mnttab in the getmntent(3X)
	family of APIs can cause a deadlock.
	JAGaa01122, JAGaa01628

	On a 64bit system strlen() returns incorrect values
	when the lower 32 bits of address are a zero.
	JAGaa93445; SR 4701418293

	For a week which contains days in the previous year
	and the new year, strftime(3C) with %V returns week
	number 53 for those days in the new year if they are
	less than 4 days in the new year in that week,
	regardless of whether the last week of the previous
	year is 52 or 53; otherwise, it returns 1.  It returns
	either 52 or 53 for those days in the previous year.
	This result in two different week numbers for days in
	the same week for certain years.
	JAGaa62691

	An internationalized application leaks memory at
	every setlocale() call to change the locale environment
	(The query operation doesn't leak the memory).
	JAGaa92941; SR 1653294694

	getpwnam() returns wrong values sometimes, making
	the system unreliable.
	JAGaa46458, JAGaa72866; SR 1653284414

	getcwd does not handle Loop Back File Systems (LOFS)
	correctly.
	JAGaa86037; SR 4701414862

	PHCO_16629:
	memcmp(3C) returns incorrect values when compiled
	with +DA2.0N.  memcmp, memchr, strncat do 64 bit
	compare opearations on 32 bit operands.
	JAGaa41144, JAGaa41248; SR 5003438507

	malloc performance is very slow.
	JAGaa17260

	On some configurations 64-bit applications using a
	long double get incorrect results.
	JAGaa35268, JAGaa32697, JAGaa40380

	Performance of getcwd() may degrade in certain cases.
	JAGaa40211

	SHLIB_PATH is enabled in the 64-bit flavor of libc.
	JAGaa22065

	setjmp/longjmp calls cause SIGBUS/SIGSEGV if application
	is linked with CXperf tool.
	JAGaa32076

	Tuned, threaded applications using the small block
	allocator use more memory than before.
	JAGaa32072

	PHCO_16130:
	strcoll and wscoll of strings with collating elements
	fail.
	JAGaa18768, JAGaa18769

	(1) strptime(3C) does not support dates beyond January
	19 UTC 2038 in 32-bit HP-UX. (2) strptime() does not
	fill in tm_wday, tm_mon and tm_mday when supplied both
	the year and day of the year. (3) strptime() does not
	treat invalid input dates and inconsistent input as
	errors. (4) strptime() does not handle %E correctly
	in the C locale. (5) strptime() returns incorrect
	value for tm_yday and tm_wday if tm_sec and/or tm_min
	are initialized to -1 when the %j conversion
	specification is used.
	JAGaa06544; SR 5003416719

	strptime() treats Feb 29 2000 and March 1 2000 as
	the same day if the %A (or %a) and %U conversion
	specifications are used. JAGaa13581
	JAGaa13581; SR 1653269738

	getcwd(3C) fails with ENOENT if the root file system
	is a loopback file system (LOFS) after a chroot.
	JAGaa11165, JAGaa01441, JAGaa05219, JAGaa06021
	SR#4701382374

	getenv runs very slow for multi-byte languages JAGaa05075
	SR#1653259333

	The getdate() function does not parse the template file
	correctly when the %r field descriptor is used in at least
	one of the templates.  This leads to the situation that a
	non-zero value for getdate_err is returned even when the
	template file contains a matching template.

	In addition, getdate() does not correctly handle the case
	where %I is used in a template but %p is not. JAGaa00429,
	JAGaa10165, JAGaa10166, JAGaa10167, JAGaa10168,JAGaa05222,
	JAGaa10164, JAGaa10163, JAGaa08067, JAGaa10158,JAGaa12392

	memcmp( ) does not perform well when static branch
	prediction is enabled. JAGaa06535

	PHCO_15768:
	When LANG=japanese, the sed command, s/$/x/, would not
	add the character to the end of lines. JAGaa01206

	Commands dump core if LC_COLLATE=nonC and LC_CTYPE=C.
	JAGaa01685

	__strnlen() API in 64-bit mode returns incorrect value
	of the length of string. The __strnlen() API returns
	correct length of string in 32-bit mode, though.
	JAGaa01674

	JAGaa01271: syslog()
	Calling openlog() with a very long ident string causes
	syslog() to dump core or  create unexpected/undefined
	results.

	Multi-threaded applications using usleep(3C) hang.
	JAGaa01457

	When Null pointer was used as argument for fputs and
	puts, the behavior is inconsistent between pre-10.20
	and 10.20 onward releases. JAGaa01279 JAGaa01511
	JAGaa01513 JAGaa01515

	syscall() API doesn't handle 5th and 8th arguments
	correctly.  These parameter values are not handled and
	hence return value from syscall() API would not be
	correct.  JAGaa04782

	setjmp() function coredumps with Memory fault if the
	program is compiled with 64-bit mode (+DA2.0W) and -z
	compiler option along with patch PHCO_14102.
	JAGaa01982

	PHCO_14704:
	Libc does not compile with the changes made in ftw.h to
	provide Large Files support for C++ due to the use of
	"struct stat64" in the internal 64-bit ftw interfaces.
	JAGaa01664

	The API sigspace() causes the calling process to hangup
	if called after another call to this function; sigspace()
	also causes the calling process to terminate if called
	by more than one thread within a process. JAGaa01033
	JAGaa01062

	The API execvp(const char *file, char *const args[])
	fails (returns -1) with errno set to E2BIG if the
	following conditions are met: (1) the 'file' is a
	shell script that doesn't specify the interpreter
	being used. (e.g., #!/usr/bin/sh); (2) the number
	of arguments contained in arguments (args[]) is
	greater than 254. JAGaa00583

	Enhancement request for providing a new threads API
	__thread_detach(). JAGaa01380

	Customers using their own versions of malloc() and free()
	would notice free() being called twice on a same block
	while using the glob() libc API. JAGaa01494

	This is an enhancement request to provide jmp_buf pointer
	in the hook functions of HP CXDL Development Tool. These
	hooks are called from setjmp() and longjmp() APIs while
	applications are linked with HP CXDL Development Tool.
	JAGaa01603

	Inconsistent behavior from pre 10.20 systems and 10.20
	onwards in memccpy() API.  JAGaa01280.

	The API regcomp() dumped core, instead of returning
	error, when dealing with some non-recognizable expression.
	JAGaa01396, JAGaa01496, JAGaa01497

	strptime(3C) does not calculate the week number correctly
	when the first day of the year is a Sunday (for %U and %W)
	or a Monday (for %W). JAGaa00976 1653231456

	When users with expired passwords try to log in on the
	console, they get usage message from the passwd command:
	"usage: passwd [-F file] [name]".  DTS JAGaa00533, SR
	5003380394.

	Threaded applications calling the gets(3S) API may hang
	after doing another i/o operation on stdin. DTS JAGaa01148
	SR 5003394833.

	Code cleanup done in getcwd.c. User behavior unchanged.
	JAGaa01101

	PHCO_14102:
	Applications that fork & implement their own malloc will
	not compile. JAGaa01398.

	PXperf performance tool doesn't collect correct statistics
	across setjmp/longjmp() family of calls. JAGaa01399.

	When the length of the environment variable LANG is longer
	than 1024 (MAXPATHLEN), catopen(3C) in /usr/sbin/lanadmin
	caused coredump. JAGaa01290.

	Calling perror(string) with the length of the string and the
	message larger than 1024 will cause coredump.  DTS #
	JAGaa01178, JAGaa01166.

	Signal mask is not restored after calling free when
	mallopt(M_BLOCK,0) has been set.  Only happens on multiple
	calls to free for the same pointer.  DTS JAGaa00773,
	JAGaa00489, DSDe424072; SR 1653228304 1653119560 5003156760

	If malloc() is requested for an impossibly large size, for
	example 2 GB, when large malloc has been enabled, this
	request fails when malloc() returns NULL and sets errno to
	ENOMEM, as it should.  However subsequent calls to malloc()
	with smaller reasonable sizes should be successful, yet
	they fail when malloc() returns NULL and sets errno to
	ENOMEM. DTS# JAGaa01179.

	In the event that times(2) fails in a multi-threaded
	application, clock(3C) does not release the mutex.  This
	will cause the next thread that invokes clock() to wait
	forever for the mutex, in effect, causing the application
	to loop forever. DTS # JAGaa00967.

	NIS map transfer fails due to transfer timeout on slave
	as a direct result of an inefficient method of scanning a
	sparse DBM database. DTS # JAGaa01111, JAGaa01150; SR #
	5003392126.

	PHCO_13412:
	64-bit Fortran 90 gets unexpected signal and the floating
	point exception handling fails.  DTS CLLbs12814 CLLbs12830,
	SR 4701376756.

	PHCO_13283:
	The HP CXDL Development Tools don't collect correct
	performance statistics across setjmp/longjmp() family of
	calls. DTS JAGaa00559, SR 4701374496.

	The wcswidth(3c) API depends on methods/locales to
	return a value 0 for an empty wide string.  Sometimes
	a locale would return a value other than 0 for an empty
	wide string. DTS JAGaa00448, SR 4701374470.

	Core dump in certain corner cases.  DTS JAGaa01047, SR
	4701374504.

Defect Description:
	PHCO_24148:
	The defect was due to blocking the signals after locking the
	malloc  mutexes in the case of multi threaded  malloc.  When
	malloc/calloc/valloc/realloc is called in signal handler and
	also the main  thread of  execution  and there are  frequent
	signals to  application.  The  application  becoming busy in
	locking and  unlocking  the malloc  mutexes  resulting  into
	application hang situation.

	Resolution:
	Signals  blocking is done before locking the mutexes.  Which
	avoids the too many mutex locks and unlocks.
	JAGad55731; 8606186527

	mallinfo(3C)  doesn't give correct memory  statistics if the
	application is multithreaded  and uses multiple arenas.  The
	problem was introduced during multi arena  enhancement.  The
	way  mallinfo()  designed  works fine only for single arena,
	but the problem  starts when there are 2 or more  arenas and
	there is a overlapping brk value.
	When multiple  threads call  malloc(3C)  to allocate  space,
	each will be  assigned  an arena.  Each arena will  maintain
	the  start  and end  point of that  arena.  The  arena_start
	represents the starting heap address for this thread and the
	end_arena  represents the ending  address.  Assume 2 threads
	are say  THREAD1 and THREAD2  running in  parallel.  THREAD1
	calls malloc(),  malloc stores the the  arena_start1(current
	brk  value  say  0x1000  ) and  extends  the  brk  value  to
	predefined size and sets the  end_arena1(0x4000),  similarly
	THREAD2(arena_start  0x4000, arena_end  0x8000).  If THREAD1
	again calls malloc() and there is no pre-allocated  space in
	the arena, the brk value is increased and arena_end  will be
	set( 0x12000).
	The mallinfo()  will collect the size by visiting each arena
	starting from  arena_start till arena_end of that arena.  In
	the above case  arena_start  and  arena_end  of  THREAD1  is
	0x1000 and 0x12000  respectively, for THREAD2 arena_start is
	0x4000 and arena_end is 0x8000 respectively.  While counting
	the size, arena for  THREAD2  will be counted 2 times,  once
	with  arena1 and once with  arena2.  Hence the  problem.  In
	single  arena   implementation  this  problem  will  not  be
	revealed.
	Double  counting  is  happening  because we will  modify the
	dummy  header  when   AClastbrk  !=  _curbrk   (AClastbrk  <
	_curbrk).  The dummy  header  which had SIZE=0 and USED set,
	will be set with the  difference of _curbrk and AClastbrk in
	the function  grow_arena().  If the  AClastbrk of one thread
	is not equal to the _curbrk, the  possibility is that either
	user application called brk/sbrk or the function  grow_arena
	is called by some  other  thread.  If the  _curbrk  value is
	changed from some other thread by calling  grow_arena() then
	the other thread treats this as the user  allocation and the
	dummy  header  is  modified   appropriately  and  fixes  the
	arenaend for this thread.
	The problem will be there if there is a overlap  between the
	brk  values  of the  different  arenas.  So in  the  current
	implementation USER_ID is used when
	O  The application directly calls brk/sbrk
	O  The other arena calls brk/sbrk (in grow_arena()
	   i.e. AClastbrk != _curbrk)
	The  problem is  because of setting  USER_ID  when the other
	arena calls  brk/sbrk (in  grow_arena()  i.e.  AClastbrk  !=
	_curbrk).

	Resolution:
	The resolution is basically to avoid the use of USER_ID when
	the  other  arena  calls  brk/sbrk  (in  grow_arena()   i.e.
	AClastbrk  !=  _curbrk).  A  new  memory  block   identifier
	ARENA_ID is defined in malloc.c as
	#define ARENA_ID 0x13
	The  ARENA_ID is used to mark that the memory  block is used
	and it is used by some arena.  The used memory block will be
	marked with ARENA_ID under the circumstance mentioned below.
	When a block of memory is used by some  other  arena and the
	last brk value  maintained in the that arena is not equal to
	the _curbrk.  While  counting  memory  usage  statistics  in
	mallinfo(), the memory block with ARENA_ID as the id we will
	skip  because  it is used by some  other  arena  and will be
	taken into account under that arena.
	The two global variables
	char *_node_curbrk
	char *_common_curbrk are also defined in malloc.c.
	node_curbrk:  The variable  _node_curbrk is used to identify
	if there are 2 successive call to the function  node_alloc()
	from  different  arena.  The check is required  because when
	space is allocated for nodes, no space will be allocated for
	the dummy header.
	common_curbrk:  This   variable  is  analogous  to  _curbrk.
	_curbrk   keeps   track   process   wide  brk   value,   but
	_common_curbrk  is to keep  track  the brk  activity  within
	malloc module.  This variable is used to decide  whether the
	brk value is changed by some other arena OR application  has
	called brk(2)/sbrk(2) system call.  If the _common_curbrk is
	not equal to _curbrk means that the  application  has called
	the brk(2)/sbrk(2).
	JAGad34660; 8606165366

	ptsname  corrupts  heap  SIGBUS may  result.  It is a bug in
	ptname()   function.When  the  application  is  linked  with
	libpthreads,it dumps core.

	Resolution:
	The cause of this  problem is instead of passing  the sizeof
	bytes  allocated by malloc to the  GET_TSS()  function,  the
	sizeof the character pointer returned by malloc is passed as
	an argument.  So,it is always  taking  sizeof the  character
	pointer which is less than the number of bytes  allocated by
	malloc.  ptsname() is modified  accordingly  to address this
	problem.
	JAGad46861; 8606177629

	When the variable TZ is not set in the environment, in HP-UX
	it defaults  to EST5EDT  which is the east coast time in US.
	This poses problem in the  environment of the processes that
	(a) are started by init(1m)
	(b) clear their environment (e.g. login (1), sendmail(1m) )
	The hard coded value is inappropriate for any timezone other
	than east coast of US and the  difference  is  difficult  to
	track for countries like Australia which  frequently  update
	their daylight timing rules.

	Resolution:
	When the environment  variable TZ is not set, tzset() checks
	the default file  /etc/default/tz for the timezone value and
	sets timezone values based on that.
	The file /etc/default/tz contains the timezone value set by
	tzset() when the environment variable TZ is not set. The
	format for the file is same as TZ format without the prefix
	"TZ=".  Please check environ(5) for TZ format.
	The order of TZ setting is as follows.
	1) if the environment variable TZ is present, it takes
	   precedence.
	2) if TZ is not present then the value contained in
	   /etc/default/tz is used for the default.
	3) if /etc/default/tz is not set then the default value is
	   equivalent to EST5EDT (Eastern Standard Time) of US.
	(Install   the   Patch   PHCO_23652   to  get   the   sample
	/etc/default/tz file. Please read "Other Dependencies" field
	for more information on PHCO_23652 patch)
	JAGab20870

	valloc()  fails to  allocate  the  memory in multi  threaded
	application  when there is space  available in other arenas.
	The problem is because in  multithreaded  application if the
	space on heap is  exhausted  and no space in the  particular
	thread's  arena, valloc is returning  NULL.  But there could
	be some space available in other arenas and that can be used
	under this arena.

	Resolution:
	The  allocation  alogorithm for valloc() is modified, to try
	allocation of space from other arenas when there is no space
	left on the heap.
	JAGad47526; 8606178299

	Initialized  TLS  support  in libc  for 64 bit non  threaded
	applications.

	Resolution:
	The  initialization  routine of Libc has  changed to support
	initialized   TLS   variables   in  a  PA64   non   threaded
	applications.  Both the  archived and shared  version of the
	libraries have this enhancement.
	To get the complete functionality of ITLS (Initilized thread
	local storage) the following patches has to be installed.
	PHSS_23440 - linker core
	PHSS_23785 - linker ISU
	PHCO_23792 - libpthread
	PHSS_23953 - Fortran compiler
	Currently  this feature is available  with Fortran  compiler
	only.No  changes  are  required to be done in libc when this
	feature is made available for any other compilers.
	JAGad49168; 8606179946

	fstyp command calls statvfsdev on VxFS version 4 disk layout
	returns  "unknown_fstyp".  It  fails  on  accessing  initial
	inode  list  extents  block  address  which  exceeds  32 bit
	addressing.  lseek64  should  be used  instead  of lseek  in
	__vx_fs_lseek.

	Now the call to lseek is  replaced  with  lseek64 by using a
	compilation flag _FILE_OFFSET_BITS=64 in the makefile.
	JAGad57721; 8606188513

	When the APIs getprpwnam(), getgrnam(),  getnetbyname(), and
	getservbyname()  are configured with the  /etc/nsswitch.conf
	file to search  sources that do not support these calls, the
	Name  Server  Switch  engine  code  unloads the sources  and
	returns  NSS_NOTFOUND.  The source "nis" doesn't support the
	trusted system call  getprpwnam().  The source "dns" is only
	valid  for  the  "hosts"   database.  Thus,  subsequent  API
	getXXXbyYYY  calls that try to search sources that have been
	unloaded end up accessing invalid locations,  resulting in a
	SIGSEGV core dump.

	Resolution:
	If a source doesn't  support an API getXXXbyYYY  call, don't
	unload the source.  Just have the Name Server Switch  engine
	code return NSS_UNAVAIL.
	JAGad41604; 8606172344

	The  strcasecmp()   and   strncasecmp()   functions   behave
	incorrectly when presented with strings  containing bytes in
	the range 128-255.  The incorrect behavior can result either
	in a core dump or an incorrect  comparison  value, depending
	on the data.

	Resolution:
	Cast  chars to  (unsigned  char)  before  using  as index in
	_tolower().
	JAGad66064; 8606196866

	PHCO_23770:
	When a C application uses C++ plugins and calls  pthread/cma
	calls in static  constructor/destroctor,  it was  leading to
	destructor  being called twice.  This was happening  because
	the C++  runtime  initialization  routine  was  invoked at a
	point when the pthread library initialization would not have
	been complete .  During this time,  constructor was invoking
	pthread calls .  This might have lead to  destruction of the
	shared data (static/global) in the libCsup.

	Resolution:
	Changes are made to libc so that C++ runtime  initialization
	routine is invoked  only  after the  completion  of  pthread
	library initialization.
	JAGad55189; SR 8606185984

	PHCO_22923:
	On  HP-UX  if  a   nonthreaded   application   links   to  a
	thread-safed  library  the link will fail due to  unresolved
	pthread symbols.To resolve these symbols, it is necessary to
	link the  nonthreaded  application  to the  threads  library
	libpthread.But linking to that library makes the application
	threaded  even if it creates no  threads.Providing  POSIX 1c
	thread  "stubs" in HP-UX C language  library have two direct
	effects for  nonthreaded  applications.  a) POSIX 1c threads
	symbols are resolved if a nonthreaded application links to a
	thread-safed  library  b)We  avoid  the  overhead  of a real
	threads library -- especially the overhead  associated  with
	mutexes when the nonthreaded  application  uses thread stubs
	rather than real threads library procedures.

	Resolution:
	Stubs are provided for all pthread calls only in SHARED LIBC
	FLAVORS of the HP-UX C Library.  These stubs do not have any
	functionality,  these are  dummy  functions  returning  zero
	except  pthread_getspecific()  family of APIs which has full
	functionality  implemented in the stubs.  Full functionality
	is provided in the stub for the  following  pthread  calls
	 * pthread_key_create()
	 * pthread_getspecific()
	 * pthread_setspecific()
	 * ptherad_key_delete()
	 * pthread_exit()
	call to stub pthread_self() returns 1
	call to stub pthread_equal(arg1, arg2) will return
	(arg1 == arg2)
	Call to the stub pthread_create() and pthread_attr_init()
	returns ENOSYS.
	All other stub calls returns zero.
	There are two special  interfaces  provided  for checking
	whether an application is linked to pthread library or not.
	a)  __is_threadlib_linked()
		returns 1 for an applications linked to pthread
	library otherwise returns zero.
	b)  __get_ismt()
	  returns 1 for applications linked with libcma
	  returns 2 for applications linked with libpthread
	  otherwise returns 0
	Risks:
	------
	An application may  inadvertantly  pick up the stubs when it
	intended  to use the real  pthreads  APIs, or it may pick up
	the  stubs  when it needs cma APIs or stubs.  These  are all
	link order problems.  An application that needs cma behavior
	must link to libcma (or the cma stubs  library)  and must do
	so in a supported link order,
	i.e.  the link line  should be shared only and should
	not contain "-lc" before -lcma.
	So long as this  condition is met, the correct cma functions
	will be referenced.  Similarly, a multithreaded  application
	that needs pthread  threads  library  behavior  must link to
	libpthread  and must do so in a  supported  link  order, and
	only use shared libc and libpthread.
	eg : An applications wants to use pthread stubs then
	the link order should be
	$ cc test.c -lc -lpthread
	An applications wants to use pthread library then the
	link order should be
	$ cc test.c -lpthread -lc
	JAGab69119; SR 8606102984

	User  cannot use C++ runtime  library on 32 bit  application
	without  either  using  a C++  main  program  or  explicitly
	invoking the C++ runtime library's  initialization  routine,
	_main, from the C ( or Fortran ) main  program.This  problem
	is not there for  64-bit  PA-RISC  applications,  or for any
	IA-64  applications, since the C++ library's  initializer is
	run  automatically  -- either  at  program  startup  or when
	dynamically loaded.

	Resolution:
	The  definition  of  the  __main_ptr  variable  is  done  in
	libc_init  routine.  The same varible is defined as a global
	variable in  libcsup,  which will be  initilized  to the C++
	runtime library  initialization  routine, _main.  Thus, when
	libcsup is linked into the program,  the variable  _main_ptr
	will point to _main; otherwise, it will contain 0.
	JAGad41440; SR 8606172179

	gettimeofday is very slow for certain vendors who use it for
	time stamping because it calls a heavy weight system call to
	get the current time of the day.

	Resolution:
	A new API hrtime_t  gethrtime(void)  has been added to libc.
	This API uses fast light weight  system call to get the nano
	seconds from certain time.  It does not give you the current
	time of day.  hrtime_t is a signed 64 bit  number.  This API
	will only be available if the  application is being compiled
	in -Ae mode because 64 bit integer  number is not  available
	in -Aa mode.
	JAGad44410; SR 8606175166

	Global  symbols  in libc can  conflict  with one in  program
	causing  SIGBUS.  In  ptsname.c  we have  defined two global
	symbols  alpha and  range_spec.  They are symbols  which are
	used only by libc.  They should not be visible to customers.
	They can conflict with the user defined global symbols.

	Resolution:
	alpha and range_spec is not used a global symbol in libc
	JAGad33756; SR 8606164457

	sigwait() does not work as cancellation  point if the thread
	is   cancelled   after  it   enters   __sigwait_sys().  When
	cancelling a thread that is blocked on sigwait() by means of
	pthread_cancel(),  the blocked sigwait()  returns with EINTR
	rather  than  checking  the  cancellation  point  before  it
	returns and terminate the thread.

	Resolution:
	When the thread is  cancelled,  then  __sigwait_sys  returns
	error  EINTR  and does not set  errno.  In  sigwait  we were
	checking for errno and setting the cancellation  point.  Now
	that has been modified to check for return value.
	JAGad39745; SR 8606170481

	memmove()  is  moving  data  positioned  very  close  to the
	quadrant boundary and it leads to a SIGSEGV.  When memmove()
	attempts to move >=16 bytes of data,  including  the last 16
	bytes of a quadrant, it fails with a SIGSEGV.

	Resolution:
	To correct  this  problem, the initial load word is now done
	without  modifying  the source  address.  The offsets of the
	subsequent loads are now positive from the current  pointer.
	After all loads are done, we increment the source address by
	16.
	JAGac87878; SR 8606129543

	regcomp(3C)  function  fails to detect an  extended  regular
	expression  match  in  the  input  data.For  example,If  the
	pattern is "%|^xyz"  and the string is te%st, it gives Found
	No Match.

	Resoltion:
	Defect is fixed by adding an  "alternate"  flag which is set
	when  there  is an  alternate('|')  option  in  the  regular
	expression.
	JAGad31456; SR 8606162140

	seekdir core dumps when compiled with -z option

	Resolution:
	Made   changes   to   check   for   null   pointers   before
	derefererencing.
	JAGac78889: SR 8606128089

	Purify reports "Uninitialized Memory reads" in readdir_r

	Resolution:
	Changes are made to initilize variables
	JAGac95112; SR 8606130241

	ftw core dumps

	Resolution:
	Trying to access the freed memory in closedir.c
	was causing the core dump. It is fixed now.
	JAGad21880; SR 8606152550

	
	When snprintf() is called with arguments like so:
	   snprintf(buf,0,format,args...);
	the buffer pointed to by buf should not be altered
	since the maximum number of characters to write
	to buf is zero, but the buffer is in fact modified.

	Resolution:
	Checks for the str_len  parameter  for zero before doing the
	actual processing.
	JAGad12471; SR 8606143128

	regerror() may dump core for some values of error code

	Resolution:
	The  logic  for  checking  the  validity  of  error  code is
	changed.
	JAGad02475; SR 8606133330

	PHCO_22314:
	Certain  allocation  patterns  using large malloc cause data
	corruption  in the last  integer of a  malloced  block.  The
	root  cause is an error in the design of large  malloc.  The
	lowest level allocation  function  malloc_sbrk()  hides from
	the  caller  whether  sbrk()  or mmap()  is used to grow the
	arena.  However, in general when mmap() is used,  allocation
	is   discontiguous.  Depending  on  whether   allocation  is
	contiguous or  discontiguous,  two different  length  values
	must be passed to malloc_sbrk() because in the discontiguous
	case space must be  allocated  for a second  pair of headers
	(the  dummy   headers  that   terminate  the  arena).  Since
	malloc_sbrk() hides from the caller the fact that sbrk() has
	failed over to mmap(),  there is no way to know which length
	to  pass.  The  implementation  always  passed  the  shorter
	length,  which is correct  only for  contiguous  allocation.
	Since  the  pre-large  malloc,  sbrk()-only,  code  detected
	discontiguous  allocation  before calling  sbrk() and passed
	the correct  lengths for each case, when sbrk() was replaced
	by  malloc_sbrk()   the  code  continued  to  work  for  the
	sbrk()-based  heap.  However,  when the fail over  to mmap()
	occurs,  and  whenever   mmap()  results  in   discontiguous
	allocation, the code does not detect the  discontiguity  and
	the shorter  length is passed to  malloc_sbrk().  This means
	that  the  arena  end  dummy  headers  are  not   explicitly
	allocated  in these  cases.  Usually,  alignment  causes the
	arena end to be spaced far enough  from the user area of the
	last block that no data  corruption  occurs when the headers
	are written.  However, for certain  block sizes and starting
	positions  this is not true, and the dummy  headers  overlap
	the  user  area  of  the  last  block,   resulting  in  data
	corruption.

	Resolution:
	The ideal fix would involve recoding large malloc so that it
	does not have a layer that hides whether sbrk() or mmap() is
	being used, and always doing the correct length  calculation
	for each  case.  However,  the fix we have  applied  here is
	simply to allocate  space for the second  pair of headers in
	every case.  This does no harm, because it simply  increases
	the  amount by which the arena is  grown,  not the  sizes of
	blocks  returned  to users.  The extra space winds up on the
	freelist.  Moreover,  in most  cases  the fix does  not even
	change the amount by which the arena is grown,  because  the
	round-up to the next ALLOCSIZE  boundary is the same with or
	without the fix.  Only for certain sizes of request that are
	at or very close to an ALLOCSIZE  multiple will the fix make
	a difference  in the amount by which the arena is grown.  In
	those  cases,  the  arena  will be  grown  by an  additional
	ALLOCSIZE.  This guarantees  that the arena end headers will
	not overlap the user area of the last block.  It will cause,
	in these cases, an extra free block of about ALLOCSIZE to be
	added to the free list.
	JAGad25621; SR 8606156311

	strftime(3C) is a thread safe libc API.  In a  multithreaded
	application  when many threads  calls this API threads  were
	blocking  on  a  mutex  used  to  synchronize  the  threads
	execution.  The  mutex  lock  holding  time by every  single
	thread  was very high  because  of which,  threads  were not
	executed in parallel.

	Resolution:
	The previous design of strftime(3C) was using most of global
	data,  to  store  the   intermediate   processed   data.  To
	synchronize the access to this data, in the API strftime(3C)
	a mutex was locked on entry into the API and  released  only
	while  return.  This  problem can be  observable  on V-class
	systems.  To resolve the mutex lock  contention,  the global
	data is  replaced  with local data which will be per thread,
	and the mutex  locking  is made very  short  period of time.
	This change promotes the parallel  execution of many threads
	during the execution of this API.
	JAGac86555; SR 8606129009

	The problem was traced to a libc code, to acl() stub.
	The following check was done:

	        if ((stat(filep, &statbufp)) != 0)
	                return (-1);

	
	However,  since stat() is a 32 bit function, it would return
	EOVERFLOW on files that are 2GB+.  It was  determined by our
	investigation  that this call is done only to check that the
	file  is  present.  E.g.  it  was  assumed,  that  an  error
	returned by stat() would imply a bad filename.

	Resolution:
	The  change  was made to remove the  stat()  check  from the
	acl() system call.  Our  investigation  has determined, that
	the kernel code  handles the invalid  file names  correctly,
	and comes back with an  appropriate  errors  when a bad file
	name  is  given.  With  that in mind  the  stat()  call  was
	determined to be an unnecessary precaution.
	JAGad09568; SR 8606140246

	sed(1)  hangs in non-C  locale  for  some patterns, awk  sub
	pattern does not work well under non-C  locales.  Both these
	problems were happening  because of underlying  problem with
	regexec.  regexec loops beyond the end of string looking for
	match in Non-C Locale.

	Resolution:
	The  problem  was traced to libc API  regexec.  Regexec  was
	looping and was  looking for a match with the  pattern  when
	the end of string was reached.  The fix  introduces a return
	with No match when the end of string is reached.
	JAGad05149,JAGac56665; SR 8606136018,8606126100

	regcomp(3C) returns bus error in case of lack of memory.
	According to the manual pages, regcomp(3C) should return
	REG_ESPACE when the system runs out of memory.

	Resolution:
	In the  regular  expression  sources,  in some cases  return
	value of malloc(3C)  was not checked.  Without  checking the
	return  value, a member in the  structure  was assigned with
	some value,  which is illegal and resulted in bus error.  To
	fix this  problem,  the  return  value  from  malloc(3C)  is
	checked.  If malloc(3C) returns NULL(No memory), regcomp(3C)
	return REG_ESPACE.
	JAGad03415; SR 8606134279

	When the switch engine fails to get the backend for the last
	resource,  it does not clean up the  resources  and free the
	contexts.  Because   of  that,  the   subsequent   calls  to
	getgrent/getpwent  have an  unexpected  value in the context
	structure and thus causes the SIGBUS error.

	Resolution:
	Added the cleanup calls, nss_endent_u() and nss_delete()
	in the nss_getent_u() function of the switch engine.
	JAGad11220; SR 8606141866

	Under certain circumstances strncat can truncate the output
	string.

	Resolution:
	The logic of the  strncat  function  was  changed to address
	this problem.  JAGad16345; SR 8606147002

	PHCO_22076:
	When a system  is  disconnected  from the  network,  and the
	hostname  lookup is configured for dns, it takes a long time
	trying  to  resolve  the  hostname  before it falls  back to
	files.  The customer wants configurable timeouts.

	Resolution:
	Two new options  have been added to make the retrans and
	retry values configurable. These 2 values can be set in
	resolv.conf as follows.
		retrans <value in milli seconds>
		retry <value>
	Or these values can be set using environment variables
	also.
	       RES_RETRANS
	       RES_RETRY
	Two new apis are provided to provide programmatic access
	to resolver(3N) retransmissions or timeouts:

		get_resfield (int field, void *value, int len);
		set_resfield (int field, void *value);

	field - is either RES_RETRANS or RES_RETRY.
	value - is the value to be set or obtained.
	len - is the sizeof(value).

	The order of precedence is as follows.
		1. environment variable
		2. resolv.conf
		3. API.

	JAGaa27175; SR 5003424531

	PHCO_20765:
	Fork fails to return for threaded applications using
	the 11.00 LR libpthread.

	Resolution:
	A bug in the atfork handler for the dynamically allocated
	malloc arena mutexes caused an uninitialized and unallocated
	mutex to be locked. The mutexes are no longer dynamically
	allocated and the atfork hander has been restored to its
	earlier version.
	JAGac40398; SR 8606125006

	Threaded programs using third-party mallocs abort. The
	dynamic allocation of malloc arena mutexes in PHCO_20555
	did not check for third party mallocs, which do not allocate
	the mutexes.

	Resolution:
	The malloc arena mutexes are no longer dynamically allocated
	and it no longer matters that a third party malloc has not
	allocated them.
	JAGac40401; SR 8606125009

	Threaded applications archive linked to earlier versions of
	libc but linked shared to system libraries with dependencies
	on shared libc can call the wrong libc mutex initializer,
	the one for patch PHCO_20555, which assumes malloc arena
	mutexes are allocated dynamically. However the older libc
	that was archive linked to these applications assumes the
	mutexes are allocated statically. This version mismatch
	leads to attempts to lock uninitialized mutexes. This
	linkage of archive libc and shared system libraries
	dependent on shared libc is unsupported, precisely because
	such mismatches can happen.

	Resolution:
	The 64 malloc arena mutexes have been returned to static
	allocation in order to maintain backwards compatibility
	with older libcs in (unsupported) archive-shared link
	mixtures. The malloc arena contexts are still dynamically
	allocated.
	JAGac40402; SR 8606125010

	Freeing valloced buffers causes sporadic failures in
	threaded applications.

	Resolution:
	A bug introduced in the conversion of valloc for multiple
	arenas caused some valloced buffers to be constructed so
	that they could not be freed correctly. It has been fixed
	in this patch.
	JAGac40711; SR 8606125320

	In a multi-threaded application, the PHCO_18227 malloc()
	created a new arena for each new thread until the configured
	number of arenas had been created. This approach led to
	excessive memory growth in applications that create threads
	sequentially and malloc/free a large amount of memory in
	each thread.

	Resolution:
	The arena assignment algorithm now tracks the active number
	of threads in the process and creates new arenas only when
	all existing arenas have at least one thread assigned to
	them. The new algorithm requires libpthread patch PHCO_19666
	to be installed on the system. If PHCO_19666 is not
	installed on the system, or if the application is linked
	with libpthread.a, then memory growth can be controlled by
	setting the maximum number of arenas to be 1.
	JAGac40903; SR 8606125513

	PHCO_20763:
	This is a SP patch version of PHCO_20765.

	PHCO_20555:
	system() was calling fork() in multi-threaded
	applications as a work-around for some locking issues
	within dld.sl and libc. The cost of a fork() relative
	to the cost of vfork() resulted in slower performance.

	The specific issues were related to locking calling
	made from the child process created by system() prior
	to exec(). The availability of these locks could not
	be guaranteed across a vfork() and hence the use of
	fork() in the original implementation of system() for
	11.00.

	Resolution:
	system() was changed to use vfork() for all
	applications instead of using vfork() only for
	non-threaded applications. sigaction() was changed
	to not require a lock() around the sigsetreturn()
	call when called from the child process created by
	system().  This guarantees a lock-free path in the
	child created by system(), thus enabling the change
	to use vfork().
	JAGab78389, JAGab81794

	In applications using large (shared memory based)
	malloc, malloc can return an invalid quad 2 "buffer"
	that overlays the stack. This invalid buffer results
	from incorrect coalescence of a quad 2 buffer with a
	quad 3 mmapped buffer.

	Resolution:
	The first quad 3 buffer for an arena is never
	coalesced to the last quad 2 buffer.
	JAGab72262

	In threaded applications, malloc statically allocates
	64 arena contexts and arena mutexes, regardless of
	whether 64 are needed.

	Resolution:
	Only one arena and one arena mutex are statically
	allocated.  Others are dynamically allocated from that
	one static arena. Only as many arenas and mutexes are
	allocated as required.
	JAGaa14937

	Certain partners require additional undocumented malloc
	statistics.

	Resolution:
	The __mallstat() api has had an additional command added
	to read an additional statistic.
	JAGaa26400

	If dirname(3c) is given an argument string which begins
	on a page boundary, and the prior virtual page is
	unreadable for any reason, dirname() causes a segmentation
	violation when it tries to look at the last byte of the
	previous virtual page.

	Resolution:
	dirname(3c) checks that it is within the space of the
	argument string before looking at a byte of the string.
	JAGaa62439

	In a multithreaded program, using popen(3C) and fork(2)
	calls in different threads can cause a deadlock.

	Resolution:
	The popen(3C) code has been modified to release the
	popen_rmutex lock before calling fork().  This lock is
	basically used to update a linked list, namely
	popen_table.  In order to add the element to this list,
	we need to know the pid returned by the fork(2) call.
	The algorithm has been changed such that we identify a
	free slot in the list(or allocate if none are free),
	remove this element from the list, then call fork(2).
	After fork(2) returns in the parent, we update the
	element, grab the popen_rmutex and update the list
	and release popen_rmutex.  This avoids the deadlock.
	JAGab77826; SR 8606107568

	regcmp() stack is not LP64-safe

	Resolution:
	The data type inconsistency has been fixed by using
	the correct data types.
	JAGab71463; SR 8606104124

	VxFS ACL fails with large UID's/GID's (>=0x80000).
	Once the file has one such entry in its ACL list,
	any subsequent acl operations return "Invalid Argument"
	error:
	[ aldan:/mnt ] (90) touch TEST
	[ aldan:/mnt ] (91) setacl -m user:12345678:r-- TEST
	[ aldan:/mnt ] (92) getacl TEST
	acl failed for file "TEST", Invalid argument

	The problem was traced to libc code, where the uid in
	acl entry is masked by global kernel defenition
	IDDONTCARE, which is set to 0x80000.  When retrieving
	ACL records of a file, the first occurance of such
	record is assumed to be the end of list. The lack of
	remaining entries then causes EINVAL (Invalid Argument)
	error to be returned.

	Resolution:
	The change has been made to check taclp->a_type
	against IDDONTCARE rather then checking field a_id.
	This will ensure, that the ACL entries with UID/GID
	grater then the value of IDDONTCARE (0x80000) will not
	fail. The change will make the code work exactly as a
	respective piece in kernel, which has not been causing
	any problems as of yet.
	JAGab76091 JAGab76238; SR 8606106738

	An array that stores the pointers to list of domain names
	in the search list is terminated with a NULL pointer.
	A pointer dereference was being done and dereference of
	a NULL pointer was causing a core dump.

	Resolution:
	A check is made for the NULL pointer without dereferencing
	it.
	JAGab72180

	res_send call does not close socket descriptors under MT
	environment.

	Resolution:
	The code changes made to frontend was restored to the old
	state and also the dns backend was restored to original
	code before the IPv6 changes were made.
	JAGab82346

	The dns backend was modified for IPv6 changes.  During
	this course, host address type was being passed from the
	front end getXXbyYY  calls to the backend.  RPC calls use
	dns  backend  directly  through  switch  and not through
	getXXbyYY frontend calls.  As the rpc were not passing
	this host address type the backend returns NULL, and the
	rpc calls fail.

	Resolution:
	The code changes made to frontend was restored to the old
	state and also the dns backend was restored to original
	code before the IPv6 changes were made.
	JAGab68997

	The host address type in the returned hostent structure
	was not being set to correct value when IP address was
	being passed to gethostbyname call.

	Resolution:
	The code changes made to frontend was restored to the
	old state and also the dns backend was restored to original
	code before the IPv6 changes were made.
	JAGab71997

	The environ(5) manpage states that the TZ environment
	variable can be of the form:

	[:]STDoffset[DST[offset][,rule]]

	Furthermore, the rule has the form:

	date/time,date/time

	where the first date/time specifies when to change from
	standard to summer time, and the second date/time
	specifies when to change from summer to standard time.

	This rule works in the northern hemisphere, where the
	first date number is less than the second date number.
	For example, in Atlanta, Georgia, I might use the
	following TZ variable:

	export TZ=EST5EDT4,M4.2.0,M10.5.0

	Which indicates that I change from standard to summer
	time on Sunday, the 2nd week of April, and that I change
	from summer back to standard time on the last day of
	October.

	Notice that in this case 4 < 10, so this works.  On the
	other hand, in the southern hemisphere, I might use a
	TZ variable like the following:

	export TZ=SAT3XYZ2,M9.1.0,M1.2.0

	This states that we should change from standard to
	summer time on Sunday, the first week in September,
	and from summer to standard time on Sunday, the second
	week of January.This dose not work because 9 > 1 (date1
	> date2). The defect here is that the date2 is not
	considered as in the next year. It is considered to be
	in January of same year of date1 instead of the next
	year.

	Resolution:
	A new condition is added in check for entry into the
	DST.  This new condition will take care of the
	southern hemisphere
	JAGab75719; SR 8606106516

	When the conditions are where the source offset is
	greater than the destination offset and the count is
	greater than the terminated source string to concatenate,
	strncat can move few than the number of bytes in the
	source string.

	Resolution:
	Corrected faulty strncat logic.
	JAGab84233

	PHCO_20369:
	This is an SP patch version of PHCO_20555.

	PHCO_19691:
	In 32 bit application, the value of time_t can only be
	up to 2038, which we have rules to cover in the file
	/usr/lib/tztab.  In a 64 bit application, we allow
	time_t to bigger than INT_MAX which means larger than
	2038.  We have a routine to check for this for 64 bit.
	The defect here is that, a call to bsearch is made
	before this check and that call is assuming that the
	input will be less than 2038.  But for years beyond
	2038 bsearch returns NULL and dereferencing is done
	with this NULL pointer and resulting in dumping core
	when the application is compiled with -z option.

	Resolution:
	Check for return value from bsearch,If the return value is
	NULL don't dereference.
	JAGab72590; SR 8606104837

	1. ctype(3C) routines are too slow and the macros
	have too many instructions because they contain
	function calls.
	2. The performance of singlebyte applications using
	the ctype routines needlessly degrades in multibyte
	locales.
	3. strcasecmp(3C) and strncasecmp(3C) are too slow
	compared to other vendors because they rely on
	_tolower(3C) which is a macro mapped to a function
	call.

	Resolution:
	To allow ctype routines to always perform table lookup,
	code populating the tables pointed into by __SB_masks,
	__SB_upper, and __SB_lower has been moved from
	__ctype_init() in NLSsetup.c to update_locale() in
	setlocale.c Now __SB_* pointers are *never* NULL and
	are used in all locales by ctype and wctype routines
	for characters codes from -1 through 255.

	Key to this change is the X/Open and HP specification
	that the return value from a ctype API is valid only
	for ints from -1 through 255.  If the API receives any
	other argument value, its behaviour is undefined. This
	fact also entailed a change to atol.c (for atoi() and
	atol()) to make sure sign extension of a char converted
	to an int does not corrupt an argument passed to
	isdigit().

	Backward compatibility forces us to limit these changes
	to internal libc use, since an application built with
	the new ctype.h and new libc but running with an older
	libc will crash. As a safeguard, all changes to ctype.h
	have been placed within #ifdef _SB_TABLE_LOOKUP and
	make.defines has been modified to strip those changes
	before a ctype.h is built for shipping (in pub_hdr/).
	Other files have been changed to ensure the faster
	ctype macros are always used in libc.
	JAGaa43050 JAGaa05164

	mktime() ignores tm_isdst if a previous TZ value had
	no dayl. sav. time

	Resolution:
	When the mktime() is invoked with different TZ
	environment  variables, a static local buffer "tzbuf" is
	used in localtime_r() in ctime.c to store the time zone
	name(For ex:  PSD8PDT,  UTC0  etc..).  mktime()  looks at
	/usr/lib/tztab file for getting the information on day
	night savings for the set time  zone(Please look at man
	pages for tztab).  The idea behind using the static buffer
	is to avoid reopening of the file /usr/lib/tztab if its
	already  processed.  However, if there is a change in
	timezone in between, the file should be  reparsed.

	The source file ctime.c is modified to check whether
	the TZ environment variable has changed and if so,
	the TZ variable is copied before further processing
	takes place.
	JAGaa44810; SR 5003444117

	strptime(3C) was unable to process format strings
	containing "%EY" or "%EC%Ey" directives and returned
	NULL. These directives are used by the era date format
	in Chinese locales zh_TW.ccdc and zh_TW.big5. The era
	date format (and this defect) are only in the 2 above
	locales supplied by HP. The failure is not caused
	by a particular date.

	Resolution:
	A correct algorithm is used to parse the %EY or %EC%Ey
	directive.
	JAGaa08262 JAGaa47278

	When calling strncmp with one valid string pointer,
	a null pointer an a length of zero strncmp will return
	the first charater or the negative of the first
	character of the valid string instead of an expected
	zero.

	Resolution:
	Change the sequence of condition testing in strncmp.
	SR 5003463463

	memchr() was not treating the match character as an
	unsigned character.

	Resolution:
	When comparing a negative integer on a short string
	memchr did not convert the negative integer to an
	unsigned char.
	JAGaa93243

	Strrstr(s1, s2) sometimes claims that a match is found
	when actually there is no match. Consider an example.
	s0 = "ABCDEFG";
	s1 = s0;
	s1 ++; /* s1 points to "BCDEFG" */
	s2 = "ABCDEFG".
	Now strrstr(s1, s2) returns "ABCDEFG", which means that
	a match is found.  It should have returned NULL.
	The problem is caused by the fact that when characters
	in s2 matches characters in s1, the algorithm keeps
	going backwards to find if more characters match without
	checking if the beginning of s1 is reached.

	Resolution:
	A check is added to make sure that when the beginning
	of s1 is reached, the search stops.
	JAGaa41142

	Some PA2.0 assembler syntax was used in the 1.1 portion
	of the code.  The current 11.X assemblers accept this
	syntax and emit the correct op codes for 1.1 machines.

	Resolution:
	changed syntax to conform to PA1.1 syntax.
	JAGaa62460

	Pointer subtractions involve NULL pointer. In 64-bit,
	such subtraction results in overflow or underflow, and
	assigning large numbers to pmatch[i].rm_eo.

	Resolution:
	JAGaa46130

	If an internationalized application calls setlocale()
	more than once to change its locale environment, it
	continuously leaks memory.

	Resolution:
	Memory needs to be dynamically allocated by setlocale()
	to save the locale specific information when changing
	the locale environment.  The previous setlocale()
	implementation didn't free the memory when changing the
	locale environment.  The new implementation frees the
	memory used to save the current locale information and
	allocate another memory to save the required locale
	information.
	JAGaa06047

	An internationalized application which frequently calls
	setlocale() to change its locale environment will
	encounter a serious performance problem.

	Resolution:
	Separate shared libraries implement the locale specific
	information.  They are loaded into an application by
	setlocale() to change the locale environment.  The
	previous setlocale() implementation used to load the
	required locale shared library and unload the one
	currently in use when changin the locale environment.
	Loading and unloading locale shared libraries are an
	expensive operatoin.  The new implementation caches up
	to 10 locale shared libraries in the application for
	the quick locale switch.  And there used to be a number
	of str*() and mem*() function calls just to copy and
	compare short strings.  They have been replaced by
	equivalent macro versions to eliminate the function call
	overhead.
	JAGaa08086

	A multi-threaded internationalized application fails in
	setlocale() for the restore operation using the buffer
	returned by the previous call to setlocale().  This patch
	should be installed for such applications.

	Resolution:
	In a multi-threaded environment, setlocale() and
	__setlocale_r(), which exists only for libd4r library,
	used to share the implementation in the way that
	setlocale() calls __setlocale_r() after protecting itself
	against simultaneous calls from more than one thread.
	__setlocale_r() erases the previous locale names (set
	the first byte to '\0') contained in the passed buffer,
	which has caused the problem.  The new implementatoin of
	setlocale() doesn't call __setlocale_r().  Another
	internal function was introduced to implement the common
	portion that can be shared by both functions.
	JAGaa32025

	When memcmp is  called  with  a negative value in the
	third argument, memcmp returns an incorrect value.
	The third argument is size_t which should really be
	treated as a large unsigned quantity.

	Resolution:
	Negative values passed to memcmp() are converted to
	large unsigned values and the comparison proceeds as
	normal.
	JAGaa24067

	VxVM pathnames not recognized by blocktochar().

	Resolution:
	__blocktochar() and __chartoblock() routines were
	rewritten to make them more general and accept any
	naming convention for device files.
	JAGab69351; SR 8606103064

	The calling overhead for a shared library imposes
	performance penalities on shared libraries. The normal
	calling convention for routines that are within an
	executable is a simple branch instruction. This is not
	possible for shared libraries because they exist in
	different spaces than the executable and they can load
	to diferent addresses each time they are loaded.  As a
	result the calling convention requires the use of stubs
	and tables to provide the mapping between the call in
	the executable and the entry in the library. This will
	entail a couple mispredicted branches along with the
	inter-space branch.

	Resolution:
	The compiler has several pragmas that can be used to
	cut down on the calling overhead for shared libraries.
	In order to make use of these pragmas the header files
	for libc needed to change to allow building the library.
	JAGab15584 JAGab16669

	strtod("NaN",ptr) on HPUX 11.0 incorrectly returns a ptr
	past the '\0'.

	Resolution:
	strod(3C) code was changed to fix the incorrect behaviour.
	JAGaa05185; SR 4701389726

	glob(3) does not treat // consistently in a directory
	path.

	Resolution:
	The glob(3C) was removing only the last '/' character
	(if any) in a patch string. Now, glob(3C) is modified
	to take care of multiple occurance of trailing '/'s in
	the patch string.
	JAGaa94846; SR 1653297432

	The strxfrm incorrectly assumes that the variable
	holding the length of the input buffer includes the
	space for null character at the time of the check.

	Resolution:
	The algorithm for strxfrm was changed. There is a
	check in this algorithm to find out if the size of
	transformed string is more than the input buffer.
	The condition does not take byte taken by null
	character of the transformed string. This results
	in null character being placed at arbitrary address.
	Hence the transformed string may contain junk characters.
	The condition was changed to take null character into
	account.
	JAGaa95471

	When the getcwd() algorithm crosses a mount point on the
	way to the root, it scans the entire directory containing
	the mount point with stat(). When the mount point has
	"sibling" directories that are also mount points, it is
	very likely that the algorithm will stat() the root of
	filesystems not on the current path, which is an expensive
	operation both in terms of time and system resources.

	Resolution:
	The algorithm now remembers all mount points that it
	crosses, so that it only ever needs to fully scan a
	directory for a mount point once. Also, the new algorithm
	pre-initializes the table of mount point names so that,
	in most cases, it never needs to scan for a mount point
	at all.  Instead, it guesses the correct name immediately,
	avoiding the expensive scan of the directory and
	(possible) other remote filesystems. There are several
	other minor improvements to the function to help pay for
	the overhead of keeping track of mount points.
	JAGaa01123, JAGaa40237

	The contents of the struct utmp is cleared when end of
	file is reached. But the struct utmp should be cleared
	only for partial reads.

	Resolution:
	Code changes are done in the getut.c file to retain
	the struct utmp contents when end of file is reached,
	it is cleared only during partial reads.
	JAGaa05209

	Running the following program:
	main()
	{
	    union {
	        unsigned long long dbl[2];
	        long double ldbl;
	    } u;

	    u.dbl[0] = 0x7FFFF80000000000ULL;
	    u.dbl[1] = 0;
	    printf("%10.4Le\n", u.ldbl);
	}

	produces the output:

	N.aN00e-01

	which is incorrect.

	Resolution:
	Code is added to handle NAN and Infinity in case
	of long double.
	JAGaa86217

	Excessive mutex contention and mutex locking overhead
	in malloc. This was partially addressed by multiarena
	malloc, but certain third-party malloc benchmarks
	indicated that HP's malloc performance was still
	uncompetitive.

	Malloc heapsize statistics were incorrect due to
	multiarena algorithm changes, which caused each arena
	to contain holes belonging to other arenas. When total
	heapsize was computed, these holes were overcounted
	resulting in large overestimates of total heapsize.
	In addition, the calculation was done under mutex lock,
	which gave unacceptable performance for some third party
	applications.

	Multiarena malloc had assertions turned on around mutex
	locks and unlocks.

	Multiarena malloc aborts in 64-bits when _M_ARENA_OPTS
	is set, due to a missing function prototype for getenv()
	in libc_init.c.

	Multiarena malloc does not allow fewer than 4 arenas
	to be configured, resulting in at least 4X the
	pre-multiarena memory consumption for a program which
	runs threads sequentially.

	Resolution:
	Overview

	A thread local cache is provided for each thread. Freed
	blocks are cached rather than coalesced, and requests are
	satisfied out of cache if possible.  This provided three
	performance benefits: 1) cache access does not need to
	be mutexed, because it is thread private. 2) coalescence
	is deferred, speeding up free(). 3) Blocks of sizes that
	have previously been requested are available, and do not
	need to be split if these sizes are requested again,
	potentially speeding up allocation (if the same sizes tend
	to be requested again).

	A roughly 2X speed up over multiarena malloc has been
	measured for some benchmarks.

	Thread local cache is turned off by default. It can only
	be turned on by setting _M_CACHE_OPTS.

	Note: The thread local cache depends on a change in
	libpthread which is supplied in libpthread patch
	PHCO_19666. If _M_CACHE_OPTS is configured to activate
	cache on a system which does not have PHCO_19666
	installed, the configuration is ignored and cache is not
	used.

	Heapsize calculation was corrected to give accurate
	values with no overcounting. A nonlocking API
	(__mallstat) to report heapsize has been provided.
	__mallstat() is a new HP-private API. It is planned to
	be expanded for other types of statistics reporting.

	Assertions have been turned off around mutex operations.

	stdlib.h has been included in libc_init.c. This supplies
	the function prototype for getenv().

	Details about the thread local cache:

	For each thread, the thread local cache layer sets up a
	private cache to which access is effectively nonthreaded,
	so no mutex lock is required on access. Since mutex
	locking is expensive, this gives a significant
	performance improvement. The thread local cache saves
	blocks of sizes that have previously been used, and thus
	may be requested again. It also provides deferred
	coalescence of freed blocks: allocations from cache are
	never split, and cached blocks are not coalesced.

	The size of the cache is configurable by the number of
	free pointers allocated. Once all the free pointers are
	in use, in the current implementation, we never remove
	anything from the cache to make room for something new.

	The cache is organized as powers of 2 buckets. I.e.
	there will be a bucket for all blocks in the size range
	64 - 127 bytes, another for 128 - 255 bytes and so on.
	Blocks are linked in the bucket in order of decreasing
	size. This allows a (somewhat) better than linear search
	for the best fit to a request. Currently, buckets from
	2^0-31 are permitted, and the maximum is configurable.
	The low end buckets are unused due to alignment, header
	and padding overhead, and small block grain.

	The number of cache pointers, number of buckets, and
	the retirement time are configured by the environment
	variable _M_CACHE_OPTS. E.g.

	export _M_CACHE_OPTS=1024:32:20

	This means that "__bucket_size" is 1024, "__buckets"
	is 32, and "__retirement_age" is 20*60 secs (20 minutes).
	[Note that in the environment variable, retirement age
	is expressed in minutes, while in the internal variable
	__retirement_age it is stored as seconds.] The number of
	cache pointers, which equals the maximum number of buffers
	that will be cached for the thread as a result of calls to
	free() is __bucket_size*__buckets, or, for this example,
	is 1024*32 = 32K.

	If _M_CACHE_OPTS is undefined, or if it is defined but
	__bucket_size is 0, then cache is disabled. If
	__retirement_age is 0, retirement is disabled. The maximum
	value for __bucket_size is 8*4096. The minimum is 0. The
	maximum value for __buckets is 32. The minimum is 8. The
	maximum value for __retirement_age is 24*60*60 seconds
	(24 hours), which the user would specify in the environment
	variable as 1440 minutes (24*60). The minimum value is 0.

	When a thread exits, its cache is stored for reuse and it
	is timestamped. As threads are created, they reuse
	available caches.  As threads are created or exit, if the
	__retirement_age is nonzero they check whether the
	difference between the timestamps of unused caches and the
	current time have exceeded the __retirement_age. Those
	caches that have been unused for longer than
	__retirement_age are retired, i.e. all their memory is
	freed with _free(). [Note that retirement is not guaranteed
	to occur exactly at the time when __retirement_age is
	reached, and there are possible scenarios in which unused
	caches are never retired because no thread exits or starts
	up.]

	The mimimum number of arenas that may be configured
	via _M_ARENA_OPTS has been reduced from 4 to 1. Configuring
	1 arena approximates pre-multiarena behavior; with this
	configuration, a program that launches threads sequentially
	will not experience large increases in memory consumption
	due to round-robin thread allocation to arenas.

	Alternatively, activating cache allows blocks allocated by
	the first thread to be reused in subsequent threads.
	JAGaa40240, JAGaa01969, JAGab19981, JAGab16523, JAGab43915
	JAGaa26400, JAGab43837, JAGab53676, JAGab19980

	regexec() matches "." in empty string "" with locales
	other than C.

	Resolution:
	regexec(3C) was matching a "."  in an empty string "".
	The problem was due to an out-of-bound array access
	without checking the end-of-string.  The changes made
	are only to make sure that the accesses are valid.
	JAGaa53114; SR 4701413906

	PHCO_19491:
	Libc does not know about the Magic Cookie that identifies
	the these new filesystem types that will be enabled in the
	future.

	Resolution:
	Add to the statfsdev module the identifiers for the
	new filesystem types.
	JAGab68821; SR 8606102818

	PHCO_19391:
	In a multithreaded application, if one of the threads
	vforks() and does an exec(2) call(except the execve(2)
	call) there is a possibility of a deadlock in the other
	threads.

	Memory leak in applications using vfork and exec(2)
	calls except execve(2) call.

	Resolution:
	Fixed the deadlock in a multithreaded application,
	if one of the threads vforks() and does an exec(2)
	call(except the execve(2) call).

	Fixed the memory leak in applications using vfork and
	exec(2) calls (except execve(2) call).
	JAGaa55615

	Libc provides JFS ACL support through two new acl(2)
	syscall:
	        acl()
	        aclsort()
	JAGaa95281;SR 4701420935

	Libc provides JFS support through a routine called
	__fstatvxfs().  Currently, __fstatvxfs() implementation
	supports only VxFS disk layout version 2 and version 3.
	__fstatvxfs() needs to be updated to support the new
	VxFS disk layout, version 4.

	Resolution:
	The following set of APIs in libc has been enhanced to
	understand a VxFS filesystem with the new version 4 disk
	layout:
	fstatvfsdev
	fstatvfsdev64
	statvfsdev
	This is accomplished via updating __fstatvxfs() to
	understand VxFS disk layout version 4.
	JAGaa95281;SR 4701420935

	PHCO_19090:
	atoi() calls the ctype routines isdigit() and isspace()
	(although the call to isdigit() has been replaced by a
	local macro in a later version). The ctype APIs are defined
	only for ints -1 through 255.  Any other argument causes
	undefined behavior.

	In our implementation, an invalid code passed to a ctype
	API translates into an invalid array index which can lead
	to the retrieval of an invalid value or to a segmentation
	fault.

	So when atoi passes a char of value greater than 127,
	the char (signed) is implicitly converted to an int and
	sign extension takes place since the high bit is 1. The
	resulting corrupted value is then received by the ctype
	API and causes undefined behavior.

	Resolution:
	All ctype APIs called in atoi() are passed an unsigned
	char to avoid sign extension corrupting the value.
	JAGab25446, JAGaa05164; SR 8606100279

	PHCO_18227:
	When the corefile generated by abort(3C) is read by DDE,
	one of the things it checks in the stackUnwindDescriptor
	is if the frame where the PC is is an alloca frame. If it
	is an alloca frame, it needs to find the StackPointer in
	gr3. It will then check all the frames more recent than
	the one where it found the alloca frame to see if any
	procedure saved off the callee save registers. If no frame
	saved them, it will use the gr3 found in the save_state.
	Note that the callee saved register are not saved into the
	save_state in syscallinit unless the process is being
	traced.  The calling convention only requires a callee
	saved register to be written to the stack if a function
	would modify it.  Hence, in the normal path of a system
	call, the user register content may not be written out
	to the stack at all; it could only be saved at context
	switch, or it might be saved/restored on a kernel stack
	at the entry/exit of a function that modifies the
	register.  What appears to be happening is the callee
	saves are not preserved when we enter the syscall _kill().

	Resolution:
	Libc API abort(3C) can save the callee save registers
	when entering this procedure.
	JAGaa43927; SR 5003443143

	If the last week of the previous year is 52 and a week
	contains days in the previous years and less than 4 days
	in the new year, strftime() returns week number 52 for
	those days in the previous year and 53 for those in the
	new year.

	Resolution:
	Changed strftime() to return the week number of the last
	week of the previous year for weeks containing days in
	the previous year and less than 4 days in the new year.
	JAGaa46298

	Enhance current implementation to provide multiple arenas,
	each with it's own lock, from where malloc can allocate.
	Threads are distributed amongst these arenas, and thus
	increasing performance due to reduced lock contention.

	Resolution:
	This patch provides multiple arenas, where malloc can
	allocate space from, and a lock for each arena. Threads
	are distributed among the arenas. Two HP-UX environment
	variables have been introduced, _M_ARENA_OPTS, and
	_M_SBA_OPTS.
	(1) _M_ARENA_OPTS can be used to tune the number of
	arenas and the arena expansion factor. In general, the
	more threads in an application, the more arenas should
	be used for better performance. Expansion factor
	controls how many pages to expand each time, assuming
	the page size is 4096 bytes. The number of arenas can be
	from 4 to 64 for threaded applications. For non-threaded
	applications, only one arena is used. If the environment
	variable is not set, or the number of arenas is set to
	be out of the range, the default number of 8 will be
	used. The expansion factor is from 1 to 4096, default
	value is 32. Again, if the factor is out of the range,
	the default value will be used. To use _M_ARENA_OPTS,
	$ export _M_ARENA_OPTS=8:32
	This means the number of arenas is 8, and the expansion
	size is 32*4096 bytes.
	In general, the more arenas you use, the smaller the
	expansion factor should be, and vice versa.
	(2) _M_SBA_OPTS is to turn on the small block allocator,
	and set up parameters for the small block allocator,
	namely, "maxfast", "grain", "num_smallblocks". (see
	man page of mallopt() for details about small block
	allocator, and its parameters.) Applications with
	small block allocator turned on usually run faster
	than with it turned off. Small block allocator can be
	turned on through mallopt(); however, it is not early
	enough for C++/Java applications. The environment
	variable turns it on before the application starts.
	Mallopt() call can still be used the same way. If the
	environment variable is set, and no small block
	allocator has been used, the subsequent mallopt()
	calls can still overwrite whatever is set through
	_M_SBA_OPTS. If the environment variable is set, and
	small block allocator has been used, then mallopt()
	will have no effect. To use this environment variable,
	$ export _M_SBA_OPTS=512:100:16
	This means the maxfast size is 512, the number of small
	blocks is 100, and the grain size is 16.
	You have to supply all 3 values, and in that order. If
	not, the default ones will be used instead.
	(3) _M_ARENA_OPTS has no effects on non-threaded cases,
	while _M_SBA_OPTS has.
	(4) For even better performance gains, the following
	2 patches (or later ones) are recommended, PHKL_16368
	(libpthread) and PHKL_16236 (kernel).
	JAGaa32680

	With the porting of OSF code for locales, the performance
	of strcoll degraded up to 20 times. This happens because
	of the generic architecture of locale engine, slow shared
	library access and use of inefficient algorithms. The
	performance has been enhanced a lot for single byte
	locales with this fix by using better algorithms.
	JAGaa00524; SR 1653214346

	Single byte locales did not collate properly when an old
	version of single byte locale (using multi-byte routines
	for single byte locales) is used with new version of libc
	(where single byte routines are used for single byte
	locales). The original change was made in 10.10.
	JAGaa18768, JAGaa18769

	Some applications attempt to statically link with libc
	to improve performance. This can lead to call graph
	failures because a archive bound application is depending
	on a shared library. Use of libcres.a will eliminate this
	problem because there are no external dependencies in this
	library.

	Resolution:
	Prior to this patch the only way to link various string
	and memory functions archived was to link libc archived.
	This leads to problems with runtime failures when the
	dependent libc.sl changes and the the archive linked code
	can no longer resovle the required symbols.  libcres.a
	contains most of the string and memory functions and a few
	 other functions that make no calls to other routines. Some
	applications may see a performance improvement linking this
	library archive while linking the rest of the application
	shared.
	JAGaa43395

	Internal libc routines need to support VxVM volume pathname
	conventions.
	JAGaa42843

	The libc routine memchr( ) does not perform well when static
	branch prediction is enabled on executables due to a lot
	branches being  misprediced . This is a performance hit
	when memchr is called a lot of times in executables.
	JAGaa13890, JAGaa41248

	mktime() always returns 0 for tm_isdst, regardless
	of whether daylight savings is in effect for dates beyond
	Tuesday January 19 03:14:07 UTC 2038.  Since strptime()
	obtains this value from mktime(), it also returns the
	incorrect value for tm_isdst for those dates.

	Resolution:
	There is no timezone adjustment rule for years past 2038
	that can be used to correctly determine the value of
	tm_isdst.  To work around this for now, the rule for the
	year 2038 is used for those years.
	JAGaa16206, SR 4701405688, JAGaa23230 SR 4701405696,
	JAGaa23233 SR 4701405720

	strptime() needs to check if the return value of
	mktime() is within the range of seconds that it supports
	because mktime() supports a much wider range of dates
	than strptime() in 64-bit mode.

	Resolution:
	strptime() was modified to check the return value of
	mktime() to determine if the input date is within the
	supported range, which is Friday December 13 20:45:52
	UTC 1901 and Friday December 31 23:59:59 UTC 9999.
	JAGaa23231 SR 4701405704, JAGaa23232 SR 4701405712

	In 64-bit HP-UX, getdate() needs to check if the return
	value of mktime() is within the range of seconds that it
	supports because mktime() supports a much wider range of
	dates than getdate().

	Resolution:
	getdate() was modified to check the return value of
	mktime() to determine if the input date is within the
	supported range, which is Friday December 13 20:45:52
	UTC 1901 and Tuesday January 19 03:14:07 UTC 2038 (in
	32-bit HP-UX) or Friday December 31 23:59:59 UTC 9999
	(for 64-bit HP-UX).
	JAGaa26931 SR 4701409581

	PHCO_18103:
	getcwd() was using memcmp() with two structures which
	were not properly initialized.

	Resolution:
	Replaced memcmp() call in getcwd() with comparison of
	individual fields in the two structures.
	JAGaa95447

	PHCO_17601:
	The problem was caused by excessive locking of /etc/mnttab
	in the getmntent(3X) family of APIs, and by incorrect use
	of the getmntent(3X) APIs by commands such as mount(1M)
	and umount(1M).

	Resolution:
	In the patch, setmntent(3X) no longer uses a read lock
	when opening the mnttab file, and a new API, delmntent(3X),
	has been developed for use by commands that delete entries
	from the mnttab file.  Use of this patch will avoid a
	possible deadlock situation during concurrent invocations
	of mount(1M) or other commands that write to or read from
	/etc/mnttab.

	Excerpts From the Changed getmntent(3X) Man Page:

	      int delmntent(FILE *stream, struct mntent *mnt);

	DESCRIPTION
	   delmntent()

	Deletes all entries from the file stream opened
	with setmntent that match both mnt_fsname and
	mnt_dir in mntent structure mnt. If mnt_fsname is
	a null pointer, all entries that match mnt_dir
	will be deleted. If mnt_dir is a null pointer, all
	entries that match mnt_fsname will be deleted. It
	is an error if both mnt_fsname and mnt_dir are
	null pointers.  Note that stream must be opened
	via setmntent for reading and writing (r+ or a+).
	Upon return from the call to delmntent, the file
	position indicator for the stream will point to
	EOF.

	 RETURN VALUE
	      setmntent()

	Returns a null pointer on error.  setmntent()
	attempts to establish an exclusive write lock on
	the file it is opening, ie: when one of the
	following types is passed to setmntent() to open
	the file for write/update: "w", "a", "r+", "w+",
	or "a+".  If setmntent() cannot get the lock, it
	returns a null pointer and sets errno to either
	EACESS or EAGAIN.

	      delmntent()
	Returns -1 on error.   Sets errno to EINVAL if
	stream or mnt are null pointers, or if both
	mnt_fsname and mnt_dir in mntent structure mnt
	are null pointers.  Sets errno to EBADF if stream
	has been opened for read (r), append (a), or
	write (w).  If the operation is successful,
	returns the number of entries deleted from the file.
	When no entries are matched, delmntent returns 0
	and does not set errno.

	      endmntent()
	Returns 1, and unlocks the file if it was locked
	by setmntent().

	 EXAMPLES
	   The following code deletes an entry:

	        struct mntent mnt_entry;
	        FILE *fp;
	        int retval = NOT_DELETED;

	        mnt_entry.mnt_fsname = "/dev/vg03/lvol7";
	        mnt_entry.mnt_dir = "/disk7";

	        if ((fp = setmntent(MNT_MNTTAB, "r+")) != NULL) {
	             if (delmntent(fp, &mnt_entry) > 0)
	                  retval = DELETED;
	             (void)endmntent(fp);
	        }
	        return(retval);
	JAGaa01122, JAGaa01628

	The first instruction of strlen() was a movb,=,n. The
	condition code used is a 32 bit extract/deposit condition
	code. Hence, if the lower 32 bits of address happen to be
	zero the condition is satisfied and the branch is taken.
	The same problem existed in the other three interfaces.

	Resolution:
	Changed the movb,=,n instruction to a cmpb,*=/copy
	sequence. This instruction is functionally the same as
	the movb,= but will work correctly for 64 bit addresses.
	JAGaa93445; SR 4701418293

	For certain years, strftime() with %V returns two
	different week numbers for days in a week which
	contains days in the previous year and less than 4
	days in the new year.  If there are less than 4 days
	in the new year, it returns week number 53 for those
	days, regardless of whether there is a week 53 in the
	previous year; otherwise, it returns 1.  It returns 52
	or 53 for the days in the previous year.  The week
	number for the days in the new year should be the last
	week of the previous year, if there are less than 4 days
	in the new year in that week.  In addition, the week
	number for the days in the previous year should be the
	same as that for the days in the new year.

	---

	Resolution:
	Changed strftime() to return the week number of the
	last week of the previous year for all days in a week
	containing days in the previous year and less than 4
	days in the new year.  Return 1 for all days in the
	week if there are 4 or more days in the new year.
	JAGaa62691

	An internationalized application encounters the memory
	leak at every

	                setlocale(category, locale);

	call to change the locale environment under any
	condition except:

	o LC_ALL environment variable is not set;
	o Category parameter is LC_ALL; and
	o Locale parameter is (explicitly specified) "C" or
	  "POSIX".

	Most internationalized applications call the setlocale()
	function in the form of:

	                setlocale(LC_ALL, "");

	and encounter the memory leak if the call is made more
	than once.  Therefore, this patch should be installed
	if an application needs to call the setlocale() function
	more than once.

	Resolution:
	Necessary memory to save the locale specific information
	used to be dynamically allocated at every setlocale()
	call without freeing the memory allocated by the previous
	call.  The implementation has been changed to free the
	previously allocated memory at every call before
	allocating the new memory.
	JAGaa92941; SR 1653294694

	A socket used in libc times out, causing synchronization
	loss and connection reliability problems.

	Resolution:
	The problem was solved by comparing the returned values
	to that in the request.
	JAGaa46458, JAGaa72866; SR 1653284414

	The check for whether the root directory has been
	reached in the case of a Loop Back File System (LOFS)
	was not done correctly in getcwd().

	Resolution:
	Changed getcwd() to fill in the entire mystat structure
	for the current directory and its parent directory and
	then compare the entire two structures.  The previous
	code only compares the inode and device numbers.  This
	change ensures that cases where the inode and device
	numbers are the same for both the current and parent
	directory will be handled correctly.

	An example of this, prior to apply the fix to getcwd(),
	follows:

	# mount /stand /stand/lofs
	# cd /stand/lofs/build
	# pwd
	/build   /* path obtained from getcwd() */

	This is because the inode and device numbers for lofs
	and stand are the same:

	build:  {ino = 4226; dev = 0x40000001; fstype = lofs;
	  fsid = 0xff000004}
	lofs:   {ino = 5376; dev = 0x40000001; fstype = lofs;
	  fsid = 0xff000004}
	stand:  {ino = 5376; dev = 0x40000001; fstype = ufs;
	  fsid = 0         }
	/:      {ino = 2;    dev = 0x40000001; fstype = ufs;
	  fsid = 0         }
	JAGaa86037; SR 4701414862

	PHCO_16629:
	memcmp(3C) returns incorrect values when compiled with
	+DA2.0N.  This is due to some recent performance
	optimizations that were done on memcmp, which introduced
	a problem where 64 bit registers are compared with 32 bit
	compare instructions. This causes the upper 32 bits to be
	ignored, which causes memcmp to return incorrect values.

	memcmp also performs 64 bit compare operations on 32 bit
	operands passed as parameters to these routines. This could
	cause problems with high optimization which could leave the
	upper 32 bits dirty and hence make memcmp return unexpected
	results.
	JAGaa41144, JAGaa41248; SR 5003438507

	The performance of malloc has been improved by changing
	the way the free memory blocks are maintained.
	JAGaa17260

	Parameters between 64-bit C code and 64-bit assembly
	code were being passed incorrectly.
	JAGaa35268, JAGaa32697, JAGaa40380

	There was a performance degrade in some cases.
	JAGaa40211

	The ELF version of the linker enables SHLIB_PATH by
	default.
	JAGaa22065

	setjmp/longjmp did not call the CXperf tool function
	with the correct first parameter.
	JAGaa32076

	A performance enhancement for threaded applications
	changed the grain size causing threaded applications
	to use more memory.
	JAGaa32072

	PHCO_16130:
	If old 10.20 locale which uses multi-byte routines
	is used and it has collating element e.g. spanish,
	strcoll and wcscoll will not perform correctly.
	JAGaa18768, JAGaa18769

	strptime(3C) returns an error when the %E conversion
	specification is used in the C locale.  It does not
	fill in the tm_wday, tm_mon and tm_mday fields in the
	tm structure when both the year and day of year are
	supplied.  It does not support dates beyond January
	19 UTC 2038 in 32-bit HP-UX.  It does not indicate
	an error when a date that is out-of-range or
	inconsistent input is provided.  The resulting values
	of tm_wday and tm_yday are off by 1 when tm_sec and/or
	tm_min are initialized to -1 when the %j conversion
	specification is used.
	JAGaa06544; SR 5003416719

	strptime() returns the same values for the tm_mday, tm_mon,
	tm_yday and tm_wday fields in the tm structure for Feb 29
	2000 and March 1 2000 if %A (or %a) and %U conversion
	specifications are used.  The output for March 1 2000 is
	incorrect.
	JAGaa13581; SR 1653269738

	A call to getcwd() will fail if the root file system
	is a loopback file system.  This will not normally be
	the case, but if chroot() has been called to set the
	root directory, then this could be a loopback file
	system (LOFS).  A specific example of this is when
	the anonymous ftp home directory is a LOFS as ftpd
	will then use chroot() and can report:

	550 getcwd: No such file or directory

	JAGaa11165, JAGaa01441, JAGaa05219, JAGaa06021
	SR#4701382374

	getenv runs very slow for multi-byte languages like
	ja_JP.SJIS. The performance for single-byte
	languages is as good as C locale. JAGaa05075
	SR#1653259333

	getdate() fails to find a matching template when %r is used
	in a template and there is at least one other template that
	contains %H or %R, even though a matching template exist.
	It also returns an error if a template contains %I but not
	%p and a matching template exists.JAGaa00429, JAGaa10165,
	JAGaa10166, JAGaa10167, JAGaa10168,JAGaa05222, JAGaa10164,
	JAGaa10163, JAGaa08067, JAGaa10158,JAGaa12392

	The libc routine memcmp( ) does not perform well when static
	branch prediction is enabled on executables due to the
	high branch misprediction. This is a performance hit when
	memcmp is called a lot of times in executables. JAGaa06535

	PHCO_15768:
	A flag in __regcomp_std() was set incorrectly which
	caused the "match end of line" not being recognized.
	Setting of the flag is corrected.  JAGaa01206

	Commands dump core if LC_COLLATE is set to non C
	locale but LC_CTYPE is set to C locale. If there
	is no difference between LC_COLLATE and LC_CTYPE,
	there is no problem. JAGaa01206

	The calculation for length of string in __strnlen() API
	for 64-bit mode was incorrect. JAGaa01674

	The previous syslog code, in some places, kept filling
	the buffers without checking for the buffer limits.
	Once the size of buffers were exceeded a core dump
	would occur. JAGaa01271

	Original usleep(3C) code didn't have the functionality to
	handle multi-threaded applications. Now it uses
	sigtimedwait(2) for handling threaded applications.
	JAGaa01457

	When Null pointer was being passed as argument for fputs
	and puts, fputs should return 0 and write nothing to the
	file, puts should return 1 and write '\n' to stdout.
	JAGaa01279 JAGaa01511 JAGaa01513 JAGaa01515

	The 5th and 8th arguments are corrupted during the course
	of execution of syscall() API. JAGaa04782

	The fix to setjmp() function in patch PHCO_14102 didn't
	take care of case where the program is compiled with
	64-bit mode (+DA2.0W) and -z compiler option.
	JAGaa01982

	PHCO_14704:
	"struct stat64" in the internal 64-bit interfaces
	(i.e. __ftw64(), __nftw64() and __nftw2_64()) needs to
	be changed to "struct stat" to be consistent with the
	changes made to ftw.h to provide Large Files support
	for C++ applications.  This change is needed in order
	for libc to compile with the changes in ftw.h and has
	no effect on functionality. JAGaa01664.

	Mutex was not released before returning to the
	caller when sigspace() is called by the process
	running on the alternate signal stack; a single
	memory space was shared among all threads within
	a process. JAGaa01033 JAGaa01062

	There was an assumption that more than 254 arguments
	wouldn't be passed to execvp().  This number was
	hard-coded in the implementation. JAGaa00583

	Enhancement request for providing a new threads API
	__thread_detach(). JAGaa01380

	An internal function called by glob() attempts to free()
	the same block twice. JAGaa01494

	This is an enhancement request to provide jmp_buf pointer
	in the hook functions of HP CXDL Development Tool. These
	hooks are called from setjmp() and longjmp() APIs while
	applications are linked with HP CXDL Development Tool.
	JAGaa01603

	Memccpy() doesn't detect the value of 0 at address 0.
	JAGaa01280

	This regcomp() defect was caused by copying one NULL
	string pointer to another without any checking.
	JAGaa01396, JAGaa01496, JAGaa01497

	strptime(3C) does not produce the correct week number for
	dates in a year that begins on a Sunday or a Monday.
	JAGaa00976 1653231456

	getlogin(3) API in libc returns NULL when the tty is
	console. Hence the utilities like passwd print error
	messages when they use getlogin() API to access the
	login name of the user. JAGaa00533 5003380394

	The gets(3S) API can fail to release a lock after
	encountering an EOF condition.  This will cause another
	thread in the application doing an i/o operation on stdin
	to hang, leading potentially to an application deadlock.
	JAGaa01583 5003394833.

	Code cleanup done in getcwd.c. User behavior unchanged.
	JAGaa01101

	PHCO_14102:
	The problem was introduced with the addition of a new
	symbol in API malloc().

	Support for CXperf performance tool was added in
	setjmp/longjmp() family of calls. If application is run
	with CXperf tool, then setjmp/longjmp() APIs have mechanism
	coded in order to gather correct performance statistics.

	HP-UX enforces that variable lengthes should not exceed
	1024. In catopen(3C), the string that represents the
	variable LANG was strcpy'ed into a buffer with a fixed
	size MAXPATHLEN (1024). This caused
	coredump when strlen(LANG) is longer than 1024.

	The size of the string, passed to perror, plus message was
	not checked and could have become larger than the size of
	the allocated output buffer.  In such situations perror
	would have coredumped.

	Signal mask was not restored for this corner case.

	This problem only occurs when 1) large malloc has been
	enabled, ie: the M_ENABLE_MMAP command has been passed to
	mallopt(), and 2) the initial size request to malloc() is
	so large that malloc() searches all 4 memory quadrants and
	it is unable to find a large enough block.

	In the event that times(2) fails in a multi-threaded
	application, clock(3C) does not release the mutex.  This
	will cause the next thread that invokes clock() to wait
	forever for the mutex, in effect, causing the application
	to loop forever.

	NIS uses dbm to to manage its data.  Because of unlucky
	splitting, the '.pag' file has a large empty area which
	causes the NIS file transfer to fail because it takes
	longer than 25 seconds for dbm to get between keys.

	PHCO_13412:
	The assembly code expects the quad floating point
	information to be passed by address. The C code that calls
	it is passing it by value. In 32-bit this pass by value
	would be converted to an address. In 64-bit it is passed by
	value.

	PHCO_13283:
	The setjmp(3c)/longjmp(3c) APIs did not have a mechanism
	which enabled correct performance statistics to be gathered
	with the HP CXDL Development Tools.

	The implementation of the wcswidth(3c) API fails to
	comply with specification if the locale dependent
	version of wcswidth does not comply.

	When calling sigsetjmp() and then siglongjmp() from
	non-position independent code. GR is not saved.

SR:
	8606186527 8606165366 8606177629 8606178299 8606179946
	8606172344 8606188513 8606196866 8606185984 8606133330
	8606164457 8606170481 8606172179 8606162140 8606128089
	8606130241 8606152550 8606129543 8606175166 8606143128
	8606102984 8606147002 8606134279 8606141866 8606156311
	8606129009 8606140246 8606136018 8606126100 5003424531
	8606125006 8606125009 8606125010 8606125320 8606125513
	8606107568 8606104124 8606106738 8606106516 8606104837
	5003444117 5003463463 8606103064 4701389726 1653297432
	4701413906 8606102818 4701420935 8606100279 5003443143
	1653214346 4701405688 4701405696 4701405720 4701405704
	4701405712 4701409581 4701414862 1653294694 1653284414
	4701418293 5003438507 5003416719 1653269738 4701374496
	4701374470 4701374504 4701376756 5003392126 1653228304
	1653119560 5003156760 5003380394 1653231456 1653259333
	4701382374

Patch Files:
	
	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libc.a
	/usr/lib/libcres.a

	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libc.a
	/usr/lib/pa20_64/libcres.a

	OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libc.2

	OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libc.2

	ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libp/libc.a

	ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
		fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libp/libc.a

	ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libpicc.a

what(1) Output:
	
	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libc.a:
		$ PATCH/11.00:PHCO_24148  May 25 2001 08:03:42 $

	ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libp/libc.a:
		$ PATCH/11.00:PHCO_24148  May 25 2001 08:27:55 $

	ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libpicc.a:
		$ PATCH/11.00:PHCO_24148  May 25 2001 08:07:25 $

	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libc.a:
		$ PATCH/11.00:PHCO_24148  May 25 2001 09:33:52 $

	ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
		fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libp/libc.a:
		$ PATCH/11.00:PHCO_24148  May 25 2001 09:35:49 $

	OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libc.2:
		$ PATCH/11.00:PHCO_24148  May 25 2001 08:06:41 $

	OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libc.2:
		$ PATCH/11.00:PHCO_24148  May 25 2001 09:31:33 $

	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/libcres.a:
		$ PATCH/11.00:PHCO_24148  May 23 2001 12:50:28 $

	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/lib/pa20_64/libcres.a:
		$ PATCH/11.00:PHCO_24148  May 23 2001 12:50:45 $

cksum(1) Output:
	
	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	1049793219 2177980 /usr/lib/libc.a

	ProgSupport.PROG-AUX,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	2255115791 2552960 /usr/lib/libp/libc.a

	ProgSupport.PROG-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	97218991 2318744 /usr/lib/libpicc.a

	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	3519354466 3647638 /usr/lib/pa20_64/libc.a

	ProgSupport.PROG-AX-64ALIB,fr=B.11.00,
		fa=HP-UX_B.11.00_32/64,v=HP:
	3481702690 4046268 /usr/lib/pa20_64/libp/libc.a

	OS-Core.CORE-SHLIBS,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	983118366 1552384 /usr/lib/libc.2

	OS-Core.CORE-64SLIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	1372935405 1559872 /usr/lib/pa20_64/libc.2

	OS-Core.C-MIN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	1588808779 68052 /usr/lib/libcres.a

	OS-Core.C-MIN-64ALIB,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	2962318642 67342 /usr/lib/pa20_64/libcres.a

Patch Conflicts: None

Patch Dependencies:
	s700: 11.00: PHCO_23092 PHKL_20236
	s800: 11.00: PHCO_23092 PHKL_20236

Hardware Dependencies: None

Other Dependencies:
	PHCO_24148: JAGab20870
	The tzset()  behaviour  have been changed to take default TZ
	values  from  the file /etc/default/tz.  A  sample  file  is
	released as patch PHCO_23652.  The /etc/default/tz  included
	in  the  patch  contains  the  earlier  default  value  ie.,
	EST5EDT.  So unless the user  explicitly  changes  the value
	contained in the file the tzset changes are  transparent  to
	the user.  The file  /etc/default/tz  contains  the timezone
	value set by tzset() when the environment variable TZ is not
	set.  The format  for the file is same as TZ format  without
	the prefix  "TZ=".  Please check  environ(5)  for TZ format.
	The order of TZ setting is as follows.
	1) if the environment variable TZ is present, it takes the
	   precedence.
	2) if TZ is not present, then the value contained in
	   /etc/default/tz is used for default.
	3) if /etc/default/tz is not set, then the default value is
	   equivalent to EST5EDT (Eastern Standard Time) of US.

Supersedes:
	PHCO_13283 PHCO_13412 PHCO_14102 PHCO_14704 PHCO_15768 PHCO_16130
	PHCO_16629 PHCO_17601 PHCO_18103 PHCO_18227 PHCO_19090 PHCO_19391
	PHCO_19491 PHCO_19691 PHCO_20369 PHCO_20555 PHCO_20763 PHCO_20765
	PHCO_22076 PHCO_22314 PHCO_22923 PHCO_23770

Equivalent Patches: None

Patch Package Size: 00 KBytes

Installation Instructions:
	Please review all instructions and the Hewlett-Packard
	SupportLine User Guide or your Hewlett-Packard support terms
	and conditions for precautions, scope of license,
	restrictions, and, limitation of liability and warranties,
	before installing this patch.
	------------------------------------------------------------
	1. Back up your system before installing a patch.

	2. Login as root.

	3. Copy the patch to the /tmp directory.

	4. Move to the /tmp directory and unshar the patch:

		cd /tmp
		sh PHCO_24148

	5. Run swinstall to install the patch:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -s /tmp/PHCO_24148.depot

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHCO_24148.  If you do not wish to retain a
	copy of the original software, use the patch_save_files option:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -x patch_save_files=false -s /tmp/PHCO_24148.depot

	WARNING: If patch_save_files is false when a patch is installed,
		 the patch cannot be deinstalled.  Please be careful
		 when using this feature.

	For future reference, the contents of the PHCO_24148.text file is 
	available in the product readme:

		swlist -l product -a readme -d @ /tmp/PHCO_24148.depot

	To put this patch on a magnetic tape and install from the
	tape drive, use the command:

		dd if=/tmp/PHCO_24148.depot of=/dev/rmt/0m bs=2k

Special Installation Instructions:
	If libc patches are installed without rebooting,
	applications currently running which are linked shared
	against libc will still continue using the former version of
	libc.  If this presents a problem to any applications, you
	should reboot.

