Closed norayr closed 7 years ago
That code is really complex :-(. My initial guess is a mismatch between pointer size and LONGINT size, either in assumptions by the ulm code, or one I haven't yet found in the compiler.
I'm concentrating at the moment on an issue from Arthur to do with File access on Windows that I really want to get to the bottom of, so won't get to this for a little while yet.
Assuming you are building on a 64 bit machine, do you have a 32 bit machine you could test this on?
-- Dave.
On 2016-11-30 15:43, Norayr Chilingarian wrote:
procedure ulmPrint.Out gets parameter 'nargs'.
When function gets called via ulmWrite.Int, 'nargs' argument receives 2, it's visible in debugger upon entering the function.
Then the generated code looks like this:
struct Out12 _s; _s.out = &out; _s.fmt = (void*)fmt; _s.fmtlen = fmt__len; _s.nargs = &nargs; _s.p1 = (void*)p1; _s.p1len = p1len;
Out__12 _s is used by compiler for implementing nested functions. Then, when we enter SetSize nested function, *Out__12_s->nargs is some very big number, in the case right now 17179869186. That's why,
WHILE index < nargs DO
in SetSize function which looks like
static void SetSize65 (void) { INT32 index; index = 0; while (index < *Out12_s->nargs) { switch (index) {
goes to the long loop.
By the way, the CASE statement was not compiled, there was a warning 307 (no ELSE symbol after CASE statement sequence may lead to trap) and then compiler was stopping, by saying 'assertion failed'. Unless I've changed case sequence by adding ELSE before closing END.
Memory model I am trying to use is default, -O2.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].
[1] https://github.com/vishaps/voc/issues/52 [2] https://github.com/notifications/unsubscribe-auth/ADChoD9i7AIsiYo9edseGetYxJ_i1WFGks5rDZmLgaJpZM4LAVnC
My last checkin fixed an issue with generated variable declaration code in intermediate structs like the scenarion you found: could you build again and see if this particular issue is fixed? Thanks -- Dave.
yes! thank you! now *Out__12_s->nargs is '2' as well, and the while loop exists correctly.
procedure ulmPrint.Out gets parameter 'nargs'.
When function gets called via ulmWrite.Int, 'nargs' argument receives 2, it's visible in debugger upon entering the function.
Then the generated code looks like this:
Out__12 _s is used by compiler for implementing nested functions. Then, when we enter SetSize nested function,
*Out__12_s->nargs
is some very big number, in the case right now 17179869186. That's why,in SetSize function which looks like
goes to the long loop.
By the way, the CASE statement was not compiled, there was a warning 307 (no ELSE symbol after CASE statement sequence may lead to trap) and then compiler was stopping, by saying 'assertion failed'. Unless I've changed case sequence by adding ELSE before closing END.
Memory model I am trying to use is default, -O2.