Question: I have a problem with parsing mongo query from string when the query contains regex filter.

the filter definition is created by 

```
var bson = BsonSerializer.Deserialize<BsonDocument>(query);
var definition = new BsonDocumentFilterDefinition<CellDo>(bson);

```

The query looks like this:

```
{
   "description": {
      "$regex": /\w*\.a\b/
   }
}

```

But when the query is passed serializer throws an exception saying `JSON reader expected a string but found '/\\w*\\.a\\b/'.`

I tried to wrap regular expression in strings - the expression is treated as string so doesn't really help and I have also wrapped the expression into RegEx call, but it just thrown exception `JSON reader expected a string but found 'RegExp'.`

The queries looks like this:

```
{
    "description": {
        "$regex": "/\w*\.a\b/"
    }
}

```

```
{
    "description": {
        "$regex": RegExp(/\w*\.a\b/, "")
    }
}

```

We are currently using mongo from docker image `mongo:4.2.6-bionic` and `MongoDB.Driver 2.10.3`

Answer: 
This program using a compiler extension to allow variable sized arrays in the form `myArray[variableSize]`. Whilst not standard, it does work on some compilers.

You are using this feature here:

```
int n, A[n];

```

However, `n` is uninitialised at this point. This is undefined behaviour even on the compilers that support such variable sized arrays. One possible (but not the only) outcome of undefined behaviour is your program crashing.

Undefined behaviour can do anything in theory, but the realistic set of things in can do in reality is smaller. Some of the likely implications of the undefined behaviour here:

1. `n` has some huge number in it, from whatever last used that bit of memory. As a result, `A` is huge.
2. `n` is 0. You can't have a 0 sized array. If the compiler doesn't notice this, you could end up trashing memory.
3. Since `n` is uninitialised, the optimiser for the compiler (they usually do very some optimisations, even when on -O0) assumes that undefined behaviour cannot occur, which is violated here, leading to strange behaviour.
4. `n` is a reasonable value, just by luck, but because it is later updated it no longer matches the size of the array and you end up reading / writing memory off the end of the array, trashing memory.

There are other possibilities, but this gives an idea of the kind of things that can happen as a result of this specific instance of undefined behaviour. If you're interested to know more, using a debugger to step through the code in assembly (you only need learn a little to understand the output, it looks more scary than it need be) will show you what's actually happening.
Passing variable as array size is not valid you need to use constant `const int n` or create dinamic array `int* arr = new int[n];`, that array will be created in runtime, and you can pass variable as it size. Dont forget to delete that array whet it goes out of scope `delete[] arr;`