Is this coding or maybe a linux command or something? Pedos sure are smart cookies.

>>25746158 Pointers

Explain what a pointer is and why it's relevant enough to not abstract away from the user? Also explain memory management and why anyone would want to manually manage it instead of having that automated as well. t. monkey

Wha..? No such thing in python

>>25746170 >explain memory management and why anyone would want to manually manage it instead of having that automated as well You wouldn't, but because of poor decisions made in the past we are stuck with C which insists on manual memory management.

>>25746170 In short manual management allows you to avoid overhead and get better performance

>A pointer references a location in memory, and obtaining the value stored at that location is known as dereferencing the pointer. As an analogy, a page number in a book's index could be considered a pointer to the corresponding page; dereferencing such a pointer would be done by flipping to the page with the given page number and reading the text found on that page. The actual format and content of a pointer variable is dependent on the underlying computer architecture. >Using pointers significantly improves performance for repetitive operations, like traversing iterable data structures (e.g. strings, lookup tables, control tables, linked lists, and tree structures). In particular, it is often much cheaper in time and space to copy and dereference pointers than it is to copy and access the data to which the pointers point. Why isn't it done automatically?

First is the one that makes sense, but C was designed by idiots so you're allowed to write shit like int* a, b; which makes no sense.

>>25746170 Because automatic memory management always has drawbacks, like being slow.

>>25746254 actually int *a makes no sense.

c
int* func();

int *a;

int *const a;

imagine doing this and thinking you're in the right.

>>25746219 >Why isn't it done automatically? This is how you go from Software Engineer to "coder".

Do coders really argue about bit? I simply use the first

>>25746387 its fun banter

int *x;

Deal with it. Or go write python scripts lol.

Does C have no automatic formatters?

>>25746466 C is a language, maccharoni snorter. You’re talking tools.

>>25746466 It does, but there is no formatting standard, so everybody configures them differently.

I spent 15 minutes reading about C stuff but it seems more menial and useless than any other programming shit I've seen before. I feel completely buck broken by the 70s.

*x makes more sense

It's a pointer to int, so obviously 1.

>>25746582 int is just the type it's a pointer to x, so obviosuly 2

>>25746586 The type of "x" is "pointer to int".

>>25746586 A pointer is a type different from an int.

where I work we do

int * x;

>>25746595 Gross.

Do you #1 niggas also write v =* p; ?

>>25746615 Dereferencing and declaring a pointer are two completely different things.

>>25746591 >>25746592 it's still a int type it's just pointing to it

I'm used to writing "int *x" because that's how they taught us in school, but "int* x" is more logical because "int*" is a type.

>>25746627 No, it's literally not an int type.

>>25746625 No. In C declarations follow the same punctuation design as the usage.

