Ternary operator using stupid stack sizes.

[Alex Cole]

I have NO clue how I've done this, but I do know that I exploit just about every compiler corner-case going, so I'm doing some pretty wierd things to begin with!  Somehow, I've managed to break the compiler to the point where it starts doing this:

heap 367cbe0

With perfectly normal ternary operators:

printf("%d", i ? 6 : 7);

The exact assembly generated for that statement is:

    ;$exp
    ; line 3a
    break    ; eeec8
    load.s.pri fffffffc
    jzer 36b3
    heap 367cbe0
    const.pri 6
    jump 36b4
l.36b3
    heap a4
    const.pri 7
l.36b4
    heap 4
    stor.i
    move.pri
    push.pri
    ;$par
    const.pri 2d65e4
    push.pri
    ;$par
    push.c 8
    sysreq.c 35    ; printf
    stack c
    heap fffffffc
    heap ffffff5c

Clearly something has gone horribly wrong!  I should note that this is in the 3.2.3664 compiler, so I was more wondering if this was a known bug that had been fixed as I couldn't find any references to it.  I'll continue to try narrow down where the exact issue is, unfortunately at this point testing the problem on later compilers is very difficult, as I say I use a lot of corner-cases so my code isn't that portable.  Quite WHY it chooses to do this I have no clue.  I have no doubt that it is a result of some other code that somehow manages to break every ternary operator, because a stand-alone script with no silly libraries doesn't have this issue and generates these correctly.

[Alex Cole]

OK, I've managed to produce a minimal test case:

#pragma tabsize 4
#pragma semicolon 1
#pragma ctrlchar '\\'

stock SomeFunction()
{
#if defined __COMPILER_SECOND_PASS
    for (new loop = 1; loop; loop = (loop ? 0 : 1))
#endif
    {
    }
    return 0;
}

main()
{
    return SomeFunction() ? 0 : 1;
}

static stock __COMPILER_SECOND_PASS() {}

When I compile this with 3.2.3664 it gives excess heap allocations on the final "return" of the code.  When I compile this with 4.0.4733 I get:

Assertion Failed: result, function hier13, file sc3.c, line 1197.
ABNORMAL TERMINATION

Which does seem to confirm that there is a bug in heap allocation somewhere and that it still exists.  I don't have any other compilers compiled on which to test.

[Alex Cole]

Actually, you don't even need the loop:

new gVar;

stock SomeFunction()
{
#if defined main
    gVar = (gVar ? 0 : 1);

[Alex Cole]

Sorry, I can't figure out how to edit messages (probably as they're emails).  Just a note that I first reported this here:

http://forum.sa-mp.com/showpost.php?p=2508346

As I'm Y_Less from the SA:MP forums.