Thanks.

Hey all. Doing some work for a client and there was a problem with a specific code being put into each document. It needs to be popped. I can do that myself.

What I need to know is whether or not a string saved from a loaded file (using print #x) will screw with the UTF-8 encoding.

Thanks for the tip. Looks like a useful tool.

I found a workaround which should work. Instead of returning a string, it writes directly to a file, discarding the strings as soon as they're generated. That should preserve the memory space, hopefully. I'm running tests on it now.

I think I understand what is happening here. You're right. It's exhausting the heap.

Does this explain why redundant calls to the same function cause a heap overflow regardless of whether the string is large enough to overflow the heap?

Well I could do that. But I'm not sure how fxm arrived at the conclusion that I was exhausting the heap space so I need some way to test that theory.

It should also be noted that the program segfaults on redundant calls to the same function, even with proper destructors in place. #ifndef NULL #define NULL 0 #endif #DEFINE DBLQUOTE ascii(34) dim shared as string*1 ASCII(255) for i as integer = 0 to 255 ASCII(i) = chr(i) next function IsWhite(c as ...

If (as fxm said) my program was segfaulting because the heap had been exhausted, is there some way to catch that error and halt execution before the program segfaults? Would help if it worked under both linux and windows.

The GUI I developed for flatland will work under linux because it uses Cairo and fbgfx. But I've been using FLTK and it works great. Much more powerful. I develop for both Windows and Linux.

I just suck at memory management and understanding when destructors are called and whatnot. I have it working ok now.

The code appears to call the destructor and for some reason there appears to be extra empty variables. When I call this from an extended object, it segfaults. I dunno what's going on. #include once "Parsing.bas" #ifndef NULL #define NULL 0 #endif #DEFINE ___DEBUG #DEFINE DBLQUOTE ascii(34)...

Why would a destructor that otherwise functions properly segfault on an object destruction called from an extended variable?

Nice catch! Thanks!

Could be the recursions. I have no idea. I don't think this is expected behavior.

That is the issue right there. I have no idea why it's segfaulting or why the size of the string should matter if the memory is allocated properly.