>>25746642 ...that was the whole point of it, you know (you don't).

>>25746642 You can use a pointer without dereferencing it. You don't actually know C, do you?

>>25746635 it's useless if it's not an int type

>>25746660 Sure you can. You just won't get the "int" without using the same syntax as in the declaration. t. Has been programming C since 1988 (not a typo)

>>25746674 The type is "int*". It is first and foremost a pointer that holds unsigned 64 bit data rather than a 32 bit signed integer.

>>25746697 Actually if your pointers are 64 bit then int was always supposed to also be 64 bit. Let's thank Microsoft niggers for breaking that.

>>25746706 Let's thank C niggers for not standardizing that

>>25746707 Fair.

>>25746706 >>25746707 > what is stdint.h

>>25746706 Int is 32 bit on Linux and BSD too.

>>25746712 I thought your ball is India at first.

>>25746714 I know. I also know some history.

>>25746712 A header that introduces aliases which nobody uses? We're talking about the size of "int" here.

>>25746680 No, you will get an int*. And you need to use the * operator on an int* to get an int. So the * does pretty much the opposite, one time it turns a normal variable into a pointer, the other time it turns a pointer into a normal variable.

>>25746719 You don't know history. Long was supposed to be 64 bit but MS was too retarded to update their code, so they insisted on using long long for 64 bit integers.

>>25746726 >which nobody uses Just glue the python libraries together kind saar 😭😭

>>25746730 And the * symbol reuse is very confusing as he's shown himself. You could think it's a pointer declaration, dereferencing or a multiplication like * or *= cause.

>>25746733 > long We were talking about ints. I guess this page has some infa I won't bother re-telling. https://stackoverflow.com/questions/17489857/why-is-int-typically-32-bit-on-64-bit-compilers

>>25746726 Everybody uses it lol, unless they use things like i32. Nobody types half a novel to declare a variable with the regular names, which then still end up meaning something different on every architecture.

>>25746756 Integer just means whole number in English.

>>25746741 Read some actual C code sometimes, you'll be surprised. Having a variable-sized built-in "int" was a design mistake, it is never correct to use it, but everyone does because it is easily accessible and looks like the default option.

>>25746771 Here's a random file from OpenSSL, for example: https://github.com/openssl/openssl/blob/master/crypto/bn/bn_exp.c. Tell me how many ints you see, and how many aliases from stdint.

>>25746707 Back in the day, an extra 32 bits per int could make a big difference.

>>25746771 > Having a variable-sized built-in "int" was a design mistake I would go as far as saying that standardizing on EIGHT FUCKING BIT "bytes" as the basic addressable unit on ALL architecture was a mistake, but I learned that most people, especially younger ones, are not at all ready for this conversation.

>>25746792 So just use int16 or int32 or whatever you need explicitly, since you know the acceptable range.

>>25746794 What should it have been standardized on?

>>25746788 Using int for general purpose small integers is common and fine. Now tell me how many times it uses short, long, or long long.

>>25746804 What if on my architecture ints are 14 bits?

>>25746815 I will not, because that would be moving the goalposts

>>25746817 No such architecture. Same as the Russian argument.

>>25746817 That's the compiler's problem. It uses whatever register size fits the range you requested.

>>25746806 Why not single bits? Or 64 bit? Or 21 bit (you know why 21?)

>>25746823 > I did not use standardized types even though they were available, oh woe is me

>>25746823 Are you retarded? It doesn't make a difference if they use stdint.h or their own aliases that they define themselves that do the same thing. Which is what they do. Which you would know if you actually read the code or knew how to read code.

>>25746835 The woe is not me because I use them. But a lot of people don't, which was my point, which you still don't seem to comprehend.

>>25746835 > standardized It's C99 - THE NEW THING! It's not to be respected.

int* p is 100% more readable in simple code, and most code should be simple

>>25746830 That's the point of c it needed to be platform independent to survive you couldn't just standardize the language when on some computers memory addresses were 24 bits or 48.

>>25746842 Are you German or something? Can you please read my posts before replying?

>>25746858 Tell me in which way my post did not refute your "argument".

>>25746850 Defacto standards were established pretty soon. C consortium niggers are just retarded. They also pretend files don't exist during the compilation process but literally every C compiler in existence uses files and will continue to use them. hurr durr my translation units! Dennis Ritchie proposed arrays (fat pointers) but they never got into C.

>>25746833 Because that's not how the hardware works.

>>25746937 It worked just fine before the IBM forced everyone to use "bytes". And it will work again, bet.

these arbitrary choices left to the user indicate bad design.

>>25746992 How does anybody benefit from NOT using a standard unit? Poccnr retardation has no limits

>>25746992 MCST won't take you.

>>25747062 In several decades they will be looking at all these 32/64-bit CPUs with the same cringy smile as when you see an LPT port in the era of USB. I mean, once we move from the "chip" to "corn" designs and 1-bit "streaming" computing is a big part of that. t. Drunken time traveller

>>25747078 >>25747068

>>25747093 >>25747068 Debil. But not my problem.

>>25747078 USB was the standardization that replaced everything else, and so were 8 bit bytes.

>>25747100 > something being the best available thing for some time means that this something is the best forever Nice logic skills, but >>25747099

Imagine giving a shit about memory in 2025

>>25747120 You barely know how to turn on a computer.

>>25747124 No u

>>25746595 imagine the code smell

>>25746630 what about: int x or int x clearly the answer should be: int * x; int * * x;

>>25747302 oops spoiler is meant to be double pointers **

>>25746771 int's definition has allowed C to just work on 16-bit machines, 32-bit machines, 64-bit machines, 64-bit machines with no 32-bit operations, 64-bit machines where 32-bit operations are preferred, and many, many other kinds of machines and ABIs. Meanwhile you're too much of a jeet to write programs that run on your own computer. The first step to criticizing C is learning it, which most such people never do, as most of the ones who do start loving it.

>>25747389 Did all those programs continue working without change? The answer is: NO

>>25747389 >start loving it Doubt. It's an objectively bad language.

>>25747407 its not possible on low level

This is why everyone moved to Rust

>>25747464 0/10

>>25747407 The jeets who can't handle this can't write programs that just work on a different machine/ABI/OS/etc on other languages either.

>>25747464 In Rust you still have to deal with USIZE. It's not a problem and it's not solvable in a low level language.

>>25747559 Frankly, just make a header with i8/u8/i32 etc. Not really a problem. The real problem I have with C as a low level language (ideally it should've always been just a portable assembly) is that it lacks multiplication of iX * iX = i2X. And also an operator which is called */ in Forth (maybe also */MOD).

>>25747577 Some assemblies don't have that multiplication, it would turn into bignum code for them. That's a big no-no in C. That forth operator I never heard about until now, looks interesting.

>>25747721 >Some assemblies don't have that multiplication Name an arch.

>>25747721 >, it would turn into bignum code for them. That's a big no-no in C. Also, this is retarded wrong. For example: all those 16-bit PCs had "bignum" for 32-bit OPs, and everyone was chill. Actually, software FP is a better example.

>>25747730 Alpha returns 64-bit results for 64-bit multiplication, and needs a separate instruction to get the upper 64 bits of a 128-bit multiplication of the same operands. m68k has 16-bit multiplication with 32-bit results, and no 32-bit multiplication. That's another one, you'd be massively blowing up the complexity of multiplication in an architecture with no or limited multiplication. And in two's complement, you can use the same instruction for signed and unsigned multiplication if the result is the same width as the operands. >>25747737 True. Ritchie added long and made it 32-bit because 16 bits were too little for inodes, you can work around it with 2 16-bit integers but compilers back then were too dumb to turn that into 32-bit math and it was penalizing 32-bit computers.

GCC needs an -f-it flag that forgets languages, standards, and documentation, and just does what the programmer intended, instead of burdening poor jeets with writing programs that work.

>>25747970 >you'd be massively blowing up the complexity of multiplication Wrong. If you NEED 32-bit x 32-bit multiplication with 64-bit result on a 32-bit machine, it's still massively faster to do this, than turn both integers into 64-bit and multiply 64 x 64 = 64.

>>25748172 >If you NEED Which you probably don't. And if you reached for it to optimize around the time C was made, you'd find that it wouldn't make things any faster and would make many unrelated usecases much slower on many then-current machines. And you'd also have to deal with adding the semantics of the return value of division being some other, larger type which isn't necessarily double the size either, and which the machine doesn't necessarily have.

>>25746120 Trans thread

>>25746254 >>25746262 >>25746532 >>25746630 consider

int* x, y;

x is an int pointer y is just an int, not an int pointer there's no separate 'pointer-variety' type to accompany the basic type, 'int*' is not a type therefore the second one is 'correct' by the virtue of not being confusing now with that in mind what does

int *const *x;

stand for? hehe

>>25748784 >what does stand for? Declare x which is a pointer to a constant pointer to an int. Simple, just read it right to left, that's how you read declarations in C. Yes, that's a design flaw in C.

>>25748784 >consider Yes, that was the point of my post. Did you read it before replying to it? >'int*' is not a type It is.

I just realized the rt-sources (realtranny sources) kernel on Gentoo is maintained by the tranny who named himself after the loli idol: https://packages.gentoo.org/packages/sys-kernel/rt-sources

>>25748806 sorry, but no it is a non-const pointer to a const int :^) >>25748841 pointer, semantically, is 'above' the type i don't know how to explain it properly other than: "imagine pointer as a struct that has one field"

>>25748947 No, a pointer is a distinct type. >it is a non-const pointer to a const int Also wrong. The garlic was correct.

>>25748973 but a pointer needs to point to something that is of some type? isn't it 'opaque'? (how gcc people would've liked to call it) anyway, consider picrel as my counterargument as i retreat into rethinking my life yea, winretard, you've probably guessed it

