Re: [gtk-list] Re: Apprarently simple signal/event question

[RNG <r gasch chello nl>]

Hi, 

I realize I'm a bit late following up on this, but allow me to 
dig a bit deeper on this subject: It makes perfect sense that 
the return value/pointer of a function is stored somewhere 
in memory, but what about calls like: 

	strcpy (pos, string);
or
	memcpy (new_mem, mem, byte_size);

The reason I ask is that I've been writing code like this for 
years (and most programs I've seen do the same thing) while 
these functions do return a pointer (which is (in these cases) 
equivalent to the 1st argument). 

In a later reply, Havok said 

> Still, it seems like a Bad Idea (tm) to rely on this. ;-)

which raises the following 3 questions: 

1) is this really dangerous?
2) if so, why does glib use calls like the above
3) am I misunderstanding something here?

Thanks
--> R



On Mon, 13 Dec 1999, Havoc Pennington wrote:
> "Peter  Garner" <peter.garner@toward.com> writes: 
> > 
> > Really?  Thanks for the heads up!!!
> 
> The return value has to be stored in memory somewhere; if the compiler
> thinks there is no return value when invoking the function pointer it
> doesn't have to make that memory. But if the function being invoked
> has a return value it will put the return value there anyway.
> 
> >  Upon what machine type 
> > do you usually program?  I mostly use intel, and although it 
> > is a terrible coding practice, just for warning purposes on
> > WHICH machine type returning a value where none is expected 
> > would cause any problems?  
> > 
> 
> No clue, I would expect it to cause problems on any machine.