HP OpenVMS Systems Documentation
Convert a time value to broken-down local time.
#include <time.h>Function Variants Compiling with the _DECC_V4_SOURCE and _VMS_V6_SOURCE feature-test macros defined enables a local-time-based entry point to the localtime_r function that is equivalent to the behavior before OpenVMS Version 7.0.
struct tm *localtime (const time_t *timer);
struct tm *localtime_r (const time_t *timer, struct tm *result); (ISO POSIX-1)
timerA pointer to a time in seconds since the Epoch. You can generate this time by using the time function or you can supply a time.
resultA pointer to a tm structure where the result is stored. The tm structure is defined in the <time.h> header file, and is also shown in Table REF-4.
The localtime and localtime_r functions convert the time (in seconds since the Epoch) pointed to by timer into a broken-down time, expressed as a local time, and store it in a tm structure.
The difference between the localtime_r and localtime functions is that the former stores the result into a user-specified tm structure. The latter stores the result into thread-specific static memory allocated by the HP C RTL, and which is overwritten by subsequent calls to localtime ; you must make a copy if you want to save it.
On success, localtime returns a pointer to the tm structure; localtime_r returns its second argument. On failure, these functions return the NULL pointer.
The tm structure is defined in the <time.h> header file and described in Table REF-4.
Table REF-4 tm Structure int tm_sec ; Seconds after the minute (0-60) int tm_min ; Minutes after the hour (0-59) int tm_hour ; Hours since midnight (0-23) int tm_mday ; Day of the month (1-31) int tm_mon ; Months since January (1-11) int tm_year ; Years since 1900 int tm_wday ; Days since Sunday (0-6) int tm_yday ; Days since January 1 (0-365) int tm_isdst ; Daylight Savings Time flag
- tm_isdst = 0 for Standard Time
- tm_isdst = 1 for Daylight Time
long tm_gmtoff ;1 Seconds east of Greenwich (negative values indicate seconds west of Greenwich) char * tm_zone ;1 Time zone string, for example "GMT"
The type time_t is defined in the <time.h> header file as follows:
typedef long int time_t
Generally speaking, UTC-based time functions can affect in-memory time-zone information, which is processwide data. However, if the system time zone remains the same during the execution of the application (which is the common case) and the cache of timezone files is enabled (which is the default), then the _r variant of the time functions asctime_r , ctime_r , gmtime_r and localtime_r , is both thread-safe and AST-reentrant.
If, however, the system time zone can change during the execution of the application or the cache of timezone files is not enabled, then both variants of the UTC-based time functions belong to the third class of functions, which are neither thread-safe nor AST-reentrant.
x Pointer to a tm structure. NULL Indicates failure.
Return the logarithm of their arguments.
double log (double x);
float logf (float x); (ALPHA ONLY)
long double logl (long double x); (ALPHA ONLY)
double log2 (double x); (ALPHA ONLY)
float log2f (float x); (ALPHA ONLY)
long double log2l (long double x); (ALPHA ONLY)
double log10 (double x);
float log10f (float x); (ALPHA ONLY)
long double log10l (long double x); (ALPHA ONLY)
xA real number.
The log functions compute the natural (base e) logarithm of x.
The log2 functions compute the base 2 logarithm of x.
The log10 functions compute the common (base 10) logarithm of x.
x The logarithm of the argument (in the appropriate base). - HUGE_VAL x is 0 ( errno is set to ERANGE), or x is negative ( errno is set to EDOM). NaN x is NaN; errno is set to EDOM.
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.
There are Alpha specific, nonstandard decc$setjmp and decc$fast_longjmp functions. 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.10 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 .
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.