>>25749100 >but a pointer needs to point to something that is of some type? It actually doesn't. There are void pointers too.

>>25749100 Pointer to int is a type. Pointers are types. What they point to is an object of another type. There are several kinds of types in C, pointers are among them, they're not really special. Being able to declare pointers and integer types in the same declaration is a C quirk, a bad one.

>>25749112 void is a type though

>>25749152 Pointer to void is a pointer to incomplete type that can't be completed. In a sense, you're both right.

>>25749152 void can be part of a type but by itself it is not a type. A function returning "void" does not return anything and this nothing has no type. It's just a placeholder word to make up for stupid syntax.

>>25746282 debunk this

>>25749169 It is a type as far as I learned. Its just a "dummy type" but still is a type. Maybe its just semantics I guess.

>>25749171

c
int *
func()
{
    123;
}

Just be a unix hacker. Funny thing, not returning from a value-returning function isn't an error, but trying to use the returned value is.

>>25749152 It's an incomplete type, you can't have a variable of type void. A pointer to void is pointing to something that you don't know the type of, but it's still actual data that you can access once you cast the pointer to an actual type.

>>25749112 yes but void is nothingness that is declared somewhat specifically

void something();

a method can't 'not return a thing' so it does, by returning 'nothing' >>25749146 >Being able to declare pointers and integer types in the same declaration is a C quirk, a bad one indeed it is although i'm more pissed about

