Quote:
Originally Posted by zgintasz
Y_Less, in that thread you agreed with mine argument why to upgrade to a newer compiler. I don't know why, but as I see, you can find any reason why not to do something that is better for most of people.
|
I agree with the need to update and upgrade over time, and have been doing so for the last 8 years! To put this in perspective:
- Dynamic memory allocation.
- Inline functions.
- Compile-time meta-programming (string hashing).
- One line callback hooking.
- Compile-time parameter checking for remote and timer functions.
- Localisation.
- Data type abstraction.
- Vararg function handling.
- AMX meta-data.
- Inter-script communication.
- Unit test framework.
- Resizable arrays.
- "foreach".
- Compressed bit arrays.
Those are some (most) of the ways I have improved the PAWN language over many years to make coding faster and simpler. Also, from other people:
- Timer fix (Slice).
- Self modifying code (Slice/ZeeX).
- Many more I can't even think of off the top of my head...
The main reason I was opposed to the upgrade was that I didn't feel that sacrificing many of those updates for the sake of a few tiny changes elsewhere was in any way a fair exchange! "We may have lost inline functions, but at least the compiler now makes slightly fewer redundant malloc calls!!! Wooo..."
THAT is why I was so adamantly against the update, especially these "fixes" from pre-4 versions:
3.1.3541 (the compiler may be modified 3.2.3664, but the VM is 3.0.3367):
Quote:
* BUG fix for the sleep opcode: the STK and HEA registers were not updated in
the AMX structure (ANSI C and GNU C versions only; the assembler versions
were correct). Reported and fixed by "chop".
|
Breaks dynamic memory allocation, and thus inline functions and timers that use it.
3.3.3875:
Quote:
* Opcode checking has become stricter: when initializing an abstract machine,
the abstract machine tests the parameters of branch instructions and of
instructions that access data in the data segment or the stack/heap.
|
We already worked around some opcode checking on data access by finding a hole in the checks. Stricter checking results in that hole being closed. This breaks ANY script that uses those techniques to access data it shouldn't:
- Inline functions.
- One line callback hooking.
- Vararg function handling.
- AMX meta-data.
- Unit test framework.
- Resizable arrays.
- Timer fix (Slice).
- Self modifying code (Slice/ZeeX).
ALL gone! So what was introduced in 3.3.3875 in place of these features?
- Overlays and compression - Useful for constrained memory devices, unlike the huge servers that run SA-MP servers.
- Numerous fixes not relevant to SA-MP's use.
- Debug information included extra functions.
- Stack usage was not correctly reported for recursive functions.
- Array comparison - That is more useful I'll admit.
NOW do you see why I was so adamantly against these updates? They introduced trivial updates here and there, with useful upgrades that apply to SA-MP few and far between, while at the same time breaking almost every advance in the PAWN language we have managed to make ourselves.
HOWEVER...
The issue with dynamic memory allocation is actually not hard to work around. The old version did it differently, only the new version uses the heap to avoid huge arrays at compile time. That just requires a reversion. The big issue remains memory access for advanced features, and that again is not an issue. Why? Because I read the wrong version in the first place!
As I said, we bypass memory checks such as this:
pawn Код:
case OP_LOAD_S_PRI:
case OP_LOAD_S_ALT:
case OP_LREF_S_PRI:
case OP_LREF_S_ALT:
case OP_STOR_S:
case OP_SREF_S:
tgt=*(cell*)(amx->code+(int)cip); /* verify address */
if (tgt<-stacksize || tgt>stacksize) {
amx->flags &= ~AMX_FLAG_VERIFY;
return AMX_ERR_BOUNDS;
} /* if */
cip+=sizeof(cell);
break;
That code checks that the parameter to "LOAD.S.pri" and similar OpCodes is within the stack, so that you can't read memory outside it (there are similar checks for LOAD.pri etc for the data segment). The work-around relies on "LREF.S.pri" - this loads a variable, then uses that value as a pointer to load more data. The variable it loads is checked to be within the stack, but the pointer contained in that variable isn't - that being the hole we exploit! That tiny bug has led to MASSIVE improvements throughout, but I just today discovered a mistake I made years ago - I used the wrong AMX version! As I said, the SA-MP server is on version 3.0.3367, which doesn't have ANY of those data segment checks - they ARE the improved ones introduced in version 3.3.3875. Apparently when I was first investigating this I looked at a later version of the source and found a way to bypass the enhanced checks, and not the non-existent checks already in the server, and we've been bypassing the upgraded checks ever since!
So, in short, when I saw that the later versions had "stricter" checking on OpCodes, I assumed this meant "stricter than the checks we already bypass" and not "just the checks we already bypass". So all code using this technique is actually already written for the new version and I no longer have serious objections to upgrades within the 3.x branch. Sorry.
Quote:
Originally Posted by zgintasz
Also, things like workarounds should be fixed internally, like kick with client messages and many things like in fixes include. Because now, honestly, developing for sa-mp sucks a lot, all these workarounds for almost everything, these streamers and etc. If all sa-mp thing would be placed on git, there could be updates every month and not every year.
|
"kick with client message" is NOT a bug, as has been explained MULTIPLE times since the intentionally introduced change.
Also, if the workarounds have already been written, it's not really a hassle even if it should be fixed internally - just include the fixes and go.
