REGCOMP(3)                 POSIX Programmer's Manual                REGCOMP(3)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.

NNAAMMEE
       regcomp, regerror, regexec, regfree -- regular expression matching

SSYYNNOOPPSSIISS
       #include <regex.h>

       int regcomp(regex_t *restrict _p_r_e_g, const char *restrict _p_a_t_t_e_r_n,
           int _c_f_l_a_g_s);
       size_t regerror(int _e_r_r_c_o_d_e, const regex_t *restrict _p_r_e_g,
           char *restrict _e_r_r_b_u_f, size_t _e_r_r_b_u_f___s_i_z_e);
       int regexec(const regex_t *restrict _p_r_e_g, const char *restrict _s_t_r_i_n_g,
           size_t _n_m_a_t_c_h, regmatch_t _p_m_a_t_c_h[restrict], int _e_f_l_a_g_s);
       void regfree(regex_t *_p_r_e_g);

DDEESSCCRRIIPPTTIIOONN
       These functions interpret _b_a_s_i_c and _e_x_t_e_n_d_e_d regular expressions as
       described in the Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _9,
       _R_e_g_u_l_a_r _E_x_p_r_e_s_s_i_o_n_s.

       The rreeggeexx__tt structure is defined in _<_r_e_g_e_x_._h_> and contains at least the
       following member:

             +--------------+--------------+---------------------------+
             |MMeemmbbeerr TTyyppee   | MMeemmbbeerr NNaammee  |        DDeessccrriippttiioonn        |
             +--------------+--------------+---------------------------+
             |ssiizzee__tt        |_r_e___n_s_u_b       | Number of parenthesized   |
             |              |              | subexpressions.           |
             +--------------+--------------+---------------------------+
       The rreeggmmaattcchh__tt structure is defined in _<_r_e_g_e_x_._h_> and contains at least
       the following members:

             +--------------+--------------+---------------------------+
             |MMeemmbbeerr TTyyppee   | MMeemmbbeerr NNaammee  |        DDeessccrriippttiioonn        |
             +--------------+--------------+---------------------------+
             |rreeggooffff__tt      |_r_m___s_o         | Byte offset from start of |
             |              |              | _s_t_r_i_n_g to start of        |
             |              |              | substring.                |
             |rreeggooffff__tt      |_r_m___e_o         | Byte offset from start of |
             |              |              | _s_t_r_i_n_g of the first       |
             |              |              | character after the end   |
             |              |              | of substring.             |
             +--------------+--------------+---------------------------+
       The _r_e_g_c_o_m_p() function shall compile the regular expression contained
       in the string pointed to by the _p_a_t_t_e_r_n argument and place the results
       in the structure pointed to by _p_r_e_g.  The _c_f_l_a_g_s argument is the
       bitwise-inclusive OR of zero or more of the following flags, which are
       defined in the _<_r_e_g_e_x_._h_> header:

       REG_EXTENDED  Use Extended Regular Expressions.

       REG_ICASE     Ignore case in match (see the Base Definitions volume of
                     POSIX.1-2017, _C_h_a_p_t_e_r _9, _R_e_g_u_l_a_r _E_x_p_r_e_s_s_i_o_n_s).

       REG_NOSUB     Report only success/fail in _r_e_g_e_x_e_c().

       REG_NEWLINE   Change the handling of <newline> characters, as described
                     in the text.

       The default regular expression type for _p_a_t_t_e_r_n is a Basic Regular
       Expression. The application can specify Extended Regular Expressions
       using the REG_EXTENDED _c_f_l_a_g_s flag.

       If the REG_NOSUB flag was not set in _c_f_l_a_g_s, then _r_e_g_c_o_m_p() shall set
       _r_e___n_s_u_b to the number of parenthesized subexpressions (delimited by
       ""\\((\\))"" in basic regular expressions or ""(())"" in extended regular
       expressions) found in _p_a_t_t_e_r_n.

       The _r_e_g_e_x_e_c() function compares the null-terminated string specified by
       _s_t_r_i_n_g with the compiled regular expression _p_r_e_g initialized by a
       previous call to _r_e_g_c_o_m_p().  If it finds a match, _r_e_g_e_x_e_c() shall
       return 0; otherwise, it shall return non-zero indicating either no
       match or an error. The _e_f_l_a_g_s argument is the bitwise-inclusive OR of
       zero or more of the following flags, which are defined in the _<_r_e_g_e_x_._h_>
       header:

       REG_NOTBOL    The first character of the string pointed to by _s_t_r_i_n_g is
                     not the beginning of the line. Therefore, the
                     <circumflex> character (''^^''), when taken as a special
                     character, shall not match the beginning of _s_t_r_i_n_g.

       REG_NOTEOL    The last character of the string pointed to by _s_t_r_i_n_g is
                     not the end of the line. Therefore, the <dollar-sign>
                     (''$$''), when taken as a special character, shall not match
                     the end of _s_t_r_i_n_g.

       If _n_m_a_t_c_h is 0 or REG_NOSUB was set in the _c_f_l_a_g_s argument to
       _r_e_g_c_o_m_p(), then _r_e_g_e_x_e_c() shall ignore the _p_m_a_t_c_h argument. Otherwise,
       the application shall ensure that the _p_m_a_t_c_h argument points to an
       array with at least _n_m_a_t_c_h elements, and _r_e_g_e_x_e_c() shall fill in the
       elements of that array with offsets of the substrings of _s_t_r_i_n_g that
       correspond to the parenthesized subexpressions of _p_a_t_t_e_r_n:
       _p_m_a_t_c_h[_i]._r_m___s_o shall be the byte offset of the beginning and
       _p_m_a_t_c_h[_i]._r_m___e_o shall be one greater than the byte offset of the end of
       substring _i.  (Subexpression _i begins at the _ith matched open
       parenthesis, counting from 1.) Offsets in _p_m_a_t_c_h[0] identify the
       substring that corresponds to the entire regular expression. Unused
       elements of _p_m_a_t_c_h up to _p_m_a_t_c_h[_n_m_a_t_c_h-1] shall be filled with -1. If
       there are more than _n_m_a_t_c_h subexpressions in _p_a_t_t_e_r_n (_p_a_t_t_e_r_n itself
       counts as a subexpression), then _r_e_g_e_x_e_c() shall still do the match,
       but shall record only the first _n_m_a_t_c_h substrings.

       When matching a basic or extended regular expression, any given
       parenthesized subexpression of _p_a_t_t_e_r_n might participate in the match
       of several different substrings of _s_t_r_i_n_g, or it might not match any
       substring even though the pattern as a whole did match. The following
       rules shall be used to determine which substrings to report in _p_m_a_t_c_h
       when matching regular expressions:

        1. If subexpression _i in a regular expression is not contained within
           another subexpression, and it participated in the match several
           times, then the byte offsets in _p_m_a_t_c_h[_i] shall delimit the last
           such match.

        2. If subexpression _i is not contained within another subexpression,
           and it did not participate in an otherwise successful match, the
           byte offsets in _p_m_a_t_c_h[_i] shall be -1. A subexpression does not
           participate in the match when:

           ''**'' or ""\\{{\\}}"" appears immediately after the subexpression in a
           basic regular expression, or ''**'', ''??'', or ""{{}}"" appears immediately
           after the subexpression in an extended regular expression, and the
           subexpression did not match (matched 0 times)

           or:

                  ''||'' is used in an extended regular expression to select this
                  subexpression or another, and the other subexpression
                  matched.

        3. If subexpression _i is contained within another subexpression _j, and
           _i is not contained within any other subexpression that is contained
           within _j, and a match of subexpression _j is reported in _p_m_a_t_c_h[_j],
           then the match or non-match of subexpression _i reported in
           _p_m_a_t_c_h[_i] shall be as described in 1. and 2. above, but within the
           substring reported in _p_m_a_t_c_h[_j] rather than the whole string. The
           offsets in _p_m_a_t_c_h[_i] are still relative to the start of _s_t_r_i_n_g.

        4. If subexpression _i is contained in subexpression _j, and the byte
           offsets in _p_m_a_t_c_h[_j] are -1, then the pointers in _p_m_a_t_c_h[_i] shall
           also be -1.

        5. If subexpression _i matched a zero-length string, then both byte
           offsets in _p_m_a_t_c_h[_i] shall be the byte offset of the character or
           null terminator immediately following the zero-length string.

       If, when _r_e_g_e_x_e_c() is called, the locale is different from when the
       regular expression was compiled, the result is undefined.

       If REG_NEWLINE is not set in _c_f_l_a_g_s, then a <newline> in _p_a_t_t_e_r_n or
       _s_t_r_i_n_g shall be treated as an ordinary character. If REG_NEWLINE is
       set, then <newline> shall be treated as an ordinary character except as
       follows:

        1. A <newline> in _s_t_r_i_n_g shall not be matched by a <period> outside a
           bracket expression or by any form of a non-matching list (see the
           Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _9, _R_e_g_u_l_a_r
           _E_x_p_r_e_s_s_i_o_n_s).

        2. A <circumflex> (''^^'') in _p_a_t_t_e_r_n, when used to specify expression
           anchoring (see the Base Definitions volume of POSIX.1-2017, _S_e_c_t_i_o_n
           _9_._3_._8, _B_R_E _E_x_p_r_e_s_s_i_o_n _A_n_c_h_o_r_i_n_g), shall match the zero-length
           string immediately after a <newline> in _s_t_r_i_n_g, regardless of the
           setting of REG_NOTBOL.

        3. A <dollar-sign> (''$$'') in _p_a_t_t_e_r_n, when used to specify expression
           anchoring, shall match the zero-length string immediately before a
           <newline> in _s_t_r_i_n_g, regardless of the setting of REG_NOTEOL.

       The _r_e_g_f_r_e_e() function frees any memory allocated by _r_e_g_c_o_m_p()
       associated with _p_r_e_g.

       The following constants are defined as the minimum set of error return
       values, although other errors listed as implementation extensions in
       _<_r_e_g_e_x_._h_> are possible:

       REG_BADBR     Content of ""\\{{\\}}"" invalid: not a number, number too
                     large, more than two numbers, first larger than second.

       REG_BADPAT    Invalid regular expression.

       REG_BADRPT    ''??'', ''**'', or ''++'' not preceded by valid regular
                     expression.

       REG_EBRACE    ""\\{{\\}}"" imbalance.

       REG_EBRACK    ""[[]]"" imbalance.

       REG_ECOLLATE  Invalid collating element referenced.

       REG_ECTYPE    Invalid character class type referenced.

       REG_EESCAPE   Trailing <backslash> character in pattern.

       REG_EPAREN    ""\\((\\))"" or ""(())"" imbalance.

       REG_ERANGE    Invalid endpoint in range expression.

       REG_ESPACE    Out of memory.

       REG_ESUBREG   Number in ""\\ddiiggiitt"" invalid or in error.

       REG_NOMATCH   _r_e_g_e_x_e_c() failed to match.

       If more than one error occurs in processing a function call, any one of
       the possible constants may be returned, as the order of detection is
       unspecified.

       The _r_e_g_e_r_r_o_r() function provides a mapping from error codes returned by
       _r_e_g_c_o_m_p() and _r_e_g_e_x_e_c() to unspecified printable strings. It generates
       a string corresponding to the value of the _e_r_r_c_o_d_e argument, which the
       application shall ensure is the last non-zero value returned by
       _r_e_g_c_o_m_p() or _r_e_g_e_x_e_c() with the given value of _p_r_e_g.  If _e_r_r_c_o_d_e is not
       such a value, the content of the generated string is unspecified.

       If _p_r_e_g is a null pointer, but _e_r_r_c_o_d_e is a value returned by a
       previous call to _r_e_g_e_x_e_c() or _r_e_g_c_o_m_p(), the _r_e_g_e_r_r_o_r() still generates
       an error string corresponding to the value of _e_r_r_c_o_d_e, but it might not
       be as detailed under some implementations.

       If the _e_r_r_b_u_f___s_i_z_e argument is not 0, _r_e_g_e_r_r_o_r() shall place the
       generated string into the buffer of size _e_r_r_b_u_f___s_i_z_e bytes pointed to
       by _e_r_r_b_u_f.  If the string (including the terminating null) cannot fit
       in the buffer, _r_e_g_e_r_r_o_r() shall truncate the string and null-terminate
       the result.

       If _e_r_r_b_u_f___s_i_z_e is 0, _r_e_g_e_r_r_o_r() shall ignore the _e_r_r_b_u_f argument, and
       return the size of the buffer needed to hold the generated string.

       If the _p_r_e_g argument to _r_e_g_e_x_e_c() or _r_e_g_f_r_e_e() is not a compiled
       regular expression returned by _r_e_g_c_o_m_p(), the result is undefined. A
       _p_r_e_g is no longer treated as a compiled regular expression after it is
       given to _r_e_g_f_r_e_e().

