I did correct that mistake, yes. stringize_array( array ) is called to save a JSON variable as a JSON object. Here is the entire file with an example. As you can see it works. However, the pass segfaulted when there was an array of objects (of the exact same type as the example) with over 2 million ...

Never mind. Text was empty.

I'll take a look through later when I'm back home. But under -EXX (compiled under Linux LXLE) I'm getting an illegal function call on the line:

redim preserve outArr(numberSubString-1)

(Windows too. It does not want to compile under -exx.)

I'm not sure seeing the code would help. It only happens given the condition that I send a JSON array with 2 million indexes to a stringize function. The offending code is somewhere in here: function stringize_array( byref v as variable ) as string if v.typ <> varType._ARRAY_ then return ""...

yay! lol

Wtf is that?

*** Error in `./stat_builder': free(): invalid pointer: 0xbff3dfe8 ***

Aborting due to runtime error 14 ("abnormal termination" signal) in /home/jynx/Desktop/im4/json_parser.bas::()

This is much faster. Pre processes the spots where delims are then uses mid to carve up the string. Array is then copied to eliminate empty indexes. sub splitOver2( byval txt as string, byval delim as string, outArr() as string ) txt &= chr( delim[0] ) dim as integer spots(), lentxt = len(txt)-1...

I made a JSON parser awhile back. Out of curiosity, can yours parse indefinitely nested arrays and objects? Mine has no XML compatibility.

The algorithm must be able to split a string over multiple delimiters (not just one). It outputs the split strings as an array. The algorithm works well for a standard text of 1 million chars or less. But when it gets around 16 million, well.. Hours of my life are robbed from me. The call goes like ...

Derp. Thanks fxm. Obvious mistake.

I can't seem to hunt down the reason for this segfault. I've traced the problem to the LET operator :: variable.Let( byref rhs as variable ) :: but I can't seem to figure out how to fix it. Maybe I'm tired or my brain is fried but any help would be appreciated. #include once "parsing.bas" ...

Macros process code the exact same way the compiler does. It is a literal swap. That means that it should process the code identically to how the compiler processes it, but in this case, and for an unidentified reason, it was eating one of the lines (the first line in the macro).

That would explain it. There are dynamic arrays in the UDT.

The answer to your question is *probably*. I don't think there would be any issues with initializing a shared UDT in a constructor at this stage of FB's development that no one else has run into before mine. That being said, I don't know exactly what in there it's crashing on. And I don't know why -...

No, that won't work. The colon starts a new line.