if (a = b)

being a legit check what are we even checking there? successful assignment? >>25749152 but then

void x; //won't fly
void *y; //ok

>>25749226 >a method can't 'not return a thing' so it does, by returning 'nothing' You actually can return nothing, that's what a function that "returns" void does. It doesn't return an empty variable or anything, it returns nothing. But a void pointer is something different and used differently. >what are we even checking there? successful assignment? You are checking if a, after the assignment to b, has a non-zero value.

>>25746170 Pointer doesn't care with the variable, it mess with the physical location of it, which is more efficient and failproof if you are good.

>>25749238 >that's what a function that "returns" void does that was sophistry from me, a function cannot be a dead end and has to return something, therefore when logically nothing is to be returned void is used as defined undefined that is returned at the end od it >But a void pointer is something different and used differently. i was pointing out the first one wouldn't compile and therefore 'void' on its own is not really a type >You are checking if a, after the assignment to b, has a non-zero value. ok i see, but why do that if i can check the one i'm assigning?

>>25749335 >ok i see, but why do that if i can check the one i'm assigning? It's a design decision. Every expression in C returns a value, if not for that you'd have to remember which do and which don't. Where did you come from that isn't like that, Lisp?

>>25749335 >a function cannot be a dead end and has to return something It doesn't. You can just look at the assembly output:

void foo() {
    return;
}

int bar() {
    return 1;
}

compiles to

foo():
        ret
bar():
        mov     eax, 1
        ret

The second function sets a register to the value 1, thus returning a value. The first function doesn't set any registers or do anything, it just returns. >ok i see, but why do that if i can check the one i'm assigning? I think the only time you would do this in practice is when you check the return value of a function. I can't think of a real example, but something like

if (x = foo())
        printf("%d\n", x);

Also modern compilers will complain about this because most of the time such code is written by mistake, so you would actually write if ((x = foo())) to make the compiler shut up about it.

>setf returns the value of the last form Nevermind, I was under the impression it returned the old value.

>>25749377 Using the return value of assignment is common in C. You use it in any function that reserves a sentinel to signify error, many of them do: e.g. realloc():

c
#include <stdlib.h>

int
main(void)
{
	void *some_alloc = NULL;
	void *tmp = NULL;

	if ((tmp = realloc(some_alloc, 1)) == NULL) {
		exit(1);
	}

	some_alloc = tmp;

	free(some_alloc);
}

>>25749348 "a = b" is three expressions variable a, assignment, variable b they return variable a, variable a then returns its value so it was decided not to treat this case specially since it just unfolds into "if (a)"? "a = b" being legit while being a typo of "a == b" wasted my nerves one time lol

>>25749402 >"a = b" being legit while being a typo of "a == b" wasted my nerves one time lol You need to compile with -Wall and you'll get a warning for it. You should enable a bunch of warnings like -Wextra too.

itt every1 trying to be the expert where multiple answers are correct

>>25749396 I was trying to think of an example where you directly check the returned value without a comparison operator. It's been a while since I had to touch the c stdlib, but I'm sure there's something.

>>25749377 fuck, what i meant is we can't

"NOTHING" foo() {
    return;
}

we have to return and have something to return which is void when we don't return an actual value >when you check the return value of a function ok i see still most people prefer to assign separately before the condition and then checking the result there? otherwise we're saving only one line and reducing readability somewhat >>25749396 but we're talking/justifying if an assignment is the only binary expression in the condition >>25749409 well...i was unaware back then

