Patterns for LocalPlayer

should be the correct one
ZacZero made post about this check it out it may help you
http://www.mpgh.net/forum/showthread.php?t=1197536

I posted this ages ago and it still works:

I don't think there is a good reason to use uintptr_t when you want to store a pointer. However, you should use freopen_s(), freopen() is deprecated:

No reason not too use uintptr_t in the case of csgo anyway. Also the function is only deprecated for security reasons and those are not an issue for me

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

You also missed dereferences. You are storing pointers to pointers to the local player. You would want to dereference once and get a reference to the pointer pointing to the local player.

You are currently subtracting client dll from the address of the pattern. The pointer is inside of the instructions and you would want to extract it out of it.

Firstoff, you are using C-style casts, which should be avoided for some reasons. Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values. I don't know which one you need, evidently because I'm not a guy with the gift of the prediction. However, intptr_t and uintptr_t are not guaranteed to exist (they were firstly introduced in C99), and from your example I can see you are just storing a pointer to something, so you can just cast it to void* also because you don't need big integer types like intptr_t/uintptr_t to hold a pointer value. Ofcourse, when you can you should avoid casts.

@WasserEsser you quoted me instead of him. I'm not the author.

Because I was specifically referring to your post about uintptr_t.
When will your pointers be negative, though?

It has nothing to do with negative pointers. If you care of your numeric value of your pointer (eg. you need to do arithmetics with it and other), then you need to use the correct unsigned or signed type to get for example the correct shift.

Sorry, when will you ever bitshift a pointer to a memory location in a game?
You'll at most add or subtract.

I didn't never talk about negative pointers, I did talk about negative values. The difference is that the pointers cannot be negative, because they are not integers.
Quote the part of the answer where I did talk about negative pointers.

Why do you take for granted he never has to bitshift into a memory location? Game or not, it's still an executable - and if he needs to when he has his good reasons, he can. However, it's an generic example. I will do a more in-context example: uintptr_t and intptr_t are 8-bytes, my value I want to get is 8-bytes too. Assume I know it will be negative (eg. similar to -60), I'd use a pointer to a signed value (intptr_t) to get the correct interpretation of that value, otherwise with uintptr_t I'd get a meaningless value.

You're completely ripping this out of the usecase of this thread.
This thread is all about storing the result of a pattern scan, which will result in a pointer to some memory location, be it an entity, a function, an address of a certain instruction or another offset.
These values will not be negative nor will you ever bitshift them.

Also, they will be 4 bytes since we're working with 32 bit process here.

Probably it wasn't if you didn't ask me about negative values. I didn't see any problem to reply you.

These values can be negative depending on how you interpret it (signed/unsigned). If you always interpret them as uintptr_t, ofcourse you won't see it is negative, rather you'd see a meaningless value (like 92380493092 instead of a signed -60) - the bitshifting was an example on why sometimes you need to distinguish them. This long discussion about intptr_t/uintptr_t started when you asked me about negative values:
and if he needs that value, he will need to apply an intptr_t or uintptr_t, depending on his context. I'm not going to repeat things. If you want to read my whole answer, good for you, else don't expect another answer from me.

CS:GO is a 32 bit process, and it will be 4 bytes because you are a Windows user. In Linux we are talking about a 64-bit process, so in my case it's 8-bytes - sorry if I don't use Windows, dear WasserEsser. Maybe you'd prefer the example as this:
- - - Updated - - -

uintptr_t and intptr_t are 4-bytes (in Windows), in your case obviously because CS:GO is a 32-bit process, but not here.

Let me just break this down in chronological order here:

Okay, let me start with these two of your posts:

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. That doesn't even make sense. The discussion began when you said you don't think it's good to use uintptr_t. Using uintptr_t in this case is EXACTLY the way to go. Using an intptr_t doesn't make any sense, since, you said it yourself, a pointer can't be negative. Sure, you can use intptr_t to store pointers, but it doesn't make sense to use it over uintptr_t since a pointer can't be negative. 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 whole topic here, and my answers were all referring to this, is about storing a pointer returned by a findpattern function. What I was talking about the entire time is that intptr_t is not to be preffered over uintptr_t.

As seen above, i was always referring to the topic of storing a pointer. Negative values are not the topic here.
Your arguments are that if you use intptr_t, you can use, for example, bitshifting.

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.
It can much rather happen that your pointer exceeds the 2 GB boundary than the case that you'll ever want to be able to bitshift your pointers.

Again, you will NOT work with negative values at all since we're working with pointers here. I don't get why you're throwing arguments about negative values in this topic when all we're talking about here are pointers.