Is it even possible to assign to pointers in C?

Is it even possible to assign to pointers in C?
void myfun(struct s *p){
struct s *a = malloc(sizeof *a);
p = a; //p doesnt change
*p = *a; //crash
p = *(&a); //p doesnt change
}

Attached: tenor.png (444x640, 290K)

that should be p = &(*a); but apart from that

*p = *a

isn't that a noop at that point?

This should do nothing useful, but not crash either.

so you cant do it?
you can't give a function a pointer, then reassign what that pointer points to?

double pointers

Arguments are pass by value, so when you pass a pointer to a function, you're just passing the memory address p pointed to, not a copy of p to manipulate. You'd need a pointer to a pointer to do that.

How does the compiler know what a is when you call sizeof *a?

You can. What exactly do you want to accomplish? It's a bit vague.

I was following along some guide on binary trees and, which was done in C++ or C# or whatever, but not C. And there it checks if the root is null, in which case it reassigns it to point to a new tree.

How about you try to understand scopes first.

this

Attached: pepe_based8.jpg (368x346, 73K)

#include
#include

struct s {
int data;
};

void myfun(struct s **p)
{
struct s *a = malloc(sizeof(struct s));
a->data = 123;
*p = a;
}

int main(void)
{
struct s *p;
myfun(&p);
printf("%d\n", p->data);
}
$ cc test.c
$ ./a.out
123

ok kid

I'm guessing when defining variable in a function, they're always put at the top. So there is a place in memory that malloc can reference, even though the value hasn't been set.

Ok here's my insertion function
void insert_it( b_tree *root, unsigned int key){
b_tree *bt = new_tree(key);
if (root == NULL){
return;
}
b_tree *leaf = root;
traverse:
if (keykey){
if(leaf->left){
leaf = leaf->left;
}else{
leaf->left = bt;
leaf->left->parent = leaf;
return;
}
}else{
if (leaf->right){
leaf = leaf->right;
}else{
leaf->right = bt;
leaf->right->parent = leaf;
return;
}
}
goto traverse;
}

I kept parent because I couldn't figure out how to delete the tree without it easily so
void destroy_it(b_tree *root){
b_tree *leaf = root;
traverse:
if (leaf->left){
leaf = leaf->left;
}else if (leaf->right){
leaf = leaf->right;
}else{
if(!leaf->parent){
printf("\nfreed %d, root", leaf->key);
free(leaf);
return;
}else if(leaf->parent->left == leaf){
printf("\nfreed %d, left child of %d", leaf->key, leaf->parent->key);
leaf->parent->left = NULL;
b_tree *parent = leaf->parent;
free(leaf);
leaf = parent;
}else if(leaf->parent->right == leaf){
printf("\nfreed %d, right child of %d", leaf->key, leaf->parent->key);
leaf->parent->right = NULL;
b_tree *parent = leaf->parent;
free(leaf);
leaf = parent;
}
}
goto traverse;
}

Who the fuck told you to use malloc(sizeof(*a)) instead of malloc(sizeof(struct s))

some guy on g who said its easier in case you replaced the name of the struct or whatever else

wait what
why doesn't p change in the first assignment statement?

No, sizeof(*p) will always net you sideof(void*) or whatever other pointer. You get the size of the pointer itself, not the pointed to element.

when you return from the function the pointer you gave it is unchanged because C passes pointers by value. By reference does not exist in C at all.

That guy doesn't understand shit
You have to allocate the size of the struct in the heap and then malloc returns a pointer to that memory which you can use
Allocating the size of a pointer that you are creating is useless
Unless you have something like type **name you don't have to think about sizeof(*pointer)

It does change, but only the local copy of p within the scope of the function changes. OP is expecting it to change in the scope where it was passed to the function.

are you two retarded? do you really think it just returns memory equal to that of a single pointer? why are you even posting in this thread if you don't know C, embarassing.

Attached: laughs1.jpg (238x212, 12K)

Are you dumb?

#include
int main (void)
{
int a, *b;
long c, *d;
printf("%d, %d, %d, %d\n", sizeof a, sizeof *b, sizeof c, sizeof *d);
printf("For good measure: %d, %d\n", sizeof b, sizeof d);
}

$ ./a.out
4, 4, 8, 8
For good measure: 8, 8

you look like a smart guy
should I be using stacks and queues to delete and print the binary tree iteratively?
or is it fine to have the parent stored in the node

There are many many books and tutorials that cover this stuff. I'm assuming you're in some CS class, so I would recommend to read your textbook or find examples online. I'll give you a hint and say binary trees play very nicely with recursion, which is sort of what you're emulating there with goto (please don't use goto. There are situations for it, but it usually results in spaghetti code when used by bad programmers).

you proved him right. You played yourself

Kek, you don't need to do this to make a BTree. Just pass in the pointer and assign it a new tree node. You don't want to dereference like you are doing unless you want the value at the pointer. Also, instead of doing sizeof(*a) just use the size of the type if you use malloc. Though I would just use the new keyword, though, I don't remember if that exists in c.

I dont want to use recursion because i head it blows up the stack, but also it looks a lot easier than iterative approaches.

If he was right, sizeof *b would equal 8.

Not him, but
>There are situations for it
Name one

nothing wrong with goto and labels inside a function idiot, there's a reason that's allowed in C by default.

yes, by passing by reference. by default c passed by value, so it passes the value of the pointer by creating a second and equal pointer for use within the function scope. if you want to modify a passed argument you have to pass it by reference.
void myfun(struct s **p) // two stars
will create a new variable with the address of a pointer as its value.
struct s *p;
myfun(&p);
will pass the address of the pointer p to the function where it can then be modified.

this is the source of many bugs and generally frowned upon so try not to pass anything by reference if you can help it. working through return values makes programs that are much easier to follow and debug than working through side effects.

Oh, I misunderstood the first guy. The second guy is right though.

using goto-linked switch statement when writing a lexer vs nested switches.

I'm learning c++, and just got into pointers. I don't know why, but they're my favorite feature so far.

>c++
get out of this thread m8, dont ned the bloat

This is literally spaghetti code. If you want to clean this up either use a buffer and de-nest your switch, or if this isn't feasible, use functions to encapsulate the inner switch. Don't litter gotos everywhere.

Yeah, shitty legacy code. Never do it. It creates a mess and allows for arbitrary control flow, which significantly hurts readability.

retard dogma mouth breather

Void myfun(struct s *p){
struct s *a = malloc(sizeof p);
p = a //=NULL
*p = *a; //a does not point on a value

Lol, someone is butthurt

spaghetti code is just unstructured code. a linked series of switches is functionally similar to a tree of function pointers with less overhead. using functions creates a lot of stack operations with too little in between setup and tear-down to justify functions and i'm not sure what you mean by using a buffer to de-nest switches in a lexer. lexers are usually just state machines with a large number of states, and the cleanest way to change state is with a jump.

At the point where performance at the function pointer level is a concern, you should probably be using asm?.

>hurrdurr this code bad my code good

breaking out of nested loops, error cleanup