#### 10.3.1 POSIX Regular Expression Compilation ¶

Before you can actually match a regular expression, you must compile it. This is not true compilation—it produces a special data structure, not machine instructions. But it is like ordinary compilation in that its purpose is to enable you to “execute” the pattern fast. (See Matching a Compiled POSIX Regular Expression, for how to use the compiled regular expression for matching.)

There is a special data type for compiled regular expressions:

Data Type: regex_t ¶

  This type of object holds a compiled regular expression. It is actually a structure. It has just one field that your programs should look at:

  `re_nsub`

    This field holds the number of parenthetical subexpressions in the regular expression that was compiled.

  There are several other fields, but we don’t describe them here, because only the functions in the library should use them.

After you create a `regex_t` object, you can compile a regular expression into it by calling `regcomp`.

Function: `int` regcomp `(regex_t *restrict compiled, const char *restrict pattern, int cflags)` ¶

  Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap lock dlopen | AC-Unsafe corrupt lock mem fd | See POSIX Safety Concepts.

  The function `regcomp` “compiles” a regular expression into a data structure that you can use with `regexec` to match against a string. The compiled regular expression format is designed for efficient matching. `regcomp` stores it into `*compiled`.

  It’s up to you to allocate an object of type `regex_t` and pass its address to `regcomp`.

  The argument cflags lets you specify various options that control the syntax and semantics of regular expressions. See Flags for POSIX Regular Expressions.

  If you use the flag `REG_NOSUB`, then `regcomp` omits from the compiled regular expression the information necessary to record how subexpressions actually match. In this case, you might as well pass `0` for the matchptr and nmatch arguments when you call `regexec`.

  If you don’t use `REG_NOSUB`, then the compiled regular expression does have the capacity to record how subexpressions match. Also, `regcomp` tells you how many subexpressions pattern has, by storing the number in `compiled->re_nsub`. You can use that value to decide how long an array to allocate to hold information about subexpression matches.

  `regcomp` returns `0` if it succeeds in compiling the regular expression; otherwise, it returns a nonzero error code (see the table below). You can use `regerror` to produce an error message string describing the reason for a nonzero value; see POSIX Regexp Matching Cleanup.

Here are the possible nonzero values that `regcomp` can return:

`REG_BADBR` ¶

  There was an invalid ‘`\{…\}`’ construct in the regular expression. A valid ‘`\{…\}`’ construct must contain either a single number, or two numbers in increasing order separated by a comma.

`REG_BADPAT` ¶

  There was a syntax error in the regular expression.

`REG_BADRPT` ¶

  A repetition operator such as ‘`?`’ or ‘`*`’ appeared in a bad position (with no preceding subexpression to act on).

`REG_ECOLLATE` ¶

  The regular expression referred to an invalid collating element (one not defined in the current locale for string collation). See Locale Categories.

`REG_ECTYPE` ¶

  The regular expression referred to an invalid character class name.

`REG_EESCAPE` ¶

  The regular expression ended with ‘`\`’.

`REG_ESUBREG` ¶

  There was an invalid number in the ‘`\digit`’ construct.

`REG_EBRACK` ¶

  There were unbalanced square brackets in the regular expression.

`REG_EPAREN` ¶

  An extended regular expression had unbalanced parentheses, or a basic regular expression had unbalanced ‘`\(`’ and ‘`\)`’.

`REG_EBRACE` ¶

  The regular expression had unbalanced ‘`\{`’ and ‘`\}`’.

`REG_ERANGE` ¶

  One of the endpoints in a range expression was invalid.

`REG_ESPACE` ¶

  `regcomp` ran out of memory.