#pentagram@irc.freenode.net logs for 21 Nov 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[01:58:50] --> Kirben has joined #pentagram
[01:58:50] --- ChanServ gives channel operator status to Kirben
[06:27:54] --- Darke|zzZ is now known as Darke
[07:02:01] --- Darke is now known as Darke|afk
[10:21:19] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[10:24:03] --> Kirben has joined #pentagram
[10:24:03] --- ChanServ gives channel operator status to Kirben
[10:45:21] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[11:45:06] --> Kirben has joined #pentagram
[11:45:06] --- ChanServ gives channel operator status to Kirben
[11:56:21] --> Colourless has joined #Pentagram
[11:56:21] --- ChanServ gives channel operator status to Colourless
[12:26:39] <-- Kirben has left IRC ("System Meltdown")
[12:28:38] --- Colourless is now known as Cless|Away
[12:51:49] --> Kirben has joined #pentagram
[12:51:49] --- ChanServ gives channel operator status to Kirben
[13:54:20] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:20:53] --- Cless|Away is now known as Colourless
[15:10:36] --- Darke|afk is now known as Darke
[15:41:23] * Darke bleahs. And still hasn't worked out exactly how to handle the 'dangling else'. Detecting it seems to be almost impossible.
[15:44:34] <Darke> Currently the 'only' solution seems to involve a second pass through all the nodes, looking for an IfNode specialised to either IF_ELSE_IF, or ELSE_IF_ELSE without an IfNode directly after specialised to IF_ELSE_IF or ELSE_IF_ELSE.
[15:45:17] <Colourless> well i would generally think that jmp opcodes would be the clue
[15:45:27] <Darke> Therefore, logically either I'm missing an option, or the logic to the way I'm handling if/elseif's is wrong. *ponder*
[15:46:14] <Darke> *nod* That's how I can tell if an if node is a plain IF or a IF_ELSE variant. *grin*
[15:46:21] <Colourless> you'll usually get something looking like this for an if and then else statement
[15:46:30] <Colourless> sometest
[15:46:36] <Colourless> jne to else statement
[15:46:41] <Colourless> code
[15:46:45] <Colourless> jmp to end of else statement
[15:46:49] <Colourless> more code
[15:47:45] <Colourless> you need to remember that else if() statments are actually the same as else { if... }
[15:48:14] <Colourless> else if is just a method to save typing ;-)
[15:49:42] * Darke nods and ponders.
[15:50:28] * Darke hunts through the large collection of 'data' and variables he has at that point in time, to see if he can detect it.
[15:51:35] <Darke> Unfortunately, at that point in time I don't have access to the scope of the previous ifnode, I'd have to search back through the stack until I find it, then test if it is really a variant of IF_ELSE.
[15:52:06] <Darke> Actually, maybe not. Time to throw some tracing in I suppose. *grin*
[15:56:31] <Colourless> what 'i' would attempt to do first would be to find out what each jmp opcode is being triggered by. if unk supported goto instructions then it will be infuriatingly annoying since things might just not make any sense if there is a goto within an if statement
[16:03:20] <Darke> If unk supports goto we're stuffed (or at least I am anyway *grin*), unless we're willing to go through by hand and untangling the extraneous logic after we decompile them. Gotos are evil because they create non reversable (at least non-trivially reversable) control flow. You need to 'out think' the smart human behind the keyboard, rather then the dumb computer in front of it. *Grin*
[17:01:21] * Darke thinks he needs to do some renaming of variables. He's got three things called 'nodes' all accessable within the same scope at times.
[17:01:42] <Darke> All with identical types too, std::queue<Node *>'s. *grin*
[17:01:46] <Colourless> you = writing unreadable code
[17:02:50] <Darke> Oh no, it's perfectly readable and logical. I'm only renaming it because it's 'bad practice'. You'd have to be deliberately malicious, or completely confused to break things. *grin*
[17:03:54] <Colourless> well i can think of one nicely bad example. you have a std::queue<Node *> nodes in global namespace, in a class, and within a method in that class :-)
[17:04:17] <Colourless> you can technically still access all of them using various methods, but still, ugh :-)
[17:05:06] <Colourless> the methods being (nodes for the one on the functions, this->nodes for the one in the class, and ::nodes for the global namespace)
[17:05:17] <Darke> Nah, nothing that horrible. *grin* Node::fold takes two parameters, a 'unit' (which you can access it's 'global' parameters through unit->nodes), and a parameter called 'nodes'. IfNode also has a local variable called 'nodes' that you need to reference inside fold as this->nodes in the one time you need to. *grin*
[17:06:03] <Colourless> gee, no not 'that' horrible at all, only two thirds as bad :-)
[17:06:52] <Darke> The only potential problem is in one class, in one instance. *grin* And that instance is commented with a 'note what I'm referencing' comment anyway. What's worse is when you're calling this->fold(unit, this->nodes), that is bad. *grin*
[17:07:14] <Darke> (Recursively of course. *grin*)
[17:07:22] <Darke> And that's the _simple_ solution. *grin*
[17:08:06] <Colourless> in theory you should also be able to use Classname::nodes (where Classname is the name of the class that nodes is in)
[17:09:09] * Darke nods. Yup.
[17:09:25] <Colourless> to be particularly evil you need to use both methods to access nodes :-)
[17:10:49] * Darke is, or was actually. The bit of code is commented out and maked for deletion. *grin*
[17:11:09] <Colourless> as i said before:
[17:11:11] <Colourless> you = writing unreadable code
[17:11:59] <Darke> Nope. The reason I commented it out and replaced it was because it was unreadable. *grin*
[17:12:42] <Darke> Also, that this->nodes hack is for... *drumroll* the hack to fix the occasional, unexplainable case where unk seems to turn the if statements outside in. *grin*
[17:15:06] <Darke> In any event, I need to rewrite the logic when I get proper function encapsulation working, currently the 'FuncNode' is wrapping the entire function block up when it gets the 0x7A, rather then starting to 'fold' itself when it gets the init, so the logic will be less illogical then. *grin*
[17:20:44] <Darke> If you want a _real_ hack, then all you need to do is manipulate that 'unit' variable a bit inside a call to fold. For example, for almost any call the fold, you can assert( ( (unit->ifstack.size()) ? unit->ifstack->nodes.back() : unit->nodes.back() )==this);
[18:20:53] --> wjp has joined #pentagram
[18:20:53] --- ChanServ gives channel operator status to wjp
[18:47:27] * Darke yawns and wanders off to sleep. Sun's up already. *grin* Night!
[18:47:39] --- Darke is now known as Darke|zzZ
[19:27:41] <Colourless> cya
[19:27:46] <Colourless> i should go too
[19:27:47] <-- Colourless has left IRC ("casts invisibility")
[21:30:59] --> Dark-Star has joined #pentagram
[21:46:47] <-- wjp has left IRC ("Zzzz...")
[22:13:04] --> Kirben has joined #pentagram
[22:13:04] --- ChanServ gives channel operator status to Kirben