Inconsistent pointer notation in C

Self-explanatory:
#include

int main(){

char *p;
char *q=p;

/*
q=p;
*/

printf("%p\n",p);
printf("%p\n",q);

return 0;
}

/*
user@guest:~/Folder$ ./a.out
0x7ffca3ffa1c0
0x7ffca3ffa1c0
*/


I see that char *q=p; actually works but why did they decide it was a good idea?
It's ugly and confusing.

Attached: fcf81e9a0b7c2142302e1ef42e1a55db.jpg (500x323, 29K)

Other urls found in this thread:

c-faq.com/decl/spiral.anderson.html
web.archive.org/web/20140209224702/http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
twitter.com/AnonBabble

>actually works but why did they decide it was a good idea?
It's not.

Always compile with -Wall -Wextra, preferrably with -pedantic as well.

Thx didn't know about them.

Were you born clinically retarded or were you lobotomized later on?

>it's ugly and confusing
I have my complaints about pointers in C but what is your problem here?
What else would you have wanted to happen here?

how is that confusing? how is that inconsistent? what output did you expect?
explain, we can't guess what you think

What were you expecting, exactly?

And -std=c89

c11 is a thing, grandpa

He was expecting a compiler error, because he falsely assumed that C is a strongly typed language.

Brainlet here. What's wrong with this?
You assign just a pointer to a new pointer variable, rite?

>Brainlet here. What's wrong with this?
p is unassigned. q is assigned garbage.

Use the notation
char* p = q;

I don't see any type violation there

Sure, I'll explain.
If p,q are pointers then it makes sense to write p=q;.
*p=q; on the other hand would be wrong because p is not pointing to any object yet and q is a pointer.
But char *p=q; is correct.
You see how in one instance *p=q is nonsense, as it should be, and in another *p=q isn't.

>use this wrong notation
get out

o-o-o-okay then i understood this. Maybe OP is the brainlet then

now answer this

funny way to spell c99

For what reason?
It makes
char* p, q;
even more confusing.
Only the fist is a pointer.

Is

int a;
int b=a;

Also a problem?
OK I see.
Well what you've got there is the same symbol having different meanings. It's not unusual.

You're declaring q as a pointer to a char and assigning it the value of p, which is a pointer to a char. I don't see the issue here. You can use char* instead if that satisfies your autism.

Don't declare two variables on the same line then. Or C could just stop being a shit language, but we know that won't happen.

read the Spiral rule on C FAQ for reading C types
also C types are written as you access it, there is kind of a duality in it

char *p
could mean `p` is pointer to char
but also char value accessed through pointer

int *(*transform)(int)
could mean `transform` is a pointer to a function passing an int returning int
but it could also read as int accessed through calling a function passing an int

just don't get confused, there are bazillion of people complaining on C pointer syntax and that Pascal did it better, but it just werks for 40 years

>You can use char* instead if that satisfies your autism.
OP again.
I get what you mean now.
I'll probably do it in this case.

>Is .... Also a problem?
Yes, see

Noted.
Thx for the explanation.

So you'd want this to be an error instead of a widely available warning?
Why? It's potentially the case that the code is valid still.
The problem is when you perform operations on or produce side effects with undefined values.

the spiral rule page: c-faq.com/decl/spiral.anderson.html
an alternative explanation web.archive.org/web/20140209224702/http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

Forget those pointers.

Have a cup of this.

Attached: java.png (1200x2195, 116K)

Actually, I'd prefer that variables were default constructed.

>Java -- the pointer free language
>NullPointerExceptions everywhere

Java ain't pointer free but the explicite pointers are hidden from the programmer.

It's a boomer meme, Java was actually marketed as "the pointer free" language back in the days.