Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site smu.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!inuxc!pur-ee!uiucdcs!smu!pedz
From: pedz@smu.UUCP
Newsgroups: net.lang.c
Subject: Varargs in C - (nf)
Message-ID: <13800005@smu.UUCP>
Date: Fri, 24-Aug-84 15:07:00 EDT
Article-I.D.: smu.13800005
Posted: Fri Aug 24 15:07:00 1984
Date-Received: Wed, 29-Aug-84 05:22:47 EDT
Lines: 96
Nf-ID: #N:smu:13800005:000:4044
Nf-From: smu!pedz    Aug 24 14:07:00 1984

#N:smu:13800005:000:4044
smu!pedz    Aug 24 14:07:00 1984

I had an idea for the variable arguments problem.  I hesitate
writing about my idea in this news group because I am not
advocating it as an addition to C.  I am one of those people who
believe that if it aint broke, don't fix it.  C ain't broke (to
me).  In any case, I have not really finallized my ideas so if
they seems sketchy, it is because they are.

The basis of the concept lies with a special data structure
which I will call "stack_frame".  Closely associated with the
"stack_frame" data structure is a "stack_frame_ptr" which is a
pointer to a stack_frame.  Toss in one more item which would be
included as part of stdio.h which is a function (or macro) which
I will call "get_arg".  Now here is how you use it.

First, let me say that the stack_frame will be a primitive type
much like int, or char.  Thus it could be put into a structure
BUT it would either be considered very bad practice or be
defined not to work.  The reason of couse is because a
stack_frame is not of fixed sized, thus it would cause heaps of
problems.  The reason that I have given a name at all is mostly
for describing the concept.

Instead, a stack_frame_ptr would and could be used as a type of
variable or field in a structure.  Care must of course be taken
to be sure that the stack_frame that the stack_frame_ptr points
to does not go away.  Thus the stack_frame_ptr would be used
mostly as arguments to functions called from within the function
which has the stack_frame that the stack_frame_ptr is pointing
to.

The function call which uses this technique would not do anything
special.  Thus all of the C programs written would not have to
be changed (because almost all of them use printf).  The
declaration of the function which is called with variable
arguments would be something like

foo(s)
stack_frame	s;
{
	stack_frame_ptr	temp = &s;
...
}

Obviously the stack_frame_ptr could be written as
stack_frame *temp
if you would prefer.  

At the time of the call, the address of s would be given the
address of the first argument of the function call.  Thus the &s
above would not be a specail case.  This will probably cause the
compiler to stack the arguments in reverse, but most compilers
do that at the present time anyway.

To access the arguments a person would do something such as
	int		i = next(temp, int);
	char	*s = next(temp, char *);
	...

where the first argument is a stack_frame_ptr and the second
argument is the same as that for a type case or a sizeof
arguement.  The next function/macro could probably be
implemented with a reasonable straight forward use of type casts
and incrementing the pointer by the sizeof the second argument.
There may be a need for a special operator for the pointer to
deal with alignment problems.

This is fundamentally the same as the varargs used in 4.2 but is
slightly different in that a pointer to the current stack frame
can be passed to another function.  The reason I feel that this
is important is because of the printf/_doprint type use where
printf stacks a few more arguements and then calls _doprint
because it knows how the stack frame looks and is assured that
will work (on 4.2).  But in general it would be much better to
call _doprint with a few arguements, one of which is a pointer
to the stack from of printf.  This could be done with confidence
of portability.

Note that there are two items which I have not included in this
specification.  One is a simple method of getting the number of
arguements passed.  The other item is a method of determining
the types of the arguements passed.  I feel that both of these
are bad since they force the information to be passed around all
of the time.  The method described is a more primitive,
fundamental method which could be argmented by the programmer to
support either or both of the features above.

Well, those are my thoughts.  You my have noticed that I slipped
into the mode of describing this as if is was to be added to C
but that was mostly for clearity and brevity.  Let me know what
you think.

Perry
convex!smu!pedz