Hello,

I would like to know if D has fundamentally changed the mechanism of passing variables to functions, namely, is it still done on the stack?

Thanks,

Rich C.

Yes, but with a caveat.

You cannot store (or pass) classes by value; they must be passed by reference.  All other arguments are passed by value.  (Obviously, a pointer argument is passed by the value of the pointer...

So, to create a class instance, you do it like this:

	class foo{...};
	foo myVar = new foo;

and when you call a function with a class argument, you pass the reference:

	doThing(myVar);

However, when you use a struct, you can use the literal value:

	struct bar {...};
	bar myVar2;	// this is a literal struct, NOT a reference

	doThing2(myVar2);	// this passes a copy of the struct
				// on the stack
	doThing3(&myVar2);	// this passes a pointer to the struct

Hope this helps!
	Russ

Rich C wrote:
> Hello,
> 
> I would like to know if D has fundamentally changed the mechanism of passing
> variables to functions, namely, is it still done on the stack?
> 
> Thanks,
> 
> Rich C.

Rich C wrote:
> I would like to know if D has fundamentally changed the mechanism of passing variables to functions, namely, is it still done on the stack?

No, D hasn't changed this mechanism.
Yes, it is still done on the stack.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3F218F62.DBFFA50D@chello.at...

> No, D hasn't changed this mechanism.
> Yes, it is still done on the stack.
>

Too bad. I am looking for a language which does not do this (other than assembler of course.) Hopefully someday people will realize that is is the major reason that C and C-derived programs are so susceptible to exploits.

Rich C.

Rich C wrote:
> Too bad. I am looking for a language which does not do this (other than
> assembler of course.) Hopefully someday people will realize that is is the
> major reason that C and C-derived programs are so susceptible to exploits.

Nope, the major reason C programs can't resist exploits are variable number of arguments and the misuse of varargs functions like printf!!!

This is both on the list to be dealt with in D.

Besides, D makes handling heap-allocated objects easy, so that if you wish, all your valuable information will not be on a stack. Using stack is much less typical in D, since only structs and wierd extention classes are stack-allocated. Giving up stack for good would yould a very bad performance penalty, which we don't want.

-i.

Put all your data on the heap, and some a$$hole will figure out a way to printf over the vtable pointer and create an exploit.  Might take him an extra hour though.

Sean

"Rich C" <no@spam.com> wrote in message news:bfs744$10uj$1@digitaldaemon.com...
>
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3F218F62.DBFFA50D@chello.at...
>
> > No, D hasn't changed this mechanism.
> > Yes, it is still done on the stack.
> >
>
> Too bad. I am looking for a language which does not do this (other than assembler of course.) Hopefully someday people will realize that is is the major reason that C and C-derived programs are so susceptible to exploits.
>
> Rich C.

> Too bad. I am looking for a language which does not do this (other than assembler of course.) Hopefully someday people will realize that is is the major reason that C and C-derived programs are so susceptible to exploits.

Stack passing is not the problem; the problem is functions like printf that can be abused to manipulate the stack.

Besides, IMHO the major reason that C programs are so suspectible to exploits is C-style strings and related buffer overruns. Which is solved in D.

-fg

>Hello,
>
>I would like to know if D has fundamentally changed the mechanism of passing variables to functions, namely, is it still done on the stack?
>
>Thanks,
>
>Rich C.

It isn't always the case: if the function is extern(D) and the arguments it is
passed can be stored in registers, that's where they will be passed.
If you're running Windows try to use obj2asm to see how they're are passed.
-Dario

"Rich C" <no@spam.com> wrote in message news:bfs744$10uj$1@digitaldaemon.com...
> Too bad. I am looking for a language which does not do this (other than assembler of course.) Hopefully someday people will realize that is is the major reason that C and C-derived programs are so susceptible to exploits.

Are you alluding to the overwrite-the-return-address trick? There's no requirement in 'C' to store return addresses and local arrays in the same place.

Sam