>>25749469 >otherwise we're saving only one line and reducing readability somewhat In C++ (and maybe newer C standards, not sure) you can actually define a variable inside the if statement, which gives this another use:

if (int x = foo())
    ...

That way this variable is available inside the if statement, but not outside, and also doesn't overwrite the value of any other variable called x.

https://llvm.org/docs/Vectorizers.html There are Bernds out there who haven't read the clang auto vectorizer documentation to write more optimizable code. Also, now that AMD put out the first CPUs with AVX-512 implementations that aren't garbage, it's going to get used a lot more in the wild. It has features specifically made to make it easier to be generated by auto vectorizers like mask registers. Too bad only garchs can have such CPUs.

int* is more understandable grammatically

>>25746848 then most code should be python

>>25754543 That would make most programs unusably slow, buggy, and impossible to distribute. And it wouldn't make things any simpler.

Both wrong. It is

int * x;

int x, *y;

>>25754566 >buggy says guy with c pointers

>>25754641 That should be illegal with every style guide.

>>25754698 >style guide Shit for fags who should stick to python or some other hand-holdy language.

herd it's the better fewer lines program takes and so i will make everything oneliner

>>25754566 >not understanding what he meant grim

it's: type name; so the type is "pointer to int", indicated by "int" and "*" Therefore should be int* x; int* = type x = name

>>25758312 Nigger.

>>25754698 Go write some Rust, pidor.

>>25746282 dogshit. you write int* because that's the type. pointer to int. int*const confirms my point.

>>25758354 you're just low iq. two extremely high iq people have explained this independently: >>25758379>>25758312

>>25758387 >you're just low iq. I was tested the highest in my college at 143 back then, thank you, nigger.

>>25758312 >int* x, y, z >int* = type >x, y, z = name But we can have this thread on repeat infinitely if the retards like you and that Brigger don't care to read or to think.

>>25746282 >const BTW, according to K&R: > The purpose of const is to announce objects that may be placed in read-only memory You don't do ROM programming, infa 100%.

int *x; is the best or do you write char[] x; too

>>25758354 >>25758400 Think about it If it's int *x; then it means that the type is "int" while the name is "*x" So the meaning is that the type here is integer whose name is *x and only because the name has an * in the beginning then the type "changes" from integer to pointer to integer. It doesn't make any sense. Why would the name change the type? So obviously the * is part of the type and therefore should be written together with the type - int*. You may write int * x; if you want, just for style, but I don't like it personally.

>>25758415 Just read the fucking thread.

int is a type if int* is also a unique type then int* <whatever> if int* is not a unique type then int *<whatever> thats how it makes sense to me as a non C programmer

>>25758418 Well, I think you can write: int *a, b; Where a is pointer to int And b is int Logically speaking, it doesn't make much sense. Practically speaking, you should never write like that. Technically speaking, since this is how C works, then you're right.

>>25758440 >Logically speaking, it doesn't make much sense. It makes absolutely perfect sense.

>>25758440 >Practically speaking, you should never write like that. And of course any real C codebase has plenty of that.

Okay, here's one more: How do you "muh type" niggers would write this? > int* idxmap,* idxmap_back; ?

>>25758459 lol

>>25758440 is it possible to write int* a, b, c and all of them would be pointers ? Because if not, then prefixing asterisk to the names makes much more sense and leads to fewer mistakes

>>25758402 that's just c's retarded syntax. type is type, simple as. you can still put const on the right side of 'em

do you write int* *x; or int **x; if you want a pointer to a pointer

>>25758485 i had enough cpp and write rust exclusively.

>>25758502 how about this one :D int* a, *b, *c; :--DDDD

>>25758484 >that's just c's retarded syntax Fair point. Now we both can go back to writing Delphi and Ruby on Rails. >>25758502 Very German. >>25758508 Something about consistency, little minds, and hobgoblins, right?

>>25758442 Consider the following: int a, *b, c, *d, *e, f, g, h, i, *j, *k, l .. Easy to see why this is bad practice, even though C language tolerates it. Other programmers would have to remember which letter is an integer and which is a pointer to an integer. Also, I see no value in writing types and pointer to these types in the same line - why not using two lines? Logically spekaing, a type and a pointer to this type should be two different types. C doesn't think this way and dictates a pointer with an optional modifier * So each expression is type (modifier) name Given that, I agree that it should be int *x because C forces the modifier to go with the name

to this day there is not a single use for pointers

