struct & pionters bug

hi all,
I've a tiny bug with this code...
In first time I use 1 without my_send, but I need doing it from another function like my_send.

Code:

---

struct sockaddr_in sin; //1
//struct sockaddr_in *sin; //2
malloc(sizeof(struct sockaddr_in));
//i'll take "error: request for member 'sin_family' in something not a structure or union
", therefore I'll use 2..., but I've got segfalt
sin.sin_family = AF_INET;
//sin->sin_family = AF_INET; //2
//Segmentation fault 2
my_send(socket,buffer,&sin); //1

sent=sendto(sock, buf, buf_siz, 0, (struct sockaddr *) &sin, sizeof(sin));
if(sent < 0) {
perror("sendto");
exit(1);
}
void my_send(int s,const char *buf, const struct sockaddr *addr){
int buflen = strlen(buf);
int sent =0;
sent = sendto(s, buf, buflen, 0, (struct sockaddr *)addr,sizeof(addr));
if(sent<0){
perror("sendto");
exit(1);
}// sendto: invalid argument 1 Without my_send function it's works very well, i think what it because somewhere I did a mistake.
}

---

Wow. Just wow. I've rarely seen a post make less sense and be less coherent than this one.

I don't even know where to begin. Okay, I don't have a clue what you're asking. I have no clue on what the code is supposed to look like, or what the ones and twos and commented code is.
What is that malloc where the return value is ignored anyway? :P Maybe that's the cause of whatever problem you're having.

Please, actually explain your problem. Please indent your code. Please don't just place random snippets next to each other (or do you actually have a function body inside another function body?). Please don't add stuff that's not code (or comments) inside the code tags.

The 1s and 2s are the two different methods he has already tried... I think... That is about all I've been able to figure out.

There's a number of obvious problems, but it is kind of hard to know what to say when the OP thinks:

Code:

---

malloc(sizeof(struct sockaddr_in));

---

serves some kind of purpose beyond just throwing out some memory -- or would it be better if I ignored these details and tried to guess what "the real problem is"?

If I were the OP, I would I hope I am not off on my own, dreaming up my own version of C, and hence now unable to communicate effectively to anyone about it.

Quote:

---

Originally Posted by MK27

There's a number of obvious problems, but it is kind of hard to know what to say when the OP thinks:

Code:

---

malloc(sizeof(struct sockaddr_in));

---

serves some kind of purpose beyond just throwing out some memory -- or would it be better if I ignored these details and tried to guess what "the real problem is"?

If I were the OP, I would I hope I am not off on my own, dreaming up my own version of C, and hence now unable to communicate effectively to anyone about it.

---

What's wrong pertaining to this malloc? It's works very well with both it few different ways.
but I've got another problem. There I did post two different methods which's I tried

Code:

---

struct sockaddr_in *sin;
sin->sin_family = AF_INET;
my_send(socket,buffer,sin);
//warning: passing argument 3 of 'my_send' from incompatible pointer type
struct sockaddr_in sin;
sin.sin_family = AF_INET;
my_send(socket,buffer,&sin);

---

But I seems, what it similar of this...

Code:

---

int number;
int *tommy;
tommy = &number;

---

Quote:

---

Originally Posted by quantt

What's wrong pertaining to this malloc? It's works very well with both it few different ways.
but I've got another problem. There I did post two different methods which's I tried

Code:

---

struct sockaddr_in *sin;
sin->sin_family = AF_INET;
my_send(socket,buffer,sin);
//warning: passing argument 3 of 'my_send' from incompatible pointer type
struct sockaddr_in sin;
sin.sin_family = AF_INET;
my_send(socket,buffer,&sin);

---

But I seems, what it similar of this...

Code:

---

int number;
int *tommy;
tommy = &number;

---

---

I suppose it depends on what you mean by "works". It compiles. It runs. That doesn't mean it is correct.

Code:

---

malloc(sizeof(struct sockaddr_in)); //incorrect
some_pointer = malloc(sizeof(struct sockaddr_in)); //correct

---

And the whole point of malloc is to give you an alternative to your "tommy" example -- allowing a pointer to point to fresh, crisp, newly-allocated memory that isn't already known to the program.

Quote:

---

Originally Posted by quantt

What's wrong pertaining to this malloc?

---

It doesn't "pertain" to anything. malloc() returns a pointer to a block of allocated memory.

Code:

---

char *ptr=malloc(666)

---

You do not have the address of this memory if you go

Code:

---

malloc(sizeof(myimagination));

---

although it may often prevent an overwrite if you do this right after you declare a variable. But that would be pure luck. Plus you cannot really modify or free this memory now in anything resembling a reliable, meaningful way. Your use of malloc() is wrong wrong wrong and no one will deny this, nor will any amount of stammering on your part change that. The worst part is, you are making an even bigger mistake by proceed beyond this. You need to get the use of malloc() straight. It's important.

ok, thanks for your introducing about malloc usage. I needs your recommendation a tiny bit more with usage like this...

Code:

---

struct sockaddr_in sin;
bzero((char *)&sin, sizeof(struct sockaddr_in));

---

or
I should use like this?

Code:

---

buf = (char *) malloc(struct sockaddr_in);

---

Where I should use this 'buf' which is I took? Or space of memory which to occupy this variable to use with either times when socket would be created and stuffed?

Quote:

---

Originally Posted by quantt

ok, thanks for your introducing about malloc usage. I needs your recommendation a tiny bit more with usage like this...

Code:

---

struct sockaddr_in sin;
bzero((char *)&sin, sizeof(struct sockaddr_in));

---

or
I should use like this?

Code:

---

buf = (char *) malloc(struct sockaddr_in);

---

Where I should use this 'buf' which is I took? Or space of memory which to occupy this variable to use with either times when socket would be created and stuffed?

---

Your two pieces of code don't really do analogous things, so obviously one can't say which is the right thing to do always. Should you go to the butcher's or the greengrocer's? That depends on what you're trying to buy.

Having said that, and not having (much) context, I can say that if you only intend to have one struct running around (i.e., buf is just supposed to be one object, not an array of unknown size), then malloc is extremely unlikely to be the correct thing to use.

Quote:

---

Originally Posted by tabstop

Your two pieces of code don't really do analogous things, so obviously one can't say which is the right thing to do always. Should you go to the butcher's or the greengrocer's? That depends on what you're trying to buy.

Having said that, and not having (much) context, I can say that if you only intend to have one struct running around (i.e., buf is just supposed to be one object, not an array of unknown size), then malloc is extremely unlikely to be the correct thing to use.

---

ok, sure it's sample with butcher's and greengrocer's was quite good, but look at that pieces from man pages...
"The malloc() function allocates size bytes of memory."
"The bzero() function writes len zero bytes to the string b."
If we doing allocate size bytes of memory than it's address spice of memory would be zero, but has a capacity which we need.

Quote:

---

Originally Posted by quantt

ok, sure it's sample with butcher's and greengrocer's was quite good, but look at that pieces from man pages...
"The malloc() function allocates size bytes of memory."
"The bzero() function writes len zero bytes to the string b."
If we doing allocate size bytes of memory than it's address spice of memory would be zero, but has a capacity which we need.

---

Okay, so as you can see, malloc and bzero have nothing to do with each other and aren't related at all. malloc gives you new memory, which contains who-knows-what. bzero gives you no memory at all, but writes zeroes to a particular memory address (you must already own that particular memory address).