RREETTUURRNN VVAALLUUEE
       Upon successful completion, the _r_e_g_c_o_m_p() function shall return 0.
       Otherwise, it shall return an integer value indicating an error as
       described in _<_r_e_g_e_x_._h_>, and the content of _p_r_e_g is undefined. If a code
       is returned, the interpretation shall be as given in _<_r_e_g_e_x_._h_>.

       If _r_e_g_c_o_m_p() detects an invalid RE, it may return REG_BADPAT, or it may
       return one of the error codes that more precisely describes the error.

       Upon successful completion, the _r_e_g_e_x_e_c() function shall return 0.
       Otherwise, it shall return REG_NOMATCH to indicate no match.

       Upon successful completion, the _r_e_g_e_r_r_o_r() function shall return the
       number of bytes needed to hold the entire generated string, including
       the null termination. If the return value is greater than _e_r_r_b_u_f___s_i_z_e,
       the string returned in the buffer pointed to by _e_r_r_b_u_f has been
       truncated.

       The _r_e_g_f_r_e_e() function shall not return a value.

EERRRROORRSS
       No errors are defined.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
           #include <regex.h>

           /*
            * Match string against the extended regular expression in
            * pattern, treating errors as no match.
            *
            * Return 1 for match, 0 for no match.
            */

           int
           match(const char *string, char *pattern)
           {
               int    status;
               regex_t    re;

               if (regcomp(&re, pattern, REG_EXTENDED|REG_NOSUB) != 0) {
                   return(0);      /* Report error. */
               }
               status = regexec(&re, string, (size_t) 0, NULL, 0);
               regfree(&re);
               if (status != 0) {
                   return(0);      /* Report error. */
               }
               return(1);
           }

       The following demonstrates how the REG_NOTBOL flag could be used with
       _r_e_g_e_x_e_c() to find all substrings in a line that match a pattern
       supplied by a user.  (For simplicity of the example, very little error
       checking is done.)


           (void) regcomp (&re, pattern, 0);
           /* This call to regexec() finds the first match on the line. */
           error = regexec (&re, &buffer[0], 1, &pm, 0);
           while (error == 0) {  /* While matches found. */
               /* Substring found between pm.rm_so and pm.rm_eo. */
               /* This call to regexec() finds the next match. */
               error = regexec (&re, buffer + pm.rm_eo, 1, &pm, REG_NOTBOL);
           }

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       An application could use:


           regerror(code,preg,(char *)NULL,(size_t)0)

       to find out how big a buffer is needed for the generated string,
       _m_a_l_l_o_c() a buffer to hold the string, and then call _r_e_g_e_r_r_o_r() again to
       get the string. Alternatively, it could allocate a fixed, static buffer
       that is big enough to hold most strings, and then use _m_a_l_l_o_c() to
       allocate a larger buffer if it finds that this is too small.

       To match a pattern as described in the Shell and Utilities volume of
       POSIX.1-2017, _S_e_c_t_i_o_n _2_._1_3, _P_a_t_t_e_r_n _M_a_t_c_h_i_n_g _N_o_t_a_t_i_o_n, use the
       _f_n_m_a_t_c_h() function.

