www.digitalmars.com         C & C++   DMDScript  

D - Passing Variables

reply "Rich C" <no spam.com> writes:
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.
Jul 25 2003
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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.

Jul 25 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
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
Jul 25 2003
parent reply "Rich C" <no spam.com> writes:
"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.
Jul 25 2003
next sibling parent Ilya Minkov <midiclub 8ung.at> writes:
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.
Jul 25 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.

Jul 25 2003
prev sibling next sibling parent "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 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
Jul 26 2003
prev sibling parent "Samuel Barber" <opendtv yahoo.com> writes:
"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
Jul 28 2003
prev sibling parent Dario <Dario_member pathlink.com> writes:
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
Jul 27 2003