498 lines
22 KiB
HTML
498 lines
22 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of PCREJIT</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>PCREJIT</H1>
|
|
Section: C Library Functions (3)<BR>Updated: 17 March 2013<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
PCRE - Perl-compatible regular expressions
|
|
<A NAME="lbAC"> </A>
|
|
<H2>PCRE JUST-IN-TIME COMPILER SUPPORT</H2>
|
|
|
|
|
|
<P>
|
|
Just-in-time compiling is a heavyweight optimization that can greatly speed up
|
|
pattern matching. However, it comes at the cost of extra processing before the
|
|
match is performed. Therefore, it is of most benefit when the same pattern is
|
|
going to be matched many times. This does not necessarily mean many calls of a
|
|
matching function; if the pattern is not anchored, matching attempts may take
|
|
place many times at various positions in the subject, even for a single call.
|
|
Therefore, if the subject string is very long, it may still pay to use JIT for
|
|
one-off matches.
|
|
<P>
|
|
|
|
JIT support applies only to the traditional Perl-compatible matching function.
|
|
It does not apply when the DFA matching function is being used. The code for
|
|
this support was written by Zoltan Herczeg.
|
|
<A NAME="lbAD"> </A>
|
|
<H2>8-BIT, 16-BIT AND 32-BIT SUPPORT</H2>
|
|
|
|
|
|
<P>
|
|
JIT support is available for all of the 8-bit, 16-bit and 32-bit PCRE
|
|
libraries. To keep this documentation simple, only the 8-bit interface is
|
|
described in what follows. If you are using the 16-bit library, substitute the
|
|
16-bit functions and 16-bit structures (for example, <I>pcre16_jit_stack</I>
|
|
instead of <I>pcre_jit_stack</I>). If you are using the 32-bit library,
|
|
substitute the 32-bit functions and 32-bit structures (for example,
|
|
<I>pcre32_jit_stack</I> instead of <I>pcre_jit_stack</I>).
|
|
<A NAME="lbAE"> </A>
|
|
<H2>AVAILABILITY OF JIT SUPPORT</H2>
|
|
|
|
|
|
<P>
|
|
JIT support is an optional feature of PCRE. The "configure" option --enable-jit
|
|
(or equivalent CMake option) must be set when PCRE is built if you want to use
|
|
JIT. The support is limited to the following hardware platforms:
|
|
<P>
|
|
<BR> ARM v5, v7, and Thumb2
|
|
<BR> Intel x86 32-bit and 64-bit
|
|
<BR> MIPS 32-bit
|
|
<BR> Power PC 32-bit and 64-bit
|
|
<BR> SPARC 32-bit (experimental)
|
|
<P>
|
|
If --enable-jit is set on an unsupported platform, compilation fails.
|
|
<P>
|
|
|
|
A program that is linked with PCRE 8.20 or later can tell if JIT support is
|
|
available by calling <B>pcre_config()</B> with the PCRE_CONFIG_JIT option. The
|
|
result is 1 when JIT is available, and 0 otherwise. However, a simple program
|
|
does not need to check this in order to use JIT. The normal API is implemented
|
|
in a way that falls back to the interpretive code if JIT is not available. For
|
|
programs that need the best possible performance, there is also a "fast path"
|
|
API that is JIT-specific.
|
|
<P>
|
|
|
|
If your program may sometimes be linked with versions of PCRE that are older
|
|
than 8.20, but you want to use JIT when it is available, you can test
|
|
the values of PCRE_MAJOR and PCRE_MINOR, or the existence of a JIT macro such
|
|
as PCRE_CONFIG_JIT, for compile-time control of your code.
|
|
<A NAME="lbAF"> </A>
|
|
<H2>SIMPLE USE OF JIT</H2>
|
|
|
|
|
|
<P>
|
|
You have to do two things to make use of the JIT support in the simplest way:
|
|
<P>
|
|
<BR> (1) Call <B>pcre_study()</B> with the PCRE_STUDY_JIT_COMPILE option for
|
|
<BR> each compiled pattern, and pass the resulting <B>pcre_extra</B> block to
|
|
<BR> <B>pcre_exec()</B>.
|
|
<P>
|
|
<BR> (2) Use <B>pcre_free_study()</B> to free the <B>pcre_extra</B> block when it is
|
|
<BR> no longer needed, instead of just freeing it yourself. This ensures that
|
|
<BR> any JIT data is also freed.
|
|
<P>
|
|
For a program that may be linked with pre-8.20 versions of PCRE, you can insert
|
|
<P>
|
|
<BR> #ifndef PCRE_STUDY_JIT_COMPILE
|
|
<BR> #define PCRE_STUDY_JIT_COMPILE 0
|
|
<BR> #endif
|
|
<P>
|
|
so that no option is passed to <B>pcre_study()</B>, and then use something like
|
|
this to free the study data:
|
|
<P>
|
|
<BR> #ifdef PCRE_CONFIG_JIT
|
|
<BR> pcre_free_study(study_ptr);
|
|
<BR> #else
|
|
<BR> pcre_free(study_ptr);
|
|
<BR> #endif
|
|
<P>
|
|
PCRE_STUDY_JIT_COMPILE requests the JIT compiler to generate code for complete
|
|
matches. If you want to run partial matches using the PCRE_PARTIAL_HARD or
|
|
PCRE_PARTIAL_SOFT options of <B>pcre_exec()</B>, you should set one or both of
|
|
the following options in addition to, or instead of, PCRE_STUDY_JIT_COMPILE
|
|
when you call <B>pcre_study()</B>:
|
|
<P>
|
|
<BR> PCRE_STUDY_JIT_PARTIAL_HARD_COMPILE
|
|
<BR> PCRE_STUDY_JIT_PARTIAL_SOFT_COMPILE
|
|
<P>
|
|
The JIT compiler generates different optimized code for each of the three
|
|
modes (normal, soft partial, hard partial). When <B>pcre_exec()</B> is called,
|
|
the appropriate code is run if it is available. Otherwise, the pattern is
|
|
matched using interpretive code.
|
|
<P>
|
|
|
|
In some circumstances you may need to call additional functions. These are
|
|
described in the section entitled
|
|
|
|
|
|
"Controlling the JIT stack"
|
|
|
|
below.
|
|
<P>
|
|
|
|
If JIT support is not available, PCRE_STUDY_JIT_COMPILE etc. are ignored, and
|
|
no JIT data is created. Otherwise, the compiled pattern is passed to the JIT
|
|
compiler, which turns it into machine code that executes much faster than the
|
|
normal interpretive code. When <B>pcre_exec()</B> is passed a <B>pcre_extra</B>
|
|
block containing a pointer to JIT code of the appropriate mode (normal or
|
|
hard/soft partial), it obeys that code instead of running the interpreter. The
|
|
result is identical, but the compiled JIT code runs much faster.
|
|
<P>
|
|
|
|
There are some <B>pcre_exec()</B> options that are not supported for JIT
|
|
execution. There are also some pattern items that JIT cannot handle. Details
|
|
are given below. In both cases, execution automatically falls back to the
|
|
interpretive code. If you want to know whether JIT was actually used for a
|
|
particular match, you should arrange for a JIT callback function to be set up
|
|
as described in the section entitled
|
|
|
|
|
|
"Controlling the JIT stack"
|
|
|
|
below, even if you do not need to supply a non-default JIT stack. Such a
|
|
callback function is called whenever JIT code is about to be obeyed. If the
|
|
execution options are not right for JIT execution, the callback function is not
|
|
obeyed.
|
|
<P>
|
|
|
|
If the JIT compiler finds an unsupported item, no JIT data is generated. You
|
|
can find out if JIT execution is available after studying a pattern by calling
|
|
<B>pcre_fullinfo()</B> with the PCRE_INFO_JIT option. A result of 1 means that
|
|
JIT compilation was successful. A result of 0 means that JIT support is not
|
|
available, or the pattern was not studied with PCRE_STUDY_JIT_COMPILE etc., or
|
|
the JIT compiler was not able to handle the pattern.
|
|
<P>
|
|
|
|
Once a pattern has been studied, with or without JIT, it can be used as many
|
|
times as you like for matching different subject strings.
|
|
<A NAME="lbAG"> </A>
|
|
<H2>UNSUPPORTED OPTIONS AND PATTERN ITEMS</H2>
|
|
|
|
|
|
<P>
|
|
The only <B>pcre_exec()</B> options that are supported for JIT execution are
|
|
PCRE_NO_UTF8_CHECK, PCRE_NO_UTF16_CHECK, PCRE_NO_UTF32_CHECK, PCRE_NOTBOL,
|
|
PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NOTEMPTY_ATSTART, PCRE_PARTIAL_HARD, and
|
|
PCRE_PARTIAL_SOFT.
|
|
<P>
|
|
|
|
The only unsupported pattern items are \C (match a single data unit) when
|
|
running in a UTF mode, and a callout immediately before an assertion condition
|
|
in a conditional group.
|
|
<A NAME="lbAH"> </A>
|
|
<H2>RETURN VALUES FROM JIT EXECUTION</H2>
|
|
|
|
|
|
<P>
|
|
When a pattern is matched using JIT execution, the return values are the same
|
|
as those given by the interpretive <B>pcre_exec()</B> code, with the addition of
|
|
one new error code: PCRE_ERROR_JIT_STACKLIMIT. This means that the memory used
|
|
for the JIT stack was insufficient. See
|
|
|
|
|
|
"Controlling the JIT stack"
|
|
|
|
below for a discussion of JIT stack usage. For compatibility with the
|
|
interpretive <B>pcre_exec()</B> code, no more than two-thirds of the
|
|
<I>ovector</I> argument is used for passing back captured substrings.
|
|
<P>
|
|
|
|
The error code PCRE_ERROR_MATCHLIMIT is returned by the JIT code if searching a
|
|
very large pattern tree goes on for too long, as it is in the same circumstance
|
|
when JIT is not used, but the details of exactly what is counted are not the
|
|
same. The PCRE_ERROR_RECURSIONLIMIT error code is never returned by JIT
|
|
execution.
|
|
<A NAME="lbAI"> </A>
|
|
<H2>SAVING AND RESTORING COMPILED PATTERNS</H2>
|
|
|
|
|
|
<P>
|
|
The code that is generated by the JIT compiler is architecture-specific, and is
|
|
also position dependent. For those reasons it cannot be saved (in a file or
|
|
database) and restored later like the bytecode and other data of a compiled
|
|
pattern. Saving and restoring compiled patterns is not something many people
|
|
do. More detail about this facility is given in the
|
|
|
|
<B>pcreprecompile</B>
|
|
|
|
documentation. It should be possible to run <B>pcre_study()</B> on a saved and
|
|
restored pattern, and thereby recreate the JIT data, but because JIT
|
|
compilation uses significant resources, it is probably not worth doing this;
|
|
you might as well recompile the original pattern.
|
|
|
|
<A NAME="lbAJ"> </A>
|
|
<H2>CONTROLLING THE JIT STACK</H2>
|
|
|
|
|
|
<P>
|
|
When the compiled JIT code runs, it needs a block of memory to use as a stack.
|
|
By default, it uses 32K on the machine stack. However, some large or
|
|
complicated patterns need more than this. The error PCRE_ERROR_JIT_STACKLIMIT
|
|
is given when there is not enough stack. Three functions are provided for
|
|
managing blocks of memory for use as JIT stacks. There is further discussion
|
|
about the use of JIT stacks in the section entitled
|
|
|
|
|
|
"JIT stack FAQ"
|
|
|
|
below.
|
|
<P>
|
|
|
|
The <B>pcre_jit_stack_alloc()</B> function creates a JIT stack. Its arguments
|
|
are a starting size and a maximum size, and it returns a pointer to an opaque
|
|
structure of type <B>pcre_jit_stack</B>, or NULL if there is an error. The
|
|
<B>pcre_jit_stack_free()</B> function can be used to free a stack that is no
|
|
longer needed. (For the technically minded: the address space is allocated by
|
|
mmap or VirtualAlloc.)
|
|
<P>
|
|
|
|
JIT uses far less memory for recursion than the interpretive code,
|
|
and a maximum stack size of 512K to 1M should be more than enough for any
|
|
pattern.
|
|
<P>
|
|
|
|
The <B>pcre_assign_jit_stack()</B> function specifies which stack JIT code
|
|
should use. Its arguments are as follows:
|
|
<P>
|
|
<BR> pcre_extra *extra
|
|
<BR> pcre_jit_callback callback
|
|
<BR> void *data
|
|
<P>
|
|
The <I>extra</I> argument must be the result of studying a pattern with
|
|
PCRE_STUDY_JIT_COMPILE etc. There are three cases for the values of the other
|
|
two options:
|
|
<P>
|
|
<BR> (1) If <I>callback</I> is NULL and <I>data</I> is NULL, an internal 32K block
|
|
<BR> on the machine stack is used.
|
|
<P>
|
|
<BR> (2) If <I>callback</I> is NULL and <I>data</I> is not NULL, <I>data</I> must be
|
|
<BR> a valid JIT stack, the result of calling <B>pcre_jit_stack_alloc()</B>.
|
|
<P>
|
|
<BR> (3) If <I>callback</I> is not NULL, it must point to a function that is
|
|
<BR> called with <I>data</I> as an argument at the start of matching, in
|
|
<BR> order to set up a JIT stack. If the return from the callback
|
|
<BR> function is NULL, the internal 32K stack is used; otherwise the
|
|
<BR> return value must be a valid JIT stack, the result of calling
|
|
<BR> <B>pcre_jit_stack_alloc()</B>.
|
|
<P>
|
|
A callback function is obeyed whenever JIT code is about to be run; it is not
|
|
obeyed when <B>pcre_exec()</B> is called with options that are incompatible for
|
|
JIT execution. A callback function can therefore be used to determine whether a
|
|
match operation was executed by JIT or by the interpreter.
|
|
<P>
|
|
|
|
You may safely use the same JIT stack for more than one pattern (either by
|
|
assigning directly or by callback), as long as the patterns are all matched
|
|
sequentially in the same thread. In a multithread application, if you do not
|
|
specify a JIT stack, or if you assign or pass back NULL from a callback, that
|
|
is thread-safe, because each thread has its own machine stack. However, if you
|
|
assign or pass back a non-NULL JIT stack, this must be a different stack for
|
|
each thread so that the application is thread-safe.
|
|
<P>
|
|
|
|
Strictly speaking, even more is allowed. You can assign the same non-NULL stack
|
|
to any number of patterns as long as they are not used for matching by multiple
|
|
threads at the same time. For example, you can assign the same stack to all
|
|
compiled patterns, and use a global mutex in the callback to wait until the
|
|
stack is available for use. However, this is an inefficient solution, and not
|
|
recommended.
|
|
<P>
|
|
|
|
This is a suggestion for how a multithreaded program that needs to set up
|
|
non-default JIT stacks might operate:
|
|
<P>
|
|
<BR> During thread initalization
|
|
<BR> thread_local_var = pcre_jit_stack_alloc(...)
|
|
<P>
|
|
<BR> During thread exit
|
|
<BR> pcre_jit_stack_free(thread_local_var)
|
|
<P>
|
|
<BR> Use a one-line callback function
|
|
<BR> return thread_local_var
|
|
<P>
|
|
All the functions described in this section do nothing if JIT is not available,
|
|
and <B>pcre_assign_jit_stack()</B> does nothing unless the <B>extra</B> argument
|
|
is non-NULL and points to a <B>pcre_extra</B> block that is the result of a
|
|
successful study with PCRE_STUDY_JIT_COMPILE etc.
|
|
|
|
<A NAME="lbAK"> </A>
|
|
<H2>JIT STACK FAQ</H2>
|
|
|
|
|
|
<P>
|
|
(1) Why do we need JIT stacks?
|
|
<P>
|
|
PCRE (and JIT) is a recursive, depth-first engine, so it needs a stack where
|
|
the local data of the current node is pushed before checking its child nodes.
|
|
Allocating real machine stack on some platforms is difficult. For example, the
|
|
stack chain needs to be updated every time if we extend the stack on PowerPC.
|
|
Although it is possible, its updating time overhead decreases performance. So
|
|
we do the recursion in memory.
|
|
<P>
|
|
|
|
(2) Why don't we simply allocate blocks of memory with <B>malloc()</B>?
|
|
<P>
|
|
Modern operating systems have a nice feature: they can reserve an address space
|
|
instead of allocating memory. We can safely allocate memory pages inside this
|
|
address space, so the stack could grow without moving memory data (this is
|
|
important because of pointers). Thus we can allocate 1M address space, and use
|
|
only a single memory page (usually 4K) if that is enough. However, we can still
|
|
grow up to 1M anytime if needed.
|
|
<P>
|
|
|
|
(3) Who "owns" a JIT stack?
|
|
<P>
|
|
The owner of the stack is the user program, not the JIT studied pattern or
|
|
anything else. The user program must ensure that if a stack is used by
|
|
<B>pcre_exec()</B>, (that is, it is assigned to the pattern currently running),
|
|
that stack must not be used by any other threads (to avoid overwriting the same
|
|
memory area). The best practice for multithreaded programs is to allocate a
|
|
stack for each thread, and return this stack through the JIT callback function.
|
|
<P>
|
|
|
|
(4) When should a JIT stack be freed?
|
|
<P>
|
|
You can free a JIT stack at any time, as long as it will not be used by
|
|
<B>pcre_exec()</B> again. When you assign the stack to a pattern, only a pointer
|
|
is set. There is no reference counting or any other magic. You can free the
|
|
patterns and stacks in any order, anytime. Just <I>do not</I> call
|
|
<B>pcre_exec()</B> with a pattern pointing to an already freed stack, as that
|
|
will cause SEGFAULT. (Also, do not free a stack currently used by
|
|
<B>pcre_exec()</B> in another thread). You can also replace the stack for a
|
|
pattern at any time. You can even free the previous stack before assigning a
|
|
replacement.
|
|
<P>
|
|
|
|
(5) Should I allocate/free a stack every time before/after calling
|
|
<B>pcre_exec()</B>?
|
|
<P>
|
|
No, because this is too costly in terms of resources. However, you could
|
|
implement some clever idea which release the stack if it is not used in let's
|
|
say two minutes. The JIT callback can help to achieve this without keeping a
|
|
list of the currently JIT studied patterns.
|
|
<P>
|
|
|
|
(6) OK, the stack is for long term memory allocation. But what happens if a
|
|
pattern causes stack overflow with a stack of 1M? Is that 1M kept until the
|
|
stack is freed?
|
|
<P>
|
|
Especially on embedded sytems, it might be a good idea to release memory
|
|
sometimes without freeing the stack. There is no API for this at the moment.
|
|
Probably a function call which returns with the currently allocated memory for
|
|
any stack and another which allows releasing memory (shrinking the stack) would
|
|
be a good idea if someone needs this.
|
|
<P>
|
|
|
|
(7) This is too much of a headache. Isn't there any better solution for JIT
|
|
stack handling?
|
|
<P>
|
|
No, thanks to Windows. If POSIX threads were used everywhere, we could throw
|
|
out this complicated API.
|
|
<A NAME="lbAL"> </A>
|
|
<H2>EXAMPLE CODE</H2>
|
|
|
|
|
|
<P>
|
|
This is a single-threaded example that specifies a JIT stack without using a
|
|
callback.
|
|
<P>
|
|
<BR> int rc;
|
|
<BR> int ovector[30];
|
|
<BR> pcre *re;
|
|
<BR> pcre_extra *extra;
|
|
<BR> pcre_jit_stack *jit_stack;
|
|
<P>
|
|
<BR> re = pcre_compile(pattern, 0, &error, &erroffset, NULL);
|
|
<BR> /* Check for errors */
|
|
<BR> extra = pcre_study(re, PCRE_STUDY_JIT_COMPILE, &error);
|
|
<BR> jit_stack = pcre_jit_stack_alloc(32*1024, 512*1024);
|
|
<BR> /* Check for error (NULL) */
|
|
<BR> pcre_assign_jit_stack(extra, NULL, jit_stack);
|
|
<BR> rc = pcre_exec(re, extra, subject, length, 0, 0, ovector, 30);
|
|
<BR> /* Check results */
|
|
<BR> pcre_free(re);
|
|
<BR> pcre_free_study(extra);
|
|
<BR> pcre_jit_stack_free(jit_stack);
|
|
<P>
|
|
<A NAME="lbAM"> </A>
|
|
<H2>JIT FAST PATH API</H2>
|
|
|
|
|
|
<P>
|
|
Because the API described above falls back to interpreted execution when JIT is
|
|
not available, it is convenient for programs that are written for general use
|
|
in many environments. However, calling JIT via <B>pcre_exec()</B> does have a
|
|
performance impact. Programs that are written for use where JIT is known to be
|
|
available, and which need the best possible performance, can instead use a
|
|
"fast path" API to call JIT execution directly instead of calling
|
|
<B>pcre_exec()</B> (obviously only for patterns that have been successfully
|
|
studied by JIT).
|
|
<P>
|
|
|
|
The fast path function is called <B>pcre_jit_exec()</B>, and it takes exactly
|
|
the same arguments as <B>pcre_exec()</B>, plus one additional argument that
|
|
must point to a JIT stack. The JIT stack arrangements described above do not
|
|
apply. The return values are the same as for <B>pcre_exec()</B>.
|
|
<P>
|
|
|
|
When you call <B>pcre_exec()</B>, as well as testing for invalid options, a
|
|
number of other sanity checks are performed on the arguments. For example, if
|
|
the subject pointer is NULL, or its length is negative, an immediate error is
|
|
given. Also, unless PCRE_NO_UTF[8|16|32] is set, a UTF subject string is tested
|
|
for validity. In the interests of speed, these checks do not happen on the JIT
|
|
fast path, and if invalid data is passed, the result is undefined.
|
|
<P>
|
|
|
|
Bypassing the sanity checks and the <B>pcre_exec()</B> wrapping can give
|
|
speedups of more than 10%.
|
|
<A NAME="lbAN"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
|
|
<P>
|
|
<B><A HREF="/cgi-bin/man/man2html?3+pcreapi">pcreapi</A></B>(3)
|
|
<A NAME="lbAO"> </A>
|
|
<H2>AUTHOR</H2>
|
|
|
|
|
|
<P>
|
|
<PRE>
|
|
Philip Hazel (FAQ by Zoltan Herczeg)
|
|
University Computing Service
|
|
Cambridge CB2 3QH, England.
|
|
</PRE>
|
|
|
|
<A NAME="lbAP"> </A>
|
|
<H2>REVISION</H2>
|
|
|
|
|
|
<P>
|
|
<PRE>
|
|
Last updated: 17 March 2013
|
|
Copyright (c) 1997-2013 University of Cambridge.
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="1"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="2"><A HREF="#lbAC">PCRE JUST-IN-TIME COMPILER SUPPORT</A><DD>
|
|
<DT id="3"><A HREF="#lbAD">8-BIT, 16-BIT AND 32-BIT SUPPORT</A><DD>
|
|
<DT id="4"><A HREF="#lbAE">AVAILABILITY OF JIT SUPPORT</A><DD>
|
|
<DT id="5"><A HREF="#lbAF">SIMPLE USE OF JIT</A><DD>
|
|
<DT id="6"><A HREF="#lbAG">UNSUPPORTED OPTIONS AND PATTERN ITEMS</A><DD>
|
|
<DT id="7"><A HREF="#lbAH">RETURN VALUES FROM JIT EXECUTION</A><DD>
|
|
<DT id="8"><A HREF="#lbAI">SAVING AND RESTORING COMPILED PATTERNS</A><DD>
|
|
<DT id="9"><A HREF="#lbAJ">CONTROLLING THE JIT STACK</A><DD>
|
|
<DT id="10"><A HREF="#lbAK">JIT STACK FAQ</A><DD>
|
|
<DT id="11"><A HREF="#lbAL">EXAMPLE CODE</A><DD>
|
|
<DT id="12"><A HREF="#lbAM">JIT FAST PATH API</A><DD>
|
|
<DT id="13"><A HREF="#lbAN">SEE ALSO</A><DD>
|
|
<DT id="14"><A HREF="#lbAO">AUTHOR</A><DD>
|
|
<DT id="15"><A HREF="#lbAP">REVISION</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:05:52 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|