From e782274ade8d7307e157a997d6ac3bcaa4130024 Mon Sep 17 00:00:00 2001 From: fusion32 Date: Wed, 2 Jul 2025 13:28:45 -0300 Subject: `query.cc` --- TODO.md | 27 ++++++++------------------- 1 file changed, 8 insertions(+), 19 deletions(-) (limited to 'TODO.md') diff --git a/TODO.md b/TODO.md index ab216b8..165acd0 100644 --- a/TODO.md +++ b/TODO.md @@ -1,6 +1,12 @@ -## TODO NEXT -- QUERY.CC +## Synchronization +I'm not sure whether synchronization is done properly. The implementation of the first few `crplayer.cc` functions left me with a taste of race conditions although integer loads on x86 are generally atomic. + +## Threading +After some initial dive into `communication.cc`, it has become clear that the original codebase relied on `LinuxThreads` which, among its quirks, assigns different PIDs to different threads, explaining the usage of `getpid()`. It also seems it could lack automatically managed thread stacks which explains `CommunicationThreadStacks`. +We'll have to address this BEFORE trying to run the server. + +## TODO (LEFTOVER) - Include `x == 0xFFFF` inside `CheckVisibility`? - The map container uses type id zero but it seems to also be used as a "no type" id which makes me want to add some `isNone()`, `isNull()`, `isVoid()` check to @@ -17,23 +23,6 @@ - Define a few constants like `MAX_NAME_LENGTH`, `MAX_SKILLS`, and `MAX_OPEN_CONTAINERS` instead of relying on `NARRAY`. -## Stack allocations -Any functions that use `alloca` or some other form of dynamic stack allocations will cause it to be an absolute mess. It usually shows up in the decompiled code as both a size computation like `-(VAR + CONST & 0xfffffff0)`, followed by some assignment. It doesn't make total sense without looking at the disassembly. I've encountered ~30 such computations and expect the functions containing them to be amongt the most challenging/annoying to be properly decompiled. - -## Exceptions -It's absolute hell. - -## Synchronization -I'm not sure whether synchronization is done properly. The implementation of the first few `crplayer.cc` functions left me with a taste of race conditions although integer loads on x86 are generally atomic. - -## Threading -After some initial dive into `communication.cc`, it has become clear that the original codebase relied on `LinuxThreads` which, among its quirks, assigns different PIDs to different threads, explaining the usage of `getpid()`. It also seems it could lack automatically managed thread stacks which explains `CommunicationThreadStacks`. - -We'll have to address this BEFORE trying to run the server. - -## Estimate -The decompiled file has ~115K lines of C. If we take ~15K lines to be rubbish, this can be round to ~100K. Considering a low estimate of 200 lines per day, the whole process could take up to 500 days which is quite a bit but not impossible. Now considering a high estimate of 1K lines per day, it could take 100 days which is also quite a bit. - ## TODO AFTER FIRST PASS - Remove VTABLE comments. - Split NPC, Monster, and Player into separate header files. -- cgit v1.2.3