Patterns for LocalPlayer

Posts 16–18 of 18 · Page 2 of 2

Originally Posted by WasserEsser

You said you don't think there is a good reason to use uintptr_t to store the result of a pattern scan, a function which will return you a pointer to a memory location which can't be negative since it's a pointer

I'm not sure of what he is doing (what is FindPattern()? how do you know what it is? what does it return? how do you know what it does return?), but why do you need an uintptr_t / intptr_t, if not for pointer arithmetics? That's why they do exist (they convert your pointer to an integer to flip their bits, XOR them, etc. - and it can be NEGATIVE when converted in a signed long). If you don't need this numeric value, why do you use those types?) - if I didn't need to do pointer arithmetics, I would perfectly have used an unsigned long/long/int32_t/uint32_t/int64_t/uint64_t (depending on your implementation), or for example assuming that function returns a DWORD I would have used a DWORD - or if I want, I could just use auto. But as I've already said, _when_ just storing an address, it's better to use void*, still better than having big data types like intptr_t/uintptr_t to hold addresses.
It's hard to understand what he is trying to do. So I'd suggest a site for OP: http://xyproblem.info/ⓘ

Using an intptr_t doesn't make any sense, since, you said it yourself, a pointer can't be negative

It gets converted to an integer which can be negative. Following your reasoning, intptr_t shouldn't even exist, which is wrong as intptr_t doesn't work with actual addresses, but with the integer converted one. As I've already said, it's unclear what OP is trying to do. When he needs to use intptr_t instead of uintptr_t for pointer arithmetics, he must use it.

Originally Posted by WasserEsser

On top of that, it can happen that your pointers point to a location over 2GB in RAM, which then breaks your application because your intptr_t is only capable of handling 2 GB instead of 4 GB like uintptr_t is capable of handling ( very specifically talking about 32 bit here ).

The minimum size of intptr_t is sizeof(void*), 4 bytes (32 bit) - the maximum size is not defined by the standard, but it is for sure 4GB (it's the same for uintptr_t, so you are incorrect). After 2GB you get the negative value on intptr_t, where is the roblem of the crash? Please, elaborate. The addressable space is 4GB.

Originally Posted by WasserEsser

uintptr_t is the type to choose when your cant use a pointer to a class (for instance if you have none).

When working with pointers, you won't use bitshifting, and if you'll ever ever use it, you can just cast your pointer to an integral type.

Bitshifting is another example. In this sentence I wasn't referring to bitshifting, but to rightshifting:

you need to use the correct unsigned or signed type to get for example the correct shift.

you need to use the correct signed or unsigned type for tagged pointers to get the rightshift.

other than this, it's plausible you are proving you are prig, be more respectful and reply with humility (which is the keyword beyond every programmer) to deserve an answer.

Originally Posted by javalover

FindPattern is to 99,9% a typical pattern matching function which iterates over a memory segment and compares the bytes to a given pattern and returns you the address at where it found the pattern if it did find it. This won't be a negative value because pointers can't be negative. You will not do anything else other than adding an offset, subtracting an offset or multiplying by a given index. uintptr_t is perfectly reasonable for this case. Of course you can use uint32_t in these cases as well, but there is no downside of using uintptr_t. There are downsides to using intptr_t over uintptr_t, though. This thread is in no way focused on working with negative values, ever. Why do you keep bringing up the intptr_t type when there won't be any negative value in these scenarios? All he is working with is a pointer to a certain memory segment. Nothing else.

Originally Posted by javalover

- and it can be NEGATIVE when converted in a signed long).

Why would you even convert this pointer, pointing to a memory region you want to access someday, into a signed long? There is absolutely no reason to do this.

Originally Posted by javalover

If you don't need this numeric value, why do you use those types?) - if I didn't need to do pointer arithmetics, I would perfectly have used an unsigned long/long/int32_t/uint32_t/int64_t/uint64_t (depending on your implementation), or for example assuming that function returns a DWORD I would have used a DWORD - or if I want, I could just use auto. But as I've already said, _when_ just storing an address, it's better to use void*, still better than having big data types like intptr_t/uintptr_t to hold addresses.

That's opinion based. I would have prefered a uint32_t/uint64_t here as well, but it's not wrong to use uintptr_t in this case. It is however completely unnecessary to use intptr_t instead of uintptr_t when you will never ever work with negative values and you will have to deal with intptr_t not being able to cover positive numbers as large as a uintptr_t is capable of hold.

Originally Posted by javalover

Originally Posted by WasserEsser

You are correct, i was completely wrong about this one.

I still stand by my point, intptr_t should NOT be preferred over uintptr_t in the scenario of this thread. There is no reason to use it as the values won't be negative and you won't work with negative values. If you're using intptr_t instead of uintptr_t, you will have problems with the large positive values and you will have to do conversions that are completely unnecessary, just because you chose a signed type whose reason is not needed at all.

Originally Posted by WasserEsser

I have a function called CoffeeMaker(), then it means it makes me coffee, to all intents and purposes. Right? That's a good conjecture. Why do you insist that you know what _his_ FindPattern() implementation is, when you actually don't?

Originally Posted by WasserEsser

This won't be a negative value because pointers can't be negative

Let me repeat it once again: pointers can't be negative (never said that). However, intptr_t and uintptr_t types convert these pointers in a long int. Can integers be negative? Yes.

Originally Posted by WasserEsser

uintptr_t is perfectly reasonable for this case

If he is trying to do pointer arithmetics, yes it may be. Else, no it isn't. uintptr_t / intptr_t are used just for pointer arithmetics (and very rarely), they convert your pointers to integers, something that you don't need to have (you don't need those addresses stored as integers) if you actually don't need to do integer arithmetics to pointers.

Originally Posted by WasserEsser

There are downsides to using intptr_t over uintptr_t, though. This thread is in no way focused on working with negative values, ever.

I'd suggest you to stop reading from wikis (Stackoverflow, in this case) and post the first thing you understand about the disadvantages of my suggestions just to oppose. I am a Stackoverflow user with an high reputation, I can publicly write intptr_t is bad - does this mean it is right, just because it's Stackoverflow or whichever other good programming forum? In fact, you should document yourself from a reference.
Forget about preferences and prejudices. If intptr_t exists, it means it has purpose to exist. If it was just a bad and useless alternative to uintptr_t, I don't think it would have existed.

Originally Posted by WasserEsser

That's opinion based. I would have prefered a uint32_t/uint64_t here as well, but it's not wrong to use uintptr_t in this case. It is however
completely unnecessary to use intptr_t instead of uintptr_t when you will never ever work with negative values and you will have to deal with intptr_t not
being able to cover positive numbers as large as a uintptr_t is capable of hold.

It's nothing about opinion based. Firstoff, you can't say which you would have preferred, since he hasn't still posted his implementation of FindPattern(), secondly, if it's impossible to work with negative values then try to answer why intptr_t does exist. It's simple: you CAN work with negative values. Both uintptr_t and intptr_t have two different meanings, and they are needed in similar but different scopes.

Originally Posted by WasserEsser

Why would you even convert this pointer, pointing to a memory region you want to access someday, into a signed long? There is absolutely no reason
to do this.

It's what intptr_t does, while uintptr_t converts your pointer into an unsigned long. You suggest to use uintptr_t but then you say there is no reason to deal with converted pointers to signed/unsigned long s (when it actually does), it's a bit incoherent.

However, TL;DR, summarizing: uintptr_t and intptr_t are used for integer arithmetics on pointers (so I've supposed OP was using them for that). I've just
said that intptr_t may be needed in some cases when you do integer arithmetics on pointers, but I'm not even sure he knows what he is doing.