RRAATTIIOONNAALLEE
       The _r_e_g_e_x_e_c() function must fill in all _n_m_a_t_c_h elements of _p_m_a_t_c_h,
       where _n_m_a_t_c_h and _p_m_a_t_c_h are supplied by the application, even if some
       elements of _p_m_a_t_c_h do not correspond to subexpressions in _p_a_t_t_e_r_n.  The
       application developer should note that there is probably no reason for
       using a value of _n_m_a_t_c_h that is larger than _p_r_e_g->_r_e___n_s_u_b+1.

       The REG_NEWLINE flag supports a use of RE matching that is needed in
       some applications like text editors. In such applications, the user
       supplies an RE asking the application to find a line that matches the
       given expression. An anchor in such an RE anchors at the beginning or
       end of any line. Such an application can pass a sequence of
       <newline>-separated lines to _r_e_g_e_x_e_c() as a single long string and
       specify REG_NEWLINE to _r_e_g_c_o_m_p() to get the desired behavior. The
       application must ensure that there are no explicit <newline> characters
       in _p_a_t_t_e_r_n if it wants to ensure that any match occurs entirely within
       a single line.

       The REG_NEWLINE flag affects the behavior of _r_e_g_e_x_e_c(), but it is in
       the _c_f_l_a_g_s parameter to _r_e_g_c_o_m_p() to allow flexibility of
       implementation. Some implementations will want to generate the same
       compiled RE in _r_e_g_c_o_m_p() regardless of the setting of REG_NEWLINE and
       have _r_e_g_e_x_e_c() handle anchors differently based on the setting of the
       flag. Other implementations will generate different compiled REs based
       on the REG_NEWLINE.

       The REG_ICASE flag supports the operations taken by the _g_r_e_p --ii option
       and the historical implementations of _e_x and _v_i.  Including this flag
       will make it easier for application code to be written that does the
       same thing as these utilities.

       The substrings reported in _p_m_a_t_c_h[] are defined using offsets from the
       start of the string rather than pointers. This allows type-safe access
       to both constant and non-constant strings.

       The type rreeggooffff__tt is used for the elements of _p_m_a_t_c_h[] to ensure that
       the application can represent large arrays in memory (important for an
       application conforming to the Shell and Utilities volume of
       POSIX.1-2017).

       The 1992 edition of this standard required rreeggooffff__tt to be at least as
       wide as ooffff__tt, to facilitate future extensions in which the string to
       be searched is taken from a file. However, these future extensions have
       not appeared.  The requirement rules out popular implementations with
       32-bit rreeggooffff__tt and 64-bit ooffff__tt, so it has been removed.

       The standard developers rejected the inclusion of a _r_e_g_s_u_b() function
       that would be used to do substitutions for a matched RE. While such a
       routine would be useful to some applications, its utility would be much
       more limited than the matching function described here. Both RE parsing
       and substitution are possible to implement without support other than
       that required by the ISO C standard, but matching is much more complex
       than substituting. The only difficult part of substitution, given the
       information supplied by _r_e_g_e_x_e_c(), is finding the next character in a
       string when there can be multi-byte characters. That is a much larger
       issue, and one that needs a more general solution.

       The _e_r_r_n_o variable has not been used for error returns to avoid filling
       the _e_r_r_n_o name space for this feature.

       The interface is defined so that the matched substrings _r_m___s_p and _r_m___e_p
       are in a separate rreeggmmaattcchh__tt structure instead of in rreeggeexx__tt.  This
       allows a single compiled RE to be used simultaneously in several
       contexts; in _m_a_i_n() and a signal handler, perhaps, or in multiple
       threads of lightweight processes. (The _p_r_e_g argument to _r_e_g_e_x_e_c() is
       declared with type ccoonnsstt, so the implementation is not permitted to use
       the structure to store intermediate results.) It also allows an
       application to request an arbitrary number of substrings from an RE.
       The number of subexpressions in the RE is reported in _r_e___n_s_u_b in _p_r_e_g.
       With this change to _r_e_g_e_x_e_c(), consideration was given to dropping the
       REG_NOSUB flag since the user can now specify this with a zero _n_m_a_t_c_h
       argument to _r_e_g_e_x_e_c().  However, keeping REG_NOSUB allows an
       implementation to use a different (perhaps more efficient) algorithm if
       it knows in _r_e_g_c_o_m_p() that no subexpressions need be reported. The
       implementation is only required to fill in _p_m_a_t_c_h if _n_m_a_t_c_h is not zero
       and if REG_NOSUB is not specified. Note that the ssiizzee__tt type, as
       defined in the ISO C standard, is unsigned, so the description of
       _r_e_g_e_x_e_c() does not need to address negative values of _n_m_a_t_c_h.

       REG_NOTBOL was added to allow an application to do repeated searches
       for the same pattern in a line. If the pattern contains a <circumflex>
       character that should match the beginning of a line, then the pattern
       should only match when matched against the beginning of the line.
       Without the REG_NOTBOL flag, the application could rewrite the
       expression for subsequent matches, but in the general case this would
       require parsing the expression. The need for REG_NOTEOL is not as
       clear; it was added for symmetry.

       The addition of the _r_e_g_e_r_r_o_r() function addresses the historical need
       for conforming application programs to have access to error information
       more than ``Function failed to compile/match your RE for unknown
       reasons''.

       This interface provides for two different methods of dealing with error
       conditions. The specific error codes (REG_EBRACE, for example), defined
       in _<_r_e_g_e_x_._h_>, allow an application to recover from an error if it is so
       able. Many applications, especially those that use patterns supplied by
       a user, will not try to deal with specific error cases, but will just
       use _r_e_g_e_r_r_o_r() to obtain a human-readable error message to present to
       the user.

       The _r_e_g_e_r_r_o_r() function uses a scheme similar to _c_o_n_f_s_t_r() to deal with
       the problem of allocating memory to hold the generated string. The
       scheme used by _s_t_r_e_r_r_o_r() in the ISO C standard was considered
       unacceptable since it creates difficulties for multi-threaded
       applications.

       The _p_r_e_g argument is provided to _r_e_g_e_r_r_o_r() to allow an implementation
       to generate a more descriptive message than would be possible with
       _e_r_r_c_o_d_e alone. An implementation might, for example, save the character
       offset of the offending character of the pattern in a field of _p_r_e_g,
       and then include that in the generated message string. The
       implementation may also ignore _p_r_e_g.

       A REG_FILENAME flag was considered, but omitted. This flag caused
       _r_e_g_e_x_e_c() to match patterns as described in the Shell and Utilities
       volume of POSIX.1-2017, _S_e_c_t_i_o_n _2_._1_3, _P_a_t_t_e_r_n _M_a_t_c_h_i_n_g _N_o_t_a_t_i_o_n instead
       of REs. This service is now provided by the _f_n_m_a_t_c_h() function.

       Notice that there is a difference in philosophy between the
       ISO POSIX-2:1993 standard and POSIX.1-2008 in how to handle a ``bad''
       regular expression. The ISO POSIX-2:1993 standard says that many bad
       constructs ``produce undefined results'', or that ``the interpretation
       is undefined''. POSIX.1-2008, however, says that the interpretation of
       such REs is unspecified. The term ``undefined'' means that the action
       by the application is an error, of similar severity to passing a bad
       pointer to a function.

       The _r_e_g_c_o_m_p() and _r_e_g_e_x_e_c() functions are required to accept any null-
       terminated string as the _p_a_t_t_e_r_n argument. If the meaning of the string
       is ``undefined'', the behavior of the function is ``unspecified''.
       POSIX.1-2008 does not specify how the functions will interpret the
       pattern; they might return error codes, or they might do pattern
       matching in some completely unexpected way, but they should not do
       something like abort the process.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _f_n_m_a_t_c_h(), _g_l_o_b()

       The Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _9, _R_e_g_u_l_a_r
       _E_x_p_r_e_s_s_i_o_n_s, <<rreeggeexx..hh>>, <<ssyyss__ttyyppeess..hh>>

       The Shell and Utilities volume of POSIX.1-2017, _S_e_c_t_i_o_n _2_._1_3, _P_a_t_t_e_r_n
       _M_a_t_c_h_i_n_g _N_o_t_a_t_i_o_n

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1-2017, Standard for Information Technology --
       Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the
       Institute of Electrical and Electronics Engineers, Inc and The Open
       Group.  In the event of any discrepancy between this version and the
       original IEEE and The Open Group Standard, the original IEEE and The
       Open Group Standard is the referee document. The original Standard can
       be obtained online at http://www.opengroup.org/unix/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2017                           REGCOMP(3)
