pcrestack man page on QNX

Man page or keyword search:  
man Server   4347 pages
apropos Keyword Search (all sections)
Output format
QNX logo
[printable version]


       PCRE - Perl-compatible regular expressions


       When  you call pcre_exec(), it makes use of an internal function called
       match(). This calls itself recursively at branch points in the pattern,
       in  order to remember the state of the match so that it can back up and
       try a different alternative if the first one fails.  As	matching  pro‐
       ceeds  deeper  and deeper into the tree of possibilities, the recursion
       depth increases.

       Not all calls of match() increase the recursion depth; for an item such
       as  a* it may be called several times at the same level, after matching
       different numbers of a's. Furthermore, in a number of cases  where  the
       result  of  the	recursive call would immediately be passed back as the
       result of the current call (a "tail recursion"), the function  is  just
       restarted instead.

       The pcre_dfa_exec() function operates in an entirely different way, and
       uses recursion only when there is a  regular  expression	 recursion  or
       subroutine  call in the pattern. This includes the processing of asser‐
       tion and "once-only" subpatterns, which	are  handled  like  subroutine
       calls.  Normally,  these are never very deep, and the limit on the com‐
       plexity of pcre_dfa_exec() is controlled by the amount of workspace  it
       is  given. However, it is possible to write patterns with runaway infi‐
       nite recursions; such patterns will cause pcre_dfa_exec() to run out of
       stack. At present, there is no protection against this.

       The comments that follow do NOT apply to pcre_dfa_exec(); they are rel‐
       evant only for pcre_exec().

   Reducing pcre_exec()'s stack usage

       Each time that match() is actually called recursively, it  uses	memory
       from  the  process  stack.  For certain kinds of pattern and data, very
       large amounts of stack may be needed, despite the recognition of	 "tail
       recursion".   You  can often reduce the amount of recursion, and there‐
       fore the amount of stack used, by modifying the pattern that  is	 being
       matched. Consider, for example, this pattern:


       It  matches  from wherever it starts until it encounters "<inet" or the
       end of the data, and is the kind of pattern that	 might	be  used  when
       processing an XML file. Each iteration of the outer parentheses matches
       either one character that is not "<" or a "<" that is not  followed  by
       "inet".	However,  each	time  a	 parenthesis is processed, a recursion
       occurs, so this formulation uses a stack frame for each matched charac‐
       ter.  For  a long string, a lot of stack is required. Consider now this
       rewritten pattern, which matches exactly the same strings:


       This uses very much less stack, because runs of characters that do  not
       contain	"<" are "swallowed" in one item inside the parentheses. Recur‐
       sion happens only when a "<" character that is not followed  by	"inet"
       is  encountered	(and  we assume this is relatively rare). A possessive
       quantifier is used to stop any backtracking into the  runs  of  non-"<"
       characters, but that is not related to stack usage.

       This  example shows that one way of avoiding stack problems when match‐
       ing long subject strings is to write repeated parenthesized subpatterns
       to match more than one character whenever possible.

   Compiling PCRE to use heap instead of stack for pcre_exec()

       In  environments	 where	stack memory is constrained, you might want to
       compile PCRE to use heap memory instead of stack for remembering	 back-
       up  points  when	 pcre_exec()  is running. This makes it run a lot more
       slowly, however.	 Details of how to do this are given in the  pcrebuild
       documentation. When built in this way, instead of using the stack, PCRE
       obtains and frees memory by calling the functions that are  pointed  to
       by  the	pcre_stack_malloc  and	pcre_stack_free variables. By default,
       these point to malloc() and free(), but you can replace the pointers to
       cause  PCRE to use your own functions. Since the block sizes are always
       the same, and are always freed in reverse order, it may be possible  to
       implement  customized  memory handlers that are more efficient than the
       standard functions.

   Limiting pcre_exec()'s stack usage

       You can set limits on the number of times that match() is called,  both
       in  total  and recursively. If a limit is exceeded, pcre_exec() returns
       an error code. Setting suitable limits should prevent it	 from  running
       out  of	stack.	The  default  values of the limits are very large, and
       unlikely ever to operate. They can be changed when PCRE is  built,  and
       they  can  also be set when pcre_exec() is called. For details of these
       interfaces, see the pcrebuild documentation and the  section  on	 extra
       data for pcre_exec() in the pcreapi documentation.

       As a very rough rule of thumb, you should reckon on about 500 bytes per
       recursion. Thus, if you want to limit your  stack  usage	 to  8Mb,  you
       should  set  the	 limit at 16000 recursions. A 64Mb stack, on the other
       hand, can support around 128000 recursions.

       In Unix-like environments, the pcretest test program has a command line
       option (-S) that can be used to increase the size of its stack. As long
       as the stack is large enough, another option (-M) can be used  to  find
       the  smallest  limits  that allow a particular pattern to match a given
       subject string. This is done by	calling	 pcre_exec()  repeatedly  with
       different limits.

   Changing stack size in Unix-like systems

       In  Unix-like environments, there is not often a problem with the stack
       unless very long strings are involved,  though  the  default  limit  on
       stack  size  varies  from system to system. Values from 8Mb to 64Mb are
       common. You can find your default limit by running the command:

	 ulimit -s

       Unfortunately, the effect of running out of  stack  is  often  SIGSEGV,
       though  sometimes  a more explicit error message is given. You can nor‐
       mally increase the limit on stack size by code such as this:

	 struct rlimit rlim;
	 getrlimit(RLIMIT_STACK, &rlim);
	 rlim.rlim_cur = 100*1024*1024;
	 setrlimit(RLIMIT_STACK, &rlim);

       This reads the current limits (soft and hard) using  getrlimit(),  then
       attempts	 to  increase  the  soft limit to 100Mb using setrlimit(). You
       must do this before calling pcre_exec().

   Changing stack size in Mac OS X

       Using setrlimit(), as described above, should also work on Mac OS X. It
       is also possible to set a stack size when linking a program. There is a
       discussion  about  stack	 sizes	in  Mac	 OS  X	at  this   web	 site:


       Philip Hazel
       University Computing Service
       Cambridge CB2 3QH, England.


       Last updated: 03 January 2010
       Copyright (c) 1997-2010 University of Cambridge.

                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server QNX

List of man pages available for QNX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net