the root of all my problems

[MK27]

I had thought that if I have a function that returns a pointer and the compiler will not allow
this:

datatype thing;
&thing=function();

that I could do this:

datatype thing, *ptr=&thing;
ptr=function();

so that the return value gets written into thing. I'm now thinking this might not be true because, in fact, *ptr is simply reassigned to a different address by function()...

I guess I could test this somehow, but I thot I'd just ask

[matsp]

So, the correct thing to do here is something like this:

datatype *ptr;
datatype thing;
ptr = somefunc();
if (ptr)
   memcpy(thing, ptr, sizeof(thing));

--
Mats

[Elysia]

I'm now thinking this might not be true because, in fact, *ptr is simply reassigned to a different address by function()...

I guess I could test this somehow, but I thot I'd just ask

You are correct.
Though, you actually do this with references in C++:

datatype thing;
datatype& ref = thing;
ref = function();

[MK27]

shucks...i thot i knew everything already

[matsp]

You are correct.
Though, you actually do this with references in C++:

datatype thing;
datatype& ref = thing;
ref = function();

But that still doesn't work for functions that return a pointer to something. If you are SURE that it's not going to return NULL, you could of course do:

ref = *function();

Edit: That works for structs and simple types, even in C - don't need a reference in this case - it's just a different way of doing memcpy() I described above.

--
Mats

[Elysia]

But that still doesn't work for functions that return a pointer to something. If you are SURE that it's not going to return NULL, you could of course do:

ref = *function();

Edit: That works for structs and simple types, even in C - don't need a reference in this case - it's just a different way of doing memcpy() I described above.

--
Mats

Mm, maybe. Can't be 100% sure what the function returns.
The only difference is that data won't have to be written twice.

[matsp]

Mm, maybe. Can't be 100% sure what the function returns.
The only difference is that data won't have to be written twice.

Huh? the code I posted really is the same as the memcpy() option - and the reference option - it's just how many variables you need and if you need to check the returned pointer or not. Once the compiler has had a go at it (with optimisation enabled), it will end up the same.

--
Mats

[Elysia]

Huh? the code I posted really is the same as the memcpy() option - and the reference option - it's just how many variables you need and if you need to check the returned pointer or not. Once the compiler has had a go at it (with optimisation enabled), it will end up the same.

Yeah, I was referring to the original memcpy. Dereferencing a pointer like that does not make two copies...

And I don't always trust the compiler optimizations when it comes to calling functions like memcpy.

[matsp]

Yeah, I was referring to the original memcpy. Dereferencing a pointer like that does not make two copies...

And I don't always trust the compiler optimizations when it comes to calling functions like memcpy.

Well, of course, if you don't NEED to use memcpy() because it's a struct or simple type, then you can do:

ptr = somefunc();
if (ptr)
   thing = *ptr;

The memcpy variant is more generic, but if the object is such that it can simply be copied, then that's fine.

--
Mats

[Elysia]

Yes, that would probably be optimized by the compiler.

[MK27]

hmm.

So I was doing this, which I guess is basically the same as the "memcpy" option:

struct in_addr address, *ptr;
ptr=(struct in_addr*)(info->h_addr);
address.s_addr=ptr->s_addr;

It works, but if I try dereferencing to save code:

struct in_addr address;
address=*(struct in_addr)(info->h_addr);

It passes the compiler but "address" is wrong.

Of course this is not really a function call.

[Elysia]

What are you trying to do?
Just because you are assigning s_addr on both sides does not mean it will work if you omit them. Those fancy names are nothing but offsets to the compiler. Be very careful.

[matsp]

hmm.

So I was doing this, which I guess is basically the same as the "memcpy" option:

struct in_addr address, *ptr;
ptr=(struct in_addr*)(info->h_addr);
address.s_addr=ptr->s_addr;

It works, but if I try dereferencing to save code:

struct in_addr address;
address=*(struct in_addr)(info->h_addr);

It passes the compiler but "address" is wrong.

Of course this is not really a function call.

First option is casting one pointer type to another. The second is trying to cast a type to another type, and that's only allowed for simple data types (including pointers), but not for example structs.

You are basically saying:

struct A
{
... 
};

struct B
{
...
};

struct A thinga;
struct B thingb;
...
thinga = (struct A) thingb;

And even if you have EXACTLY the same content on both sides, it's different types.

[MK27]

What are you trying to do?
Just because you are assigning s_addr on both sides does not mean it will work if you omit them.

1) Well, technically I'm trying to get the information returned by gethostbyname() (which is what you would use with a string like www.internet.com) into a permanent in_addr, which is the "network order" (=bigendian) unint32 used by a lot of C socket/inet functions, or rather a struct containing such, which makes me wonder why it is a struct at all, since it doesn't have any other members besides the unint32_t.

2) I think if you read your next sentence from the perspective of a person who is not you, you will be wondering what was meant.

Thanks for the help tho. I seem to have "imagegrabber" working nicely...for now