 |
» |
|
|
|
|  | |
Code compiled on 9.x systems, and not re-linked or recompiled
on 10.x, will run on 10.x without problems, unless it does one of
the following: Invokes hard-coded pathnames that
no longer exist as of 10.0 (see the section on the HP-UX 10.0 filesystem
in the Release Notes). Uses mknod(1M)
to create device files with 9.x names or major and minor numbers
(see the section on I/O convergence in the Release Notes). (But system default device-file names such as /dev/lp
are still supported on 10.x.) Invokes HP-UX commands or command options that are
no longer supported as of 10.0 or whose meaning or behavior has
changed (see the sections on shells and commands in the Release
Notes). Invokes HP-proprietary library routines for HP-UX
"diskless" clusters (see “HP-UX ("DUX")
Clusters No Longer Supported ” later in this chapter). Invokes HP-proprietary NLS (Native Language Support)
routines that are no longer supported as of 10.0 (see “NLS Routines
No Longer Supported ”
later in this chapter). Invokes certain libc
routines on a system on which transition links
have been turned off (see the section on libraries in the Release
Notes). The links are in effect by default on all 10.x systems (see
“Upgrade Tools ”). Mixes libc
pattern-matching routines in unusual ways (see “Pattern-Matching
Routines Mixed in Unusual Ways ” later in this
chapter). Uses shadow password routines or the shadow password
file (see “Shadow Password
Routines ” later in this
chapter). Uses NetIPC routines that are no longer supported
(see “NetIPC Routines
No Longer Supported ” later in this
chapter.) Uses certain routines that have been changed for
reasons of standards conformance or I/O convergence (see “Other Changes
Affecting Applications ”
later in this chapter.)
Run the prepare(update_aid)
tool to check application source code for these conditions and,
optionally, to create copies with the correct pathnames for 10.x.
See the previous chapter for instructions. The following potential problems will not
be caught by prepare
and analyzer;
they are described in more detail later in this chapter. An application may behave differently
if it depends on 9.x math library error handling. See “Changes in
Error Handling for Math Library Functions ” later in this chapter. Programs that run correctly on 9.x could encounter
problems on 10.x because of a 9.0 linker bug. The software included in the package that accompanies this
manual (the "Upgrade Preparation Media" package) includes tools
to check for the existence of such problems and fix them; see “Linker Defects”
later in this chapter for details. Applications will get different behavior on floating-point
convert-to-integer overflow. The 9.x behavior was incorrect, and inconsistent between the
Series 700 and 800. It has been corrected; see “Floating-Point
to Integer Conversion ” later in this
chapter.
The sections that follow provide some general guidelines for
portability between HP-UX releases, and specific guidance for some
of the cases in the list above. Guidelines
for Writing Portable Applications | |
To make sure an application will port as easily as possible
from one HP-UX release to another (not just from 9.x to 10.x), a
programmer should: Avoid using archive libc
with other shared libraries (even libdld.sl). Use archived libc
only if the entire application is linked archived. ("Archived" means bound at link time; "shared" means bound
at run time). Compatibility problems could arise when libc interfaces are
resolved out of both shared and archived libc.
In the case of libdld.sl,
the compatibility problems could arise when a program tries to load
a shared library that has dependencies on libc.sl. Avoid using both archived and shared libc
or making libc
an explicit dependency of other shared libraries. Compatibility problems could arise when libc
calls are resolved out of both shared and archived libc,
either directly or via a dependent shared library. The general rule is: always link with the shared
version of libc
whenever any other shared libraries are being used. Avoid linking applications with the -B immediate
option; and avoid using BIND_IMMEDIATE
when loading libc
with shl_load(3X). The reasons for this are: Using these options forces all symbols to be bound at startup
time, even symbols that are not required by the application. If
one of the symbols is not in a future release, the application will
no longer load. libc
was versioned in the past and may be again in the future. If an
older version of a symbol depends on other symbols which are not
present, then the application will not load.
Specific Guidelines
for Moving Code from 9.x to 10.x | |
This section describes conditions for which programmers should
check their code, and change the code if they exist, before moving
the application from a 9.x to 10.x system. Pattern-Matching
Routines Mixed in Unusual Ways This section outlines the problems that could arise if your
code uses: Combinations with 10.x glob(3C)
or 10.x regcomp(3C) 10.x wordexp(3C)
and pre-10.0 wordfree(3C)
These combinations are not likely to occur. But if they did,
it would be when some 10.x code (the "allocation" routine) is dynamically
loaded — via shl_findsym(3X)
for example — and some pre-10.0 code from libc
(the "execution" or "deallocation" routine) is linked archived into
an application or dependent library. Combinations with 10.x glob(3C) or 10.x regcomp(3C)The combinations in question are: 10.x glob(3C)
and pre-10.0 globfree(3C). 10.x regcomp(3C)
and pre-10.0 regexec(3C)
or pre-10.0 regfree(3C).
Direct call If the application code calling glob(3C)
and globfree(3C)
is compiled and linked in this manner on a pre-10.0 system — cc -Wl,+e,__dld_loc -Wl,+e,errno -Wl,+e,_end -Wl,+e,malloc -Wl, \\
-a,archive main.c -l:libdld.sl |
— and the application is then run on 10.x, it will
receive a SIGSEGV signal while executing the globfree(3C) code: 0x00003514 _globfre+001c OR 1,0,4
0x00003518 _globfre+0020 COMIBT,= 0,26,_globfree+0048
0x0000351c _globfre+0024 STW 26,12(0,1)
0x00003520 _globfre+0028 ADDIL 0x0,27
0x00003524 _globfre+002c OR 1,0,5
0x00003528 _globfre+0030 LDWS 0(0,26),31
0x0000352c _globfre+0034 BL free,2
0x00003530 _globfre+0038 STW 31,16(0,5)
0x00003534 _globfre+003c LDW 16(0,5),26
0x00003538 _globfre+0040 COMIBF,= 0,26,_globfree+0030
File: unknown Procedure: _globfree + 0x00000030 Line: unknown
segmentation violation (no ignore) at 0x00003528
(file unknown): _globfree +0x00000030: (line unknown)
>t
0 _globfree + 0x00000030 (0, 0, 0, 0)
... |
Similarly, an application combining 10.x regcomp(3C)
with pre-10.0 regexec(3C)
or regfree(3C)
(in the manner described for globfree
above) will receive a SIGSEGV
signal while executing regexec
or regfree code. Unless a SIGSEGV
signal handler is installed, the system will generate a core dump
and terminate the program. Remedy: Recompile and relink the application on
10.x, thus eliminating all pre-10.0 modules. Indirect call from shared library If the application code calls glob(3C)
indirectly from a dependent shared library that is relinked on 10.x
and calls globfree(3C)
directly, then the application will get a load error and abort. For example, if the application is compiled and linked in
this manner on a pre-10.0 system — cc -Wl,-a,archive -l:libdld.sl main.c -L. -l:libfoo.sl |
— and the library is then recompiled and linked in
this manner on a 10.x system — cc -c +z foo.c
ld -b foo.o -o libfoo.sl |
— then the application will get a load error and
abort when it is run on 10.x; for example: /usr/lib/dld.sl: Unresolved symbol: _end (data) from /lib/libc.sl
/usr/lib/dld.sl: Unresolved module for symbol: _curbrk (data) from /lib/libc.sl
/usr/lib/dld.sl: Unresolved module for symbol: malloc (code) from /lib/libc.sl
Abort(coredump) |
Similarly, the application will get a load error and abort
if it combines 10.x regcomp(3C)
and pre-10.0 regexec(3C)
or regfree(3C)
in the manner just described. Remedy: Recompile and relink the application on
10.x, thus eliminating all pre-10.0 modules. 10.x wordexp(3C) and pre-10.0 wordfree(3C) Combining wordexp(3C)
and wordfree(3C)
directly, in a manner similar to that shown for glob
and globfree
above, will not cause a SIGSEGV
signal, but will result in the pre-10.0 wordfree
behavior: a memory leak of up to strlen+16
bytes for each string in the we_wordv
list. (See the wordexp
manpage on a 9.x or 10.x system for a description of we_wordv.) Combining wordexp
and wordfree
indirectly, in a manner similar to that shown for glob
and globfree
above, will result in the same type of behavior as in the example
under "Indirect Call from Shared Library": unresolved symbols at
load time. Remedy: Recompile and relink the application on
10.x, thus eliminating all pre-10.0 modules. The shadow password routines listed in the table below have
been moved to a separate library for 10.x: libsec. In addition, the standard password routines fgetpwent(3C),
getpwaid(3C),
getpwent(3C),
getpwnam(3C),
getpwuid(3C)
and their re-entrant counterparts no longer call the corresponding
shadow password routines automatically in 10.x. Results of calling password routines from 9.x executable
on 10.x The shadow password routines have been stubbed out in the
10.x libc; the
functional routines are in libsec.
The shadow password file /.secure/etc/passwd
does not exist in 10.x. See the table below for the effects on 9.x
code. The table that follows shows the results a 9.x executable
that calls the password routines will get on 10.x. Results depend
on the type of system, how the library code was linked and which
routines are called. |
----------------------------------------------------------
| | On 10.x Trusted | On 10.x Regular |
|9.x | System | System |
|executable | | |
|calling: | code linked | code linked |
| | shared archived | shared archived |
|------------|----------|----------|----------|----------|
|setspwent | | return void; |
|setspwent_r | | errno set to ENOENT |
|------------| |--------------------------------|
|endspwent | error | |
|endspwent_r | | return void; errno unchanged |
|------------| message |--------------------------------|
|fgetspwent | | |
|fgetspwent_r| and | |
|getspwaid | | return NULL; |
|getspwaid_r | abort; | |
|getspwent | | errno set to ENOENT; |
|getspwent_r | see | |
|getspwnam | | see Notes (3) and (4) |
|getspwnam_r | Note (1)| |
|getspwuid | | |
|getspwuid_r | | |
|------------| |--------------------------------|
|putspwent | | returns -1; errno set to |
| | | ENOENT; see Note (4) |
|------------|-------------------------------------------|
|standard | | |
|password | set password field | |
|routines | to "*" and audit | ok; no change from |
|(setpwent, | fields to -1; see | 9.x |
|etc.) | Note (2) | |
----------------------------------------------------------------- |
|
See remedies and notes below. Remedy if calling fgetspwent(3C)
and putspwent(3C): see Note 4. Remedy for all other cases: recompile
and relink the application on 10.x, naming the security library
explicitly in the compile or link statement(for example: cc -o main
main.c -lsec).
NOTES Note 1 The stubbed shadow password routines in libc
will not access the new trusted systems database. An error message
will be displayed on stderr
and the program will exit with an exit status of 1. Note 2 This result is ambiguous because a "*" is returned both when
the shadow password file cannot be opened and when the caller is
not UID 0. (But you can tell the difference from errno:
it is set to ENOENT
if the file can't be opened, and to EACCES
if the caller is not UID 0.) Note 3 These routines will return NULL
because they can't open the pre-10.0 shadow password file /.secure/etc/passwd,
which does not exist on 10.x. If the application is linked with
the ld(1) -z
option and the NULL
return value is dereferenced, the program will get a SIGSEGV
signal. Unless the program has a SIGSEGV
signal handler, it will abort with a core dump. Note 4 fgetspwent(3C)
and putspwent(3C)
will not work on 10.x if the calling application uses them for reading
or updating /.secure/etc/passwd,
because that file no longer exists. Refer to the 10.x getprpnam(3)
manpage for replacement routines. If the application uses these routines to maintain a password
file other than /.secure/etc/passwd,
these routines will work on 10.x as they did before. See the section on Commercial Security in the Release
Notes for more information. HP-UX ("DUX")
Clusters No Longer Supported HP-UX Clusters are no longer supported as of 10.0. The "DUX" and context-dependent file routines have been stubbed
out in 10.x. The results of calling these routines are summarized
in the table that follows. Note the special case of getcontext(),
which is an entirely new routine as of 10.0. |
Linked shared Linked archived
Routine (uses 10.x libc) (used pre-10.0 libc)
===========================================================
cnodes returns 0 returns 0
cnodeid returns 1 returns 1
setccent returns void; returns void;
errno set to ENOENT errno set to ENOENT
endccent returns void; returns void;
errno set to ENOENT errno is unchanged
fgetccent
getcccid return NULL; return NULL;
getccent errno set to ENOENT errno set to ENOENT
getccnam
ftwh returns -1; works like ftw
errno set to EOPNOTSUPP
getcdf returns NULL; returns NULL;
errno set to EOPNOTSUPP errno set to ENOENT
getcontext gets SVID3-compliant returns -1;
(different) behavior errno set to EOPNOTSUPP
gethcwd returns NULL; works like getcwd
errno set to EOPNOTSUPP
hidecdf returns NULL; context-dependent components
errno set to EOPNOTSUPP are not hidden
mkrnod returns -1; returns -1;
errno set to EOPNOTSUPP errno set to EOPNOTSUPP
nftwh returns -1; works like nftw
errno set to EOPNOTSUPP |
Remedy: No direct replacements. NLS Routines
No Longer Supported The following Native Language Support routines and macros
are not present in the 10.x libc: byte_status(3C) nl_isalpha(3C)
c_colwidth(3C) nl_iscntrl(3C)
catgetmsg(3C) nl_isdigit(3C)
catread(3C) nl_isgraph(3C)
currlangid(3C) nl_islower(3C)
firstof2(3C) nl_isprint(3C)
fprintmsg(3C) nl_ispunct(3C)
getmsg(3C) nl_isspace(3C)
ICONV(3C) nl_isupper(3C)
iconvclose(3C) nl_isxdigit(3C)
iconvlock(3C) nl_msg(3C)
iconvopen(3C) nl_printf(3C)
iconvsize(3C) nl_scanf(3C)
idtolang(3C) nl_sprintf(3C)
langinfo(3C) nl_sscanf(3C)
langinit(3C) nl_strcmp(3C)
langtoid(3C) nl_strncmp(3C)
nl_asctime(3C) nl_strtod(3C)
nl_ascxtime(3C) nl_tolower(3C)
nl_atof(3C) nl_toupper(3C)
nl_catopen(3C) printmsg(3C)
nl_ctime(3C) secof2(3C)
nl_cxtime(3C) sprintmsg(3C)
nl_fprintf(3C) strcmp16(3C)
nl_fscanf(3C) strcmp8(3C)
nl_gcvt(3C) strncmp16(3C)
nl_init(3C) strncmp8(3C)
nl_isalnum(3C) |
When linked into an archived 9.x executable and run on 10.x,
these routines will behave the same as on 9.x (in conjunction with
9.x locales, which are still supported on 10.x; these routines will
not support the 10.x locales). When these routines are linked into a shared 9.x executable,
the application will abort on 10.x, because the routines are not
in libc. The
abort message will say something like: /usr/lib/dld.sl: Unresolved symbol: catgetmsg (code) from ./foo
Abort(coredump) |
Remedy: See the section on NLS in the chapter on
commands and libraries in the Release Notesfor alternative routines. 8.x Applications Linked Archived These will not work in internationalized mode, because the
8.x locales are not provided on 10.x. But you can copy the 8.x locales
onto the 10.x system if you need them. See the section on NLS in the chapter on commands and libraries
in the Release Notes. NetIPC Routines
No Longer Supported The following Network Interprocess Communication (NetIPC)
routines are not present in the 10.x libc: addopt(3N) ipcname(3N)
initopt(3N) ipcnamerase(3N)
ipcconnect(3N) ipcrecv(3N)
ipccontrol(3N) ipcrecvcn(3N)
ipccreate(3N) ipcselect(3N
ipcdest(3N) ipcsend(3N)
ipcerrmsg(3N) ipcsetnodename(3N)
ipcerrstring(3N) ipcshutdown(3N)
ipcgetnodename(3N) optoverhead(3N)
ipclookup(3N) readopt(3N) |
The results of calling these routines are summarized in the
table that follows. When linked shared When linked archived
Routine (uses 10.x libc) (used pre-10.0 libc)
===========================================================
addopt
initopt
ipcerrmsg Abort (note 1) 9.x behavior
ipcerrstring
optoverhead
readopt
ipcconnect
ipccontrol
ipccreate
ipcdest
ipcgetnodename
ipclookup
ipcname Abort (note 1) SIGSYS signal/abort
ipcnamerase (note 2)
ipcrecv
ipcrecvcn
ipcselect
ipcsend
ipcsetnodename
ipcshutdown |
NOTES: Note 1: The application will be abort because the routines are not
in libc. The
abort message will say something like: /usr/lib/dld.sl: Unresolved symbol: addopt (code) from ./foo
Abort(coredump) |
Note 2: The application will receive a SIGSYS
signal when one of these routines is called. Unless the program
has SIGSYS signal
handler, it will terminate with a core dump. The abort message will
say: Bad system call(coredump) |
Remedy: Use BSD Sockets instead of NetIPC. See NetIPC
to BSD Sockets Migration Guide (HP part number
98194-90045). For additional ARPA transport information, see the
manual Installing and Administering LAN/9000
Software (HP part number 98194-90050). Changes in
Error Handling for Math Library Functions As of Release 10.0, error handling for math library functions
has been updated where necessary to conform to the latest version
of the X/Open Portability Guide (XPG4). The math library manpages
describe the 10.x error handling for each function in detail. There is no longer any difference
between error handling in libm
(the SVID library) and libM
(the XPG4 library). XPG4 is a superset of SVID3, and the two standards do not
conflict. The most visible change is that the libm
library functions no longer produce DOMAIN,
SING, PLOSS,
or TLOSS error
messages. If XPG4 does not require a function to set errno,
the function does not set it. For example, most library functions used to set errno
to EDOM if a
function argument was a NaN
(Not-a-Number);
they no longer do so, though they continue to return a NaN.
The table that follows describes the changes in error handling
for each function. Error handling is described in terms of the return value and
the errno setting.
For example, NaN, EDOM
means that NaN
is returned and errno is set to EDOM. |
Function 9.0 libm 9.0 libM 10.0
===========================================================
Most, NaN args NaN, EDOM NaN, EDOM NaN, 0
Most, underflow 0, ERANGE 0, ERANGE 0,0
(scalb is the only function still required to set errno
to ERANGE in the case of underflows.)
acos(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
acos(|x|>1.0) 0, EDOM NaN, EDOM 0, EDOM
acosd(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
acosd(|x|>1.0) 0, EDOM NaN, EDOM 0, EDOM
acosf(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
acosf(|x|>1.0) NaN, EDOM NaN, EDOM 0, EDOM
acosdf(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
acosdf(|x|>1.0) NaN, EDOM NaN, EDOM 0, EDOM
acosh: no change except for NaN arguments
asin(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
asin(|x|>1.0) 0, EDOM NaN, EDOM 0, EDOM
asind(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
asind(|x|>1.0) 0, EDOM NaN, EDOM 0, EDOM
asinf(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
asinf(|x|>1.0) NaN, EDOM NaN, EDOM 0, EDOM
asindf(+-INF) NaN, EDOM NaN, EDOM 0, EDOM
asindf(|x|>1.0) NaN, EDOM NaN, EDOM 0, EDOM
asinh: no change except for NaN arguments
atan: no change except for NaN arguments |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
atan2(0,0) 0, EDOM 0, EDOM NaN, 0
atan2d(0,0) 0, EDOM 0, EDOM NaN, 0
atan2df(0,0) 0, EDOM 0, EDOM NaN, 0
atan2f(0,0) 0, EDOM 0, EDOM NaN, 0
atand: no change except for NaN arguments
atandf: no change except for NaN arguments
atanf: no change except for NaN arguments
atanh(+-1) NaN, EDOM NaN, EDOM NaN, 0
cabs(overflow) HUGE_VAL, HUGE_VAL, HUGE_VAL, 0
ERANGE ERANGE
cbrt(negative) 0, EDOM 0, EDOM result, 0
cbrtf(negative) 0, EDOM 0, EDOM result, 0
copysign: no change
copysignf: no change
cos(large arg) 0, ERANGE 0, ERANGE result, 0
cos(+-INF) 0, ERANGE NaN, EDOM NaN, 0
cosd(large arg) 0, ERANGE 0, ERANGE result, 0
cosd(+-INF) 0, ERANGE NaN, EDOM NaN, 0
cosdf(large arg) 0, ERANGE 0, ERANGE result, 0
cosdf(+-INF) 0, ERANGE NaN, EDOM NaN, 0
cosf(large arg) 0, ERANGE 0, ERANGE result, 0
cosf(+-INF) 0, ERANGE NaN, EDOM NaN, 0 |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
cosh: no change except for NaN arguments
coshf: no change except for NaN arguments
drem(x, 0) NaN, 0 NaN, 0 NaN, EDOM
drem(+-INF, y) NaN, 0 NaN, 0 NaN, EDOM
exp(+INF) HUGE_VAL, HUGE_VAL, +INF, 0
ERANGE ERANGE
exp(-INF) 0, ERANGE 0, ERANGE 0, 0
expf(+INF) HUGE_VAL, HUGE_VAL, +INF, 0
ERANGE ERANGE
expf(-INF) junk, 0 +INF, 0 0, 0
fabs: no change except for NaN arguments
fabsf: no change except for NaN arguments
finite: no change
finitef: no change
floor: no change except for NaN arguments
fmod(x, 0) x, 0 NaN, EDOM NaN, EDOM
fmodf(x, 0) x, 0 NaN, EDOM NaN, EDOM
hypot(overflow) HUGE_VAL, HUGE_VAL, HUGE_VAL, 0
ERANGE ERANGE
isinf: no change
isinff: no change
isnan: no change
isnanf: no change
j0(large values) 0, ERANGE 0, ERANGE result, 0
j1(large values) 0, ERANGE 0, ERANGE result, 0
jn(large values) 0, ERANGE 0, ERANGE result, 0 |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
lgamma(int <= 0) HUGE_VAL, HUGE_VAL, HUGE_VAL,
EDOM EDOM 0
lgamma(overflow) HUGE_VAL, HUGE_VAL, HUGE_VAL,
ERANGE ERANGE 0
lgamma(+INF) NaN, ERANGE NaN, EDOM NaN, 0
lgamma(-INF) HUGE_VAL, HUGE_VAL, HUGE_VAL,
ERANGE ERANGE 0
log(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
log(negative) -HUGE_VAL, -HUGE_VAL, NaN, EDOM
EDOM EDOM
log10(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
log10(negative) -HUGE_VAL, -HUGE_VAL, NaN, EDOM
EDOM EDOM
log10f(0) -MAXFLOAT, -MAXFLOAT, -MAXFLOAT,
EDOM EDOM 0
log10f(negative) -MAXFLOAT, +INF, EDOM NaN, EDOM
EDOM
log2(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
log2(negative) -HUGE_VAL, -HUGE_VAL, NaN, EDOM
EDOM EDOM
log2f(0) -MAXFLOAT, -MAXFLOAT, -MAXFLOAT,
EDOM EDOM 0
log2f(negative) -MAXFLOAT, -MAXFLOAT, NaN, EDOM
EDOM EDOM |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
logf(0) -MAXFLOAT, -MAXFLOAT, -MAXFLOAT,
EDOM EDOM 0
logf(negative) -MAXFLOAT, +INF, EDOM NaN, EDOM
EDOM
logb(0) -INF, 0 -INF, 0 -HUGE_VAL,
EDOM
modf: no change
pow(-INF, +even int) 1, 0 1, 0 +INF, 0
pow(-INF, +odd int) -1, 0 -1, 0 -INF, 0
pow(-INF, -even int) 1, 0 1, 0 0, 0
pow(-INF, -odd int) -1, 0 -1, 0 0, 0
pow(0, 0) 0, EDOM 1, 0 1, 0
pow(0, negative) 0, EDOM -HUGE_VAL, -HUGE_VAL,
EDOM EDOM
pow(negative, +-INF) 0, EDOM NaN, EDOM NaN, 0
pow(neg., non-int) 0, EDOM NaN, EDOM NaN, EDOM
powf(0, 0) NaN, EDOM NaN, EDOM 1, 0
powf(0, negative) NaN, EDOM NaN, EDOM -HUGE_VAL,
EDOM
powf(x>1, +INF) -HUGE_VAL, -HUGE_VAL, +INF, 0
EDOM EDOM
powf(x>1, -INF) 0, EDOM 0, EDOM +INF, 0
powf(0<x<1, -INF) 0, EDOM 0, EDOM 0, 0
powf(0<x<1, +INF) HUGE_VAL, HUGE_VAL, 0, 0
EDOM EDOM
powf(0, negative) NaN, EDOM NaN, EDOM -HUGE_VAL,
EDOM
powf(negative, +INF) NaN, EDOM NaN, EDOM NaN, 0
powf(negative, -INF) -INF, 0 -INF, 0 NaN, 0
rint: no change except for NaN arguments |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
scalb(overflow) +INF, 0 +INF, 0 +-HUGE_VAL,
ERANGE
scalb(underflow) 0, 0 0, 0 0, ERANGE
sin(large arg) 0, ERANGE 0, ERANGE result, 0
sin(+-INF) 0, ERANGE NaN, EDOM NaN, 0
sind(large arg) 0, ERANGE 0, ERANGE result, 0
sind(+-INF) 0, ERANGE NaN, EDOM NaN, 0
sindf(large arg) 0, ERANGE 0, ERANGE result, 0
sindf(+-INF) 0, ERANGE NaN, EDOM NaN, 0
sinf(large arg) 0, ERANGE 0, ERANGE result, 0
sinf(+-INF) 0, ERANGE NaN, EDOM NaN, 0
sinh: no change except for NaN arguments
sinhf: no change except for NaN arguments
sqrt(negative) 0, EDOM NaN, EDOM NaN, EDOM
sqrtf: no change
tan(large arg) 0, ERANGE 0, ERANGE result, 0
tan(+-INF) 0, ERANGE NaN, EDOM NaN, 0
tand(large arg) 0, ERANGE 0, ERANGE result, 0
tand(+-INF) 0, ERANGE NaN, EDOM NaN, 0
tandf(large arg) 0, ERANGE 0, ERANGE result, 0
tandf(+-INF) 0, ERANGE NaN, EDOM NaN, 0 |
|
|
Function 9.0 libm 9.0 libM 10.x
===========================================================
tanf(large arg) 0, ERANGE 0, ERANGE result, 0
tanf(+-INF) 0, ERANGE NaN, EDOM NaN, 0
tanh: no change except for NaN arguments
tanhf: no change except for NaN arguments
y0(negative) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM EDOM 0
y1(negative) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM EDOM 0
yn(negative) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM EDOM 0
y0(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
y1(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
yn(0) -HUGE_VAL, -HUGE_VAL, -HUGE_VAL,
EDOM ERANGE 0
y0(large values) 0, ERANGE 0, ERANGE result, 0
y1(large values) 0, ERANGE 0, ERANGE result, 0
yn(large values) 0, ERANGE 0, ERANGE result, 0 |
If a program depends on the 9.x math library error handling,
it may behave differently on a 10.x system if it uses shared libraries
or if it is recompiled on 10.x. A program that linked in an archive
library on a pre-10.0 system will continue to behave as it did before. Floating-Point
to Integer Conversion The behavior of an overflow exception on a floating-point
convert-to-integer operation has been modified so as to be consistent
on the Series 700 and 800, and to comply with the IEEE Standard
and the behavior documented in the HP-UX Floating-Point
Guide, HP part number B3906-90003. In previous releases, the Series 800 took a floating-point
exception on this conversion even if all traps were disabled. In
9.x, the Series 700 did not generate a floating point exception;
instead the result was truncated to MAXINT/MININT
and the OVERFLOW
bit was set. Both of these behaviors were incorrect according to the IEEE
specification, and did not accord with what was documented in the
HP-UX Floating-Point Guide. The correct behavior is not to trap with a floating-point
exception if traps are disabled, but return MAXINT/MININT,
set the INVALID
bit, and raise an FP
exception only if the INVALID
trap-enable bit is on. This is the behavior of HP-UX 10.x on both
the Series 700 and 800. You can enable traps for some or all of these conditions by
using the fpsetdefaults
function, the fpsetmask
function, the +T
option (f77 only),
or the +FP compiler
option. For more information, see Chapter 5 of the HP-UX
Floating-Point Guide. Other Changes
Affecting Applications Standards Conformance Changes The following routines have been changed in 10.x for standards
conformance. Routine Reason
===========================================================
iconv(3C) XPG4.2 conformance: function now returns
size_t rather than ssize_t.
nftw(3C) XPG4.2 conformance: passes FTW_SLN rather
than FTW_SL for a dangling symlink.
see the entry for this command in Chapter
6 of the Release
Notes for more
information.
openlog(3C) XPG4.2 conformance: functions now return
syslog(3C) void rather than int. Note: function
closelog(3C) prototypes for these functions were not
delivered before 10.0.
tcsendbreak(3C) SVID3 conformance: the "duration"
parameter is no longer ignored its
value is used to alter the function's
behavior. |
The following routine has been changed to support I/O convergence
(see the section on IO convergence in the Release Notes): dial(3C) Device name suffix was 3 characters on
9.x Series 700; 4 characters on 9.x
Series 800. It is 4 characters on 10.x. |
The /bin/ld
and /lib/dld.sl
released at 9.0 had a pair of defects that could cause a program
that runs correctly on a 9.x system to work incorrectly on 10.x
systems. Fixes for these defects are included in the "Upgrade Tools"
package that includes this manual; see “Locating and Loading Tools and Documentation”. The problem could result in the wrong version of a symbol
being used; or, if the version which would be used is unavailable,
an unsatisfied symbol error may occur. The defect occurs when a shared library is built with an explicit
dependency on a second shared library that uses versioned symbols.
The summary version information recorded in the first shared library
can be incorrect. This can cause problems for any program or shared
library which uses the first shared library. Affected programs or shared libraries should be re-linked
on a 9.x system using the latest linker patch, (PHSS_5290 or later)
using the shared library versions that were current when the program
or the shared library with the problem was built. You should re-link affected programs or shared libraries on
a 9.x system using the tools provided in this package
(see “Locating and Loading Tools and Documentation”), and the
shared library versions that were current when the program or the
shared library with the problem was built. Don't re-link with newer versions of the shared libraries;
if you do, the re-link will cause the program or shared libraries
to pick up the newer versioned symbols, which may not be what the
program or shared library needs. The tools are: The program chkversion. This indicates whether the programs or shared libraries you
specify are affected by this problem. The script chksysver. This examines all of the programs and shared libraries on
a system.
See the chkversion(1M)
and chksysver(1M)
manpages (included in this package) for more details. Do tasks in the following order: Load the tools from the upgrade tape or disk as described
in Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”. Run chksysver(1M)
to check all the shared libraries and programs on the system. This could take from one to two hours. (Example times: 45
minutes on a 755 using 4Gb of data. 1 hour and 45 minutes on a 720
using 3Gb of data.) If you know that only specific programs or libraries could
have the problem, use chkversion(1M)
instead. See the manpages for more information. If chksysver
or chkversion
reports any problems: Load the new version of dld.sl
from the PHSS_5290 patch. Relink the affected programs and libraries. You must do this as soon as you have downloaded the new version
of /lib/dld.sl;
otherwise the affected code will now encounter the same errors when
you try to run it on 9.x as it would on 10.01. Re-link shared libraries with the patched linker, then re-link
any shared libraries or programs which depend upon the corrected
shared library. If you re-link a shared library, re-link the programs
and shared libraries which depend upon it. For example, if the report generated by chksysver
says, Y has incorrect version information |
— then you need to re-link Y. If the report says, X has incorrect version information for Y |
— then you need to re-link X
(you should have already re-linked Y). Log in as root and run a script to correct version-propagation
behavior in the affected libraries: /usr/contrib/bin/install_verfix -uninstall |
See the chksysver(1M)
manpage for more information.
The highwater mark of a shared library should be the maximum
of the highest version number of any symbol defined by the shared
library and the highwater mark of any of the shared libraries mentioned
on the link line which created the shared library. A defect in the 9.0 /bin/ld
caused the highwater marks of the dependent libraries to be ignored,
which can cause an incorrect highwater mark to be recorded in a
shared library. This can cause problems for a a program or another
shared library which uses a shared library with the wrong highwater
mark. A defect in /lib/dld.sl
allowed these defective programs to run without an apparent error. |
Printable version