>>25758535 >Easy to see why this is bad practice, even though C language tolerates it. Other programmers would have to remember which letter is an integer and which is a pointer to an integer. Apart from being Jewish, do you have clinically diagnosed any other mental problems?

>>25758538 > to this day there is not a single use for po Too easy.

int* is a single type. Only the parsing of multideclarations is completely fucked up in C. The D language fixed it:

import std;
void main() {
    int* a, b, c;
    writeln(typeid(a).toString," ",typeid(b).toString," ",typeid(c).toString);
}

outputs: int* int* int*

>>25758535 you were the chosen one, shlomo! it was said that you would own cniles, not join them!

>>25758535 >Logically spekaing, a type and a pointer to this type should be two different types. They are. They are only treated like this during the parsing stage.

>>25758544 Great! What useful software written in D is there today?

>>25758552 Write some.

>>25758538 what would you use them for, you're just a toilet cleaner

Pointers are gay. Java authors were right to abandon all this shit.

>>25758554 Typical.

>>25758535 that looks retarded ofc, but why not: int a, c, f, g, h, i, l; int *b, *d, *e, *j, *k;

>>25758558 That looks better

>>25758558 It is better, of course Would have been even better if C allowed writing int* as the type and then all the following vars would have been int* But it looks like C doesn't like it

>>25758541 Are you saying that writing like that >int a, *b, c, *d, *e, f, g, h, i, *j, *k, l .. Is somehow reasonable? It fulfills no practical purpose other than confusing people who will read this code

>>25758563 true, i wonder why even have such silly symbols to drastically alter data type or variable name was there something illegal to create a int_ptr type to begin with ? so you have your int a, b, c; int_ptr x, y, z; or would this be confusing down the lane ? to read and understand whether its a variable or a pointer ? seems like just having *<name> makes much more sense because then in the code you can reason about "something" being a variable or a pointer.

>>25758572 typedef int *intptr;

>>25758572 80iq post

>>25758579 thanks Now extrapolate your onions

>>25758572 You can create complex types like

int*

.

>>25758582 -> >>25758583

>>25758578 is this a recipe for absolute disaster or actually something thats used in practice ?

>>25758546 I can't deny the facts Looks like the Russian ball is technically right You may write: int a, *b; a is int b is int* I think the logic here is faulty but that's how C works

>>25758586 right, so me not understanding some hidden meta about C is somehow low IQ, altho i've never ever spent a second working with it

>>25758587 type** are widely used.

>>25758592 if you were high iq you would've immediately considered applying operator to itself. but you are low iq balt.

>>25758598 go apply yourself to yourself bong

>>25758591 not sure, if logic is faulty. "int* is a type" is just a bullshit definition

I forgot everything ;_; Function pointers are tricky tbh Btw I agree with Israel, it's bad form to write int *x, y; Either Int* x; Int y;

>>25758606 >"int* is a type" is just a bullshit definition int* is a type, retard ChatGPT explanation: >You're absolutely correct—int* is indeed a single type that represents "pointer to an integer." However, in variable declarations, the * is part of the syntax that explicitly binds to the variable, not to the type itself. That's why the distinction matters.

Consider the following: Class A, whose size is let's say 80 bytes Now the following expression: A a, *a_p; sizeof(a) = 80 sizeof(a_p) = 8 (let's say it's a 64-bit system where size of pointer is 8 bytes So now it's even more crazy logic as the "type" of both a and a_p is A. a_p differs by having a modifier *, which is allegedly not part of the type. This is very faulty logic you got there, C !

>>25758613 it's still just a bullshit definition. I don't see the contradiction. Developers of a compiler wouldn't need to implement it like that

>>25758617 int* is a type and I don't see how a typed language would work if a variable declared int* was just a pointer to anything or genderfluid int. The parsing rules have nothing to do with this.

The developers of a compiler DO need to implement it in a way that int, int* and

int**

are separate types.

>>25758470 only correct interpretation anything else is autism

>>25758587 typedef int *intptr_t; (or something with in-betweens) is literally in standard stdint.h

>>25758578 >>25758587 >>25758780 >The following type designates a signed integer type with the property that any valid >pointer to void can be converted to this type, then converted back to pointer to void, >and the result will compare equal to the original pointer: > intptr_t intptr_t does exist and it is used, but not for what the Russian seems to be implying.

>>25758780 uintptr_t is an integer able to hold a pointer. It serves a completely different purpose

>>25758801 You were faster