HP OpenVMS Systems Documentation
Computes ln(1+y) accurately.
double log1p (double y);
float log1pf (float y);
long double log1pl (long double y);
yA real number greater than - 1.
The log1p functions compute ln(1+y) accurately, even for tiny y.
x The natural logarithm of (1+ y). - HUGE_VAL y is less than - 1 ( errno is set to EDOM), or y = - 1 ( errno is set to ERANGE). NaN y is NaN; errno is set to EDOM.
Returns the radix-independent exponent of the argument.
double logb (double x);
float logbf (float x);
long double logbl (long double x);
xA nonzero, real number.
The logb functions return the exponent of x, which is the integral part of log2|x|, as a signed floating-point value, for nonzero x.
x The exponent of x. - HUGE_VAL x = 0.0; errno is set to EDOM. +Infinity x is +Infinity or - Infinity. NaN y is NaN; errno is set to EDOM.
Provides a way to transfer control from a nested series of function invocations back to a predefined point without returning normally; that is, by not using a series of return statements. The longjmp function restores the context of the environment buffer.
void longjmp (jmp_buf env, int value);
envThe environment buffer, which must be an array of integers long enough to hold the register context of the calling function. The type jmp_buf is defined in the <setjmp.h> header file. The contents of the general-purpose registers, including the program counter (PC), are stored in the buffer.
valuePassed from longjmp to setjmp , and then becomes the subsequent return value of the setjmp call. If value is passed as 0, it is converted to 1.
When setjmp is first called, it returns the value 0. If longjmp is then called, naming the same environment as the call to setjmp , control is returned to the setjmp call as if it had returned normally a second time. The return value of setjmp in this second return is the value you supply in the longjmp call. To preserve the true value of setjmp , the function calling setjmp must not be called again until the associated longjmp is called.
The setjmp function preserves the hardware general-purpose registers, and the longjmp function restores them. After a longjmp , all variables have their values as of the time of the longjmp except for local automatic variables not marked volatile . These variables have indeterminate values.
The setjmp and longjmp functions rely on the OpenVMS condition-handling facility to effect a nonlocal goto with a signal handler. The longjmp function is implemented by generating a HP C RTL specified signal and allowing the OpenVMS condition-handling facility to unwind back to the desired destination. The HP C RTL must be in control of signal handling for any HP C image.
For HP C to be in control of signal handling, you must establish all exception handlers through a call to the VAXC$ESTABLISH function (rather than LIB$ESTABLISH ). See Section 4.2.5 and the VAXC$ESTABLISH function for more information.
The C RTL provides nonstandard decc$setjmp and decc$fast_longjmp functions for Alpha and Integrity server systems. To use these nonstandard functions instead of the standard ones, a program must be compiled with the __FAST_SETJMP or __UNIX_SETJMP macros defined.
Unlike the standard longjmp function, the decc$fast_longjmp function does not convert its second argument from 0 to 1. After a call to decc$fast_longjmp , a corresponding setjmp function returns with the exact value of the second argument specified in the decc$fast_longjmp call.
You cannot invoke the longjmp function from an OpenVMS condition handler. However, you may invoke longjmp from a signal handler that has been established for any signal supported by the HP C RTL, subject to the following nesting restrictions:
- The longjmp function will not work if invoked from nested signal handlers. The result of the longjmp function, when invoked from a signal handler that has been entered as a result of an exception generated in another signal handler, is undefined.
- Do not invoke the setjmp function from a signal handler unless the associated longjmp is to be issued before the handling of that signal is completed.
- Do not invoke the longjmp function from within an exit handler (established with atexit or SYS$DCLEXH). Exit handlers are invoked after image tear-down, so the destination address of the longjmp no longer exists.
- Invoking longjmp from within a signal handler to return to the main thread of execution might leave your program in an inconsistent state. Possible side effects include the inability to perform I/O or to receive any more UNIX signals.
Returns the full name of the terminal.
#include <curses.h>Function Variants The longname function has variants named _longname32 and _longname64 for use with 32-bit and 64-bit pointer sizes, respectively. See Section 1.9 for more information on using pointer-size-specific functions.
void longname (char *termbuf, char *name);
termbufA string containing the name of the terminal.
nameA character-string buffer with a minimum length of 64 characters.
The terminal name is in a readable format so that you can double-check to be sure that Curses has correctly identified your terminal. The dummy argument termbuf is required for UNIX software compatibility and serves no function in the OpenVMS environment. If portability is a concern, you must write a set of dummy routines to perform the functionality provided by the database termcap in the UNIX system environment.
Generates uniformly distributed pseudorandom-number sequences. Returns 48-bit signed long integers.
long int lrand48 (void);
The lrand48 function generates pseudorandom numbers using the linear congruential algorithm and 48-bit integer arithmetic.
It returns nonnegative, long integers uniformly distributed over the range of y values such that 0 <= y < 231 .
Before you call the lrand48 function use either srand48 , seed48 , or lcong48 to initialize the random-number generator. You must initialize prior to invoking the lrand48 function, because it stores the last 48-bit Xi generated into an internal buffer. (Although it is not recommended, constant default initializer values are supplied automatically if the drand48 , lrand48 , or mrand48 functions are called without first calling an initialization function.)
The function works by generating a sequence of 48-bit integer values, Xi, according to the linear congruential formula:
Xn+1 = (aXn+c)mod m n >= 0
The argument m equals 248 , so 48-bit integer arithmetic is performed. Unless you invoke the lcong48 function, the multiplier value a and the addend value c are:
a = 5DEECE66D16 = 2736731631558 c = B16 = 138
The value returned by the lrand48 function is computed by first generating the next 48-bit Xi in the sequence. Then the appropriate bits, according to the type of data item to be returned, are copied from the high-order (most significant) bits of Xi and transformed into the returned value.
See also drand48 , lcong48 , mrand48 , seed48 , and srand48 .
n Signed nonnegative long integers uniformly distributed over the range 0 <= y < 2 31 .
Rounds to the nearest integer value, rounding according to the current rounding direction.
long lrint (double x);
long lrintf (float x);
long lrintl (long double x);
xA real value.
The lrint functions return the rounded integer value of x, rounded according to the current rounding direction.
n Upon success, the rounded integer value.
Rounds to the nearest integer value, rounding halfway cases away from zero regardless of the current rounding direction.
long lround (double x);
long lroundf (float x);
long lroundl (long double x);
xA real value.
The lround functions return the rounded integer value of x, with halfway cases rounded away from zero regardless of the current rounding direction.
n Upon success, the rounded integer value.
Positions a file to an arbitrary byte position and returns the new position.
off_t lseek (int file_desc, off_t offset, int direction);
file_descAn integer returned by open , creat , dup , or dup2 .
offsetThe offset, specified in bytes. The off_t data type is either a 32-bit or a 64-bit integer. The 64-bit interface allows for file sizes greater than 2 GB, and can be selected at compile time by defining the _LARGEFILE feature-test macro as follows:
directionAn integer indicating whether the offset is to be measured forward from the beginning of the file (direction=SEEK_SET), forward from the current position (direction=SEEK_CUR), or backward from the end of the file (direction=SEEK_END).
The lseek function can position a fixed-length record-access file with no carriage control or a stream-access file on any byte offset, but can position all other files only on record boundaries.
The available Standard I/O functions position a record file at its first byte, at the end-of-file, or on a record boundary. Therefore, the arguments given to lseek must specify either the beginning or end of the file, a 0 offset from the current position (an arbitrary record boundary), or the position returned by a previous, valid lseek call.
This function returns the new file position as an integer of type off_t which, like the offset argument, is either a 64-bit integer if _LARGEFILE is defined, or a 32-bit integer if not.
For a portable way to position an arbitrary byte location with any type of file, see the fgetpos and fsetpos functions.
If, while accessing a stream file, you seek beyond the end-of-file and then write to the file, the lseek function creates a hole by filling the skipped bytes with zeros.
In general, for record files, lseek should only be directed to an absolute position that was returned by a previous valid call to lseek or to the beginning or end of a file. If a call to lseek does not satisfy these conditions, the results are unpredictable.
See also open , creat , dup , dup2 , and fseek .
x The new file position. - 1 Indicates that the file descriptor is undefined, or a seek was attempted before the beginning of the file.
Retrieves information about the specified file.
int lstat (const char *restrict file_path, struct stat *restrict user_buffer);
file_pathThe name of the file for which you want to retrieve information.
user_bufferThe stat structure in which information is returned.
The lstat function retrieves information about the specified file (file_path). If the file is a symbolic link, information about the link itself is returned (in contrast to stat , which returns information about the file that the symbolic link points to).
See also symlink , unlink , readlink , realpath , and lchown .
0 Successful completion. -1 Indicates an error. errno is set to any errno value returned by stat .
Waits for I/O on a specific file to complete.
int lwait (int fd);
fdA file descriptor corresponding to an open file.
The lwait function is used primarily to wait for completion of pending asynchronous I/O.
0 Indicates successful completion. - 1 Indicates an error.
Allocates an area of memory. These functions are AST-reentrant.
#include <stdlib.h>Function Variants The malloc function has variants named _malloc32 and _malloc64 for use with 32-bit and 64-bit pointer sizes, respectively. See Section 1.9 for more information on using pointer-size-specific functions.
void *malloc (size_t size);
sizeThe total number of bytes to be allocated.
The malloc function allocates a contiguous area of memory whose size, in bytes, is supplied as an argument. The space is not initialized.
The malloc routines call the system routine LIB$VM_MALLOC. Because LIB$VM_MALLOC is designed as a general-purpose routine to allocate memory, it is called upon in a wide array of scenarios to allocate and reallocate blocks efficiently. The most common usage is the management of smaller blocks of memory, and the most important aspect of memory allocation under these circumstances is efficiency.
LIB$VM_MALLOC makes use of its own free space to satisfy requests, once the heap storage is consumed by splitting large blocks and merging adjacent blocks. Memory can still become fragmented, leaving unused blocks. Once heap storage is consumed, LIB$VM_MALLOC manages its own free space and merged blocks to satisfy requests, but varying sizes of memory allocations can cause blocks to be left unused.
Because LIB$VM_MALLOC cannot be made to satisfy all situations in the best possible manner, perform your own memory management if you have special memory usage needs. This assures the best use of memory for your particular application.
The OpenVMS Programming Concepts Manual explains the several memory allocation routines that are available. They are grouped into three levels of hierarchy:
- At the highest level are the RTL Heap Management Routines LIB$GET_VM and LIB$FREE_VM, which provide a mechanism for allocating and freeing blocks of memory of arbitrary size. Also at this level are the routines based on the concept of zones, such as LIB$CREATE_VM_ZONE, and so on.
- At the next level are the RTL Page Management routines LIB$GET_VM_PAGE and LIB$FREE_VM_PAGE, which allocate a specified number of contiguous pages.
- At the lowest level are the Memory Management System Services, such as $CRETVA and $EXPREG, that provide extensive control over address space allocation. At this level, you must manage the allocation precisely.
The maximum amount of memory allocated at once is limited to 0xFFFFD000.
x The address of the first byte, which is aligned on a quadword boundary (ALPHA ONLY) or an octaword boundary (INTEGRITY SERVERS ONLY) . NULL Indicates that the function is unable to allocate enough memory. errno is set to ENOMEM.