what does the standard say about parameter passing?

T

Tobias Oed

John said:
Hi, I don't have a copy of the standard, and I'm curious if the
mechanism to pass parameters to functions is defined by the standard or
left to the implementation. Specifically the points that I would like to
know if they are imposed by the standard are the following:

- using the stack to pass parameters
- parameters being adjacent in memory
- pushing them in reverse order before jumping to the function (so that
they can be accessed in increasing addresses by the function) (assuming
that passing through the stack is required)

The implementation is allowed to do it as it sees fit as long as it works as
specified in the standard. As a side note, a stack isn't required by the
standard.
P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

google for n869
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
enjoy the read :^)
Tobias
 
J

John Tsiombikas (Nuclear / the Lab)

Hi, I don't have a copy of the standard, and I'm curious if the
mechanism to pass parameters to functions is defined by the standard or
left to the implementation. Specifically the points that I would like to
know if they are imposed by the standard are the following:

- using the stack to pass parameters
- parameters being adjacent in memory
- pushing them in reverse order before jumping to the function (so that
they can be accessed in increasing addresses by the function) (assuming
that passing through the stack is required)


P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

-- Nuclear / the Lab --
 
E

Eric Sosman

John Tsiombikas (Nuclear / the Lab) said:
Hi, I don't have a copy of the standard, and I'm curious if the
mechanism to pass parameters to functions is defined by the standard or
left to the implementation. [...]

The mechanisms by which arguments are passed to functions
and function values returned to the caller -- even the means
by which the function knows where to return -- are entirely
up to the implementation. The Standard describes the behavior,
not the mechanics.
P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

Google for "N869".
 
G

Gordon Burditt

Hi, I don't have a copy of the standard, and I'm curious if the
mechanism to pass parameters to functions is defined by the standard or
left to the implementation. Specifically the points that I would like to
know if they are imposed by the standard are the following:

- using the stack to pass parameters

*THE* stack? Which stack? Some systems don't have one, and some
systems have more than one. If you assume that an implementation
has *THE* stack, you risk kicking yourself in *THE* ear with *THE*
foot. No, ANSI C doesn't guarantee anything about *THE* stack.
- parameters being adjacent in memory

No guarantee. In certain versions of certain compilers, global
variables seem to be sorted alphabetically by variable name, but
you can't count on that.
- pushing them in reverse order before jumping to the function (so that
they can be accessed in increasing addresses by the function) (assuming
that passing through the stack is required)

No guarantee. This is likely to be tied to architecture issues where
on some systems the stack (if there is one) grows UP in memory and in some
it grows DOWN.

Gordon L. Burditt
 
B

bd

Hi, I don't have a copy of the standard, and I'm curious if the
mechanism to pass parameters to functions is defined by the standard or
left to the implementation. Specifically the points that I would like to
know if they are imposed by the standard are the following:

- using the stack to pass parameters
- parameters being adjacent in memory
- pushing them in reverse order before jumping to the function (so that
they can be accessed in increasing addresses by the function) (assuming
that passing through the stack is required)

The standard does not specify *how* an implementation should pass
parameters, only the effect. Any of those could produce a conforming
implementation (as well as many others).
P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

A search engine is usually used in these situations.
 
J

John Tsiombikas (Nuclear / the Lab)

- using the stack to pass parameters
*THE* stack? Which stack? Some systems don't have one, and some
systems have more than one. If you assume that an implementation
has *THE* stack, you risk kicking yourself in *THE* ear with *THE*
foot. No, ANSI C doesn't guarantee anything about *THE* stack.

Well I guess *A* stack can be implemented somewhere in *THE* memory by
the compiler in case it was required, even if the computer doesn't have
a special stack pointer register. And all computers have *THE* memory as
far as I know.
No guarantee. This is likely to be tied to architecture issues where
on some systems the stack (if there is one) grows UP in memory and in some
it grows DOWN.

that's true

-- Nuclear / the Lab --
 
B

bd

Well I guess *A* stack can be implemented somewhere in *THE* memory by
the compiler in case it was required, even if the computer doesn't have
a special stack pointer register. And all computers have *THE* memory as
far as I know.

As far as ANSI C is concerned, the compiler could write the arguments to
disk, then read it back in the function. There would be no point, but it's
legal.
 
D

Dan Pop

In said:
As far as ANSI C is concerned, the compiler could write the arguments to
disk, then read it back in the function. There would be no point, but it's
legal.

And as far as the real world implementations are concerned, if the
processor has enough registers, they're used for argument passing.

So, people who rely on the typical x86 implementations behaviour are
likely to have a surprise when moving their code elsewhere: an argument
type mismatch and the processor may search the argument in the wrong CPU
register.

Dan
 
C

CBFalconer

bd said:
.... snip ...

As far as ANSI C is concerned, the compiler could write the
arguments to disk, then read it back in the function. There
would be no point, but it's legal.

This system uses punch cards. Blue for bytes, fuchia for floats,
dark green for doubles, puce for pointers, indigo for ints. long
ints use two indigo cards. shorts are silver.
 
K

Keith Thompson

Tobias Oed said:
John Tsiombikas (Nuclear / the Lab) wrote: [...]
P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

google for n869
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
enjoy the read :^)
Tobias

And keep in mind that n869 is a *draft*; it's not actually the
standard. I understand that there were significant changes between
n869 and the final standard.
 
D

Dan Pop

In said:
Tobias Oed said:
John Tsiombikas (Nuclear / the Lab) wrote: [...]
P.S. I caught something about a free draft of the standard on the
internet in some other message but I missed it, is that so? and where
can I find it?

google for n869
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
enjoy the read :^)
Tobias

And keep in mind that n869 is a *draft*; it's not actually the
standard. I understand that there were significant changes between
n869 and the final standard.

It depends on your definition of "significant". For the purposes of
c.l.c (as well as for someone who just wants to learn C99), the changes
are hardly significant. A few examples:

o More details in the representation of signed integer types.

o The prohibition of defining __cplusplus.

o The addition of _Exit() to the standard library specification.

o Signed integer conversions can raise a signal if the value cannot be
represented in the target type.

o More details in the specification of the exact-width types defined
by <stdint.h>

I really see no point in flaming the people who use N869 in this newsgroup
instead of the real thing, especially considering that C99 doesn't come
in plain text format, so it's a lot less convenient for quick searches
and for cut & paste (although these actions can be performed on the PDF
version).

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top