<commit_before><h1 id="limitations">Limitations</h1>

<p>The following is a list of known limitations of the current implementation.
Limitations include shortcomings from a semantics perspective, performance
limitations, and implementation limits (which are inevitable).</p>

<p>Trivial bugs are not listed unless they are "long term bugs".</p>

<h2>No re-entrancy</h2>

<p>A single Duktape heap, i.e. contexts sharing the same garbage collector,
is <b>not re-entrant</b>.  Only one C/C++ thread can call Duktape APIs
at a time for a particular Duktape heap (although the calling thread
can change over time).</p>

<h2>String and buffer limits</h2>

<p>The internal representation allows a maximum length of 2**31-1 (0x7fffffff)
<i>bytes</i> (not characters) for strings.  16-bit codepoints encode into 3
bytes of UTF-8 in the worst case, so the maximum string length which is
guaranteed to work is about 0.7G characters.</p>

<p>Buffer values are also limited to 2**31-1 (0x7fffffff) bytes.</p>

<h2>Property limits</h2>

<p>An object can have at most <code>DUK_HOBJECT_MAX_PROPERTIES</code> (an
internal define).  Currently this limit is 0x7ffffffff.</p>

<h2>Array limits</h2>

<p>When array item indices go over the 2**31-1 limit (0x7fffffff), Duktape
has some known bugs with array semantics.</p>

<h2>Regexp quantifier over empty match</h2>

<p>The regexp engine gets stuck when a quantifier is used over an
empty match but eventually bails out with an internal recursion
(or execution step) limit.  For instance, the following should produce
a "no match" result but hits an internal recursion limit instead:</p>

<pre>
$ duk
duk&gt; t = /(x*)*/.exec('y');
RangeError: regexp executor recursion limit
        duk_regexp_executor.c:145
        exec (null) native strict preventsyield
        global input:1 preventsyield
</pre>

<h2>Regexp quantifier over captures</h2>

<p>When a quantified atom contains captures, the E5.1 specification requires
that the captures inside the quantified are reset to <code>undefined</code>
whenever the quantified is re-matched by the quantifier.  Duktape doesn't
currently do this, which may cause a capture to show through a previous round
if the capture in question is skipped in quantifier matching.</p>

<h2>Regexp dollar escape</h2>

<p>The Duktape RegExp syntax allows dollar escaping (e.g. <code>/\$/</code>)
even though it is not allowed by the E5.1 specification.  RegExp dollar
escapes are used in existing Ecmascript code quite widely.</p>

<h2>Invalid stack indices</h2>

<p>The internal implementation for some stack operations (like
<code>duk_set_top()</code> uses pointer arithmetic.  On 32-bit platforms
the pointer arithmetic may wrap and work in unexpected ways if stack
index values are large enough (e.g. 0x20000000 on a 32-bit platform
with 8-byte packed value type).</p>

<h2>Error handler model incomplete</h2>

<p>The model for error handlers is incomplete.  Use <code>DUK_INVALID_INDEX</code>
as the error handler index for now.</p>
<commit_msg>remove regexp quantifier capture handling limitation from guide (fixed now)<commit_after><h1 id="limitations">Limitations</h1>

<p>The following is a list of known limitations of the current implementation.
Limitations include shortcomings from a semantics perspective, performance
limitations, and implementation limits (which are inevitable).</p>

<p>Trivial bugs are not listed unless they are "long term bugs".</p>

<h2>No re-entrancy</h2>

<p>A single Duktape heap, i.e. contexts sharing the same garbage collector,
is <b>not re-entrant</b>.  Only one C/C++ thread can call Duktape APIs
at a time for a particular Duktape heap (although the calling thread
can change over time).</p>

<h2>String and buffer limits</h2>

<p>The internal representation allows a maximum length of 2**31-1 (0x7fffffff)
<i>bytes</i> (not characters) for strings.  16-bit codepoints encode into 3
bytes of UTF-8 in the worst case, so the maximum string length which is
guaranteed to work is about 0.7G characters.</p>

<p>Buffer values are also limited to 2**31-1 (0x7fffffff) bytes.</p>

<h2>Property limits</h2>

<p>An object can have at most <code>DUK_HOBJECT_MAX_PROPERTIES</code> (an
internal define).  Currently this limit is 0x7ffffffff.</p>

<h2>Array limits</h2>

<p>When array item indices go over the 2**31-1 limit (0x7fffffff), Duktape
has some known bugs with array semantics.</p>

<h2>Regexp quantifier over empty match</h2>

<p>The regexp engine gets stuck when a quantifier is used over an
empty match but eventually bails out with an internal recursion
(or execution step) limit.  For instance, the following should produce
a "no match" result but hits an internal recursion limit instead:</p>

<pre>
$ duk
duk&gt; t = /(x*)*/.exec('y');
RangeError: regexp executor recursion limit
        duk_regexp_executor.c:145
        exec (null) native strict preventsyield
        global input:1 preventsyield
</pre>

<h2>Regexp dollar escape</h2>

<p>The Duktape RegExp syntax allows dollar escaping (e.g. <code>/\$/</code>)
even though it is not allowed by the E5.1 specification.  RegExp dollar
escapes are used in existing Ecmascript code quite widely.</p>

<h2>Invalid stack indices</h2>

<p>The internal implementation for some stack operations (like
<code>duk_set_top()</code> uses pointer arithmetic.  On 32-bit platforms
the pointer arithmetic may wrap and work in unexpected ways if stack
index values are large enough (e.g. 0x20000000 on a 32-bit platform
with 8-byte packed value type).</p>

<h2>Error handler model incomplete</h2>

<p>The model for error handlers is incomplete.  Use <code>DUK_INVALID_INDEX</code>
as the error handler index for now.</p>

{'fraction_non_alphanumeric': 0.09139026111503176, 'fraction_numerical': 0.02328863796753705, 'mean_word_length': 4.657684630738523, 'pattern_counts': {'":': 0, '<': 117, '<?xml version=': 0, '>': 117, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 10, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4987431', 'n_tokens_mistral': 1813, 'n_tokens_neox': 1714, 'n_words': 743}