what does the standard say about parameter passing?

Discussion in 'C Programming' started by Tobias Oed, Jun 26, 2003.

  1. Tobias Oed

    Tobias Oed Guest

    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.
    google for n869
    http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
    enjoy the read :^)
    Tobias
     
    Tobias Oed, Jun 26, 2003
    #1
    1. Advertisements

  2. 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 --
     
    John Tsiombikas (Nuclear / the Lab), Jun 26, 2003
    #2
    1. Advertisements

  3. Tobias Oed

    Eric Sosman Guest

    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.
    Google for "N869".
     
    Eric Sosman, Jun 26, 2003
    #3
  4. Hi, I don't have a copy of the standard, and I'm curious if the
    *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.
    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.
    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
     
    Gordon Burditt, Jun 26, 2003
    #4
  5. Tobias Oed

    bd Guest

    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).
    A search engine is usually used in these situations.
     
    bd, Jun 26, 2003
    #5
  6. John Tsiombikas (Nuclear / the Lab), Jun 27, 2003
    #6
  7. - using the stack to pass parameters
    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.
    that's true

    -- Nuclear / the Lab --
     
    John Tsiombikas (Nuclear / the Lab), Jun 27, 2003
    #7
  8. Tobias Oed

    bd Guest

    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.
     
    bd, Jun 27, 2003
    #8
  9. Tobias Oed

    Dan Pop Guest

    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
     
    Dan Pop, Jun 27, 2003
    #9
  10. Tobias Oed

    CBFalconer Guest

    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.
     
    CBFalconer, Jun 27, 2003
    #10
  11. 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.
     
    Keith Thompson, Jun 27, 2003
    #11
  12. Tobias Oed

    Dan Pop Guest

    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
     
    Dan Pop, Jun 30, 2003
    #12
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.