---

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.