Which is better

This is also the very reason why bullshits like Android exists.

It depends you autist. Raw CPU speed isn't going to be your bottleneck on most any web application for instance (and whether web apps are cancer or not is another topic).

Also if he just "avoids pointers" and has "underlings" code for him, he could just prototype in something like Python.

C is fucktarded and made the second one the default convention because their developers were so obsessed with compactness they disregarded semantic correctness and common sense. Basically
// pointer to int and intint* a, b;

One would expect the first token of a variable declaration to be the type, which defines behaviour, semantics and size in memory, and the next comma separated ones as the identifiers, which gives them aliases. However, the asterisk behaves differently, since it modifies the type but is actually some optional token that can be placed, whitespace or not, before an alias. This isn't included in the alias, but is part of the identifier declaration, as shown above, and yet it modifies the type. I assume they did this to save a line so you can declare T and T* in the same line, which is really stupid but no C fanboy is gonna admit that.

I think it's more clear to put the star next to variable when you're dereferencing it. But when declaring pointer, I give the star his own safe space, because he's saying "Hey, look at me. I'm a pointer! LOOK AT ME YOU SHITLORD!##$"
int * foo;
*foo = NULL;

As others have pointed out, the second one is better because:
/* foo is pointer to int, bar is int */int *foo, bar;
But there is another reason. A declaration like
int *foo;
should not be read as "foo is a pointer to int", but rather as "the value pointed at by foo is an int". Since when dereferencing pointers you put the star right before the name it makes sense to use the same convention during declaration.
int *foo;*foo = 2;int bar = *foo;

The latter, if only because of what pointed out. I would have preferred the former if pointers in variable declarations worked in a sane way (because it should logically group with the type, not the variable name).

I disagree with your logic there. * in a type signature isn't the same as * as a dereferencing operator. One declares the type as a pointer, the other dereferences a pointer. Remember that you aren't declaring the value that foo points to, but foo itself as a pointer.

It wasn't a conscious decision for C, it came from C's history as a higher-level assembly language that stuck around as C became an actual high-level language, similar to C's weird handling of enum names. Not all the bad decisions stuck (such as struct behavior in the original C, which allowed a struct's members to be accessed on any type that could see the struct), but some bad decisions did.

Very few C fanboys defend everything about C. Most people, even those that hold that it's the best language available, acknowledge that it has flaws that are only kept for compatibility with existing code.

rust style is best style:
let foo = 0 as *const i32;

I have never used rust before, but what's the purpose of i32? To indicate that the pointer is a constant integer with the size of 32 bits? What will happen if I compile that for 64-bit machine? Or on a 8-bit microcontroller?

A 64-bit machine is called 64-bit because it can use memory addresses of 64 bits, and therefore address 2^64 bytes of memory. An int in C is typically 32 bits on both (32-bit) x86 and on x86_64, giving it a −2,147,483,648 to −2,147,483,647 range. C ints are 32 bits on just about any modern processor, but the C standard only requires them to be a minimum of 16 bits, so any C code that assumes ints can have values larger than 32767 is technically not portable.

Rust's i32 type is a 32-bit integer. The size of the pointer to that integer is irrelevant for that.

it is equivalent to const int32_t* foo = 0;

i32 is just 32bit integer, m8. Another reason Rust is shit apparently; s32 is better because it explicitly says it's signed.

having signed is bloat, anyway.

I know, but that was the logic behind using * as the sign for "pointer to" in declarations. Don't blame me, I didn't invent the retarded syntax, I'm just pointing out the retarded reasoning that lead to it.

but s32 doesnt explicitly say signed.

I never liked the way C did it. Being a pointer is a modifier of the type. In D, x and y are both int pointers:

int* x, y;

Supposedly the C behavior was done to save keystrokes back in the days when computers were slow enough for that to matter.

Assume a type is signed until told otherwise.

u32 is the unsigned 32 bit int.

This is the proper way to do it:
Foo : access Integer;

I started learning C recently and this enlightened me on this issue.

Thanks for the clarification. I was reading example as: "let foo be a variable with a value of zero and refer to that variable as a 32 bit pointer which is constant". Which of course seemed wired to me since why would you need or even be required to specify a size of a pointer. What is the rationale behind declaring pointers in this way? Is i32 *foo = 0; reserved for other use? That "as" in the statement is weird, "be" would make more sense here, for examplelet foo = 0 be const i32 *; Rust seems very confusing to me as someone who used C before.

Rusts syntax is batshit insane, as expected from retarded SJWs

Uh...doesn't that dereference a random pointer value? The second line should just be foo = NULL; with no asterisk.

you can also write it like this:
let foo: *const i32 = &0;

not an objective argument

I've never had to declare my shit in one line ever so I use the first way. I also prefix all pointers with p_ and references with r_.

int a;int* p_a;int& r_a = a;

kill yourself

Neither, ofc.
Bar* foo{nullptr};

>not recognizing ancient C shitcode for what it is.

int * foo = NULL;

Hungarian notation is shit. You should use proper tooling to get the type of a variable, not pre- or suffixes which may or may not be correct.

This. Types may change over time.

user, I...

...

Thursday.