int* ptr_a, ptr_b;
Also just found out the author was the developer of Adium [1], which is one of my favorite softwares (best logo) on macOS.
"int *p"
"int* p"
Edit: corrected code quotation.
No, void pointer arithmetic is not allowed by the C standard: https://stackoverflow.com/questions/3523145/pointer-arithmet...
OTOH, GCC documentation says "sizeof is also allowed on void and on function types, and returns 1".
First "foo_ptr's type is int * ", but then "The pointer has a type, too, by the way. Its type is int.".
I also refuse to agree with "An int * * 's type is int * ". :)
But I guess "the type of `* ptr` is int, the type of `ptr` is int * " would be even more confusing.
A demonstration of a declaration statement where the asterisk operator binds to an identifier rather than to a type:
int my_int, *my_ptr, my_other_int;
extern void my_function(int*, char*);
Interestingly the D programming language mostly keeps C's syntax, but handles multiple declarations differently. https://dlang.org/spec/declaration.html#declaration_syntax
1[array] == array[1]
Now add in some poorly named variables for some real fun
https://github.com/Droogans/unmaintainable-code#cs-eccentric...
This is an amazingly wrong statement. In assembly you deal with memory addresses. Pointers in C are a much higher level abstraction.
> On current mainstream Intel processors, it occupies four bytes of memory (because an int is four bytes wide).
This depends on the compiler as well as the processor.
C11 6.5.3.2p3 “The unary & operator yields the address of its operand. If the operand has type ‘type’, the result has type ‘pointer to type’.”
I understand the intention to warn about the abstraction C introduces, but you’ve confused things.
Pointers and addresses are perfectly covered.
What you really want to bring is what the Standard calls the “C abstract machine”, for which the memory model can be surprising.
Not really; almost all programmers treat them as addresses and almost all compilers represent them that way. Regardless of what the standard actually says. Leading to surprises when this doesn't hold true, and awkwardnesses of the 16-bit x86 "near/far" pointers.
I mean, that's the only reason that "array[index]" and "index[array]" are interchangeable; you don't see that in other languages.
Yes. On x64 compilers targeting 64bit cpus, the following prints 8 instead of 4:
#include <iostream>
int main () {
std::cout << sizeof(int*) << std::endl;
} #include <stdio.h>
int main(void)
{
printf("%zu\n", sizeof (int *));
return 0;
}An 'int' is usually 4 bytes wide when compiling for 64-bit ISAs (at least I haven't seen situations yet where this isn't the case, my experience is limited to x86 and ARM though). Modern C fixes this ambiguity with sized integer types (e.g. int32_t vs int64_t).