Revert "Re-use IF code for ELSE IF"

[Lartu]

Reverts #43

[Lartu]

@dvkt I have reverted your pr. Reusing the code broke ELSE for the 3.0.0 release 😓 so I'm reverting back to my version where everything worked fine. I'll add a notice to the release page saying ELSE is broken and that they can use ELSE IF 0 IS EQUAL TO 0 as an alternative.

[xvxx]

Oh okay, drat! Do you have an example? ELSE still works for me but maybe this case is too simple:

procedure:
if 1 is greater than 2 then
    display "gt"
else
    display "lt"
end if
display crlf

$  ldpl ok.lsc ; ./ok-bin
LDPL: Compiling...
* File(s) compiled successfully.
* Saved as ok-bin
lt

[Lartu]

Ah, sorry. You have to use ELSE IF along with ELSE. At least it wasn't working for me. Try the Brainfuck interpreter example.

[Lartu]

No, sorry, that one doesn't use ELSE IF. Try https://github.com/lartu/LBI

[xvxx]

Ah damn okay, yeah. It works on Mac but I get SIGSEGV on Linux - is that what you're getting? I'll take a look soon.

[Lartu]

Yes! That's what I'm getting on Linux. It's so weird that works on your mac! Do you have LDPL 3.0.0 there as well? (please mind that today I uploaded 3.0.1 with some bugfixes and your identifier obfuscation system so it might be running that version).

[xvxx]

Okay, I know what's going on now - sorry about this. I was intentionally relying on vector::operator[] returning gibberish when given an out-of-bounds index on Mac, thinking it was some C++ fancy magic, but it's just undefined behavior. So it works on Mac and crashes on Linux.

I was able to replicate it with this simple program:

#include <vector>
#include <string>
#include <iostream>
using namespace std;
int main(){
  vector<string> tokens;
  tokens.push_back("ELSE");
  if(tokens[1] == "IF") cout << "wut?" << endl; // intentional out-of-bounds access
}

Which I ran on both OSes with:

c++ -std=gnu++11 wut.cpp -o wut

Maybe there is a -Warning or some other compiler flag I can use to tell me when I'm relying on clang-dependent behavior (read: doing something stupid) in the future.

[Lartu]

Oh I get it. Very weird that Clang works that way, I have just used GCC on Mac. Glad to hear you found the problem!