Previously, Config->InitialMemory/MaxMemory were hooked up to some commandline args but had no effect at all.
Good question - it's not so much adding a flag, as fixing an existing broken flag, but you're right. I'm not aware of any current users, but I was planning to use it myself in my own projects, to help catching any memory leaks.
This can be Config->InitMemory % WasmPageSize != 0
error: -initial-memory=<value>: value is not aligned to 4096 bytes
is more common style of an error message.
This else looks odd because if there is an error in the first if, the control reaches here, but if there is an error in the second if, it doesn't. Maybe we should just set it unconditionally. We won't use a value if there's an error because we'll exit before we use a dummy value.
OK, it's just copied from the block above however where the same idiom is used. Should compile down to the same thing.
OK, I'll tidy that in a future commit. Thanks.
You say we'll exit before we use a dummy value - but I don't think exit is no-return?
In particular, if exit returns then we'll carry on to the MaxMemory block below, which uses MemoryPtr, so we have to leave this block with a "safe" value for MemoryPtr.
That was my logic anyway.
I mean error() counts the number of errors we've seen and before calling write(), we first check if the counter is zero, and if not, we return without calling that function (which will result in existing from the program.) So we do not really care too much about a wrong value in Config.
And with this code, a wrong value could still be set to MemoryPtr. If the first error test passes but the second test succeeds, this line is executed. That's inconsistent.