Re: x86 Stack Confusion

Discussion in 'C Programming' started by Grumble, Jan 9, 2006.

  1. Grumble

    Grumble Guest

    [ Hello comp.lang.c,

    As far as I understand, C89 and C99 leave the details of parameter
    passing up to the implementation. For that reason, I've claimed in
    comp.lang.asm.x86 that there is no such thing as "the C calling
    convention". Am I mistaken? ]

    David J. Craig wrote:

    > Grumble wrote:
    >
    >> Randy Hyde wrote:
    >>
    >>> Grumble wrote:
    >>>
    >>>> shellcode wrote:
    >>>>
    >>>>> [...] The stack function subtracts 4 from esp and saves ebp
    >>>>> (to comply with the C calling convention).
    >>>>
    >>>> Just a nit:
    >>>>
    >>>> There is no "C calling convention".
    >>>
    >>> Actually, just to "nit" right back at you, there *is* a
    >>> *convention*. What there isn't is a requirement.

    >>
    >> How can you claim there is such a thing as the "C calling
    >> convention" when C compilers run on hundreds of different
    >> platforms?
    >>
    >> What you (probably) have in mind is the so-called "Function Calling
    >> Sequence" defined in the Intel386 Architecture Processor
    >> Supplement of the System V Application Binary Interface (ABI)
    >> document.
    >>
    >> http://www.caldera.com/developers/devspecs/abi386-4.pdf

    >
    > There is a 'C calling convention' in that right to left passing of
    > arguments, how those arguments are passed based upon size
    > adjustments, and that the caller is responsible to 'cleanup' the call
    > after it returns. This right to left passing is required for
    > functions that allow a variable number of arguments.


    comp.lang.c readers: are any of these assertions correct? I don't see
    any reference to "right to left passing of arguments" or cleanup or
    "size adjustments" in the C89 draft.

    http://rm-f.net/~orange/devel/specifications/c89-draft.html

    I think float parameters in variadic functions are promoted to double ??
    but that is the only "size adjustment" I can think of.

    --
    Regards, Grumble
    Grumble, Jan 9, 2006
    #1
    1. Advertising

  2. Grumble

    pemo Guest

    "Grumble" <> wrote in message
    news:43c24999$0$27306$...
    >[ Hello comp.lang.c,
    >
    > As far as I understand, C89 and C99 leave the details of parameter
    > passing up to the implementation. For that reason, I've claimed in
    > comp.lang.asm.x86 that there is no such thing as "the C calling
    > convention". Am I mistaken? ]
    >
    > David J. Craig wrote:
    >
    >> Grumble wrote:
    >>
    >>> Randy Hyde wrote:
    >>>
    >>>> Grumble wrote:
    >>>>
    >>>>> shellcode wrote:
    >>>>>
    >>>>>> [...] The stack function subtracts 4 from esp and saves ebp
    >>>>>> (to comply with the C calling convention).
    >>>>>
    >>>>> Just a nit:
    >>>>>
    >>>>> There is no "C calling convention".
    >>>>
    >>>> Actually, just to "nit" right back at you, there *is* a
    >>>> *convention*. What there isn't is a requirement.
    >>>
    >>> How can you claim there is such a thing as the "C calling
    >>> convention" when C compilers run on hundreds of different
    >>> platforms?
    >>>
    >>> What you (probably) have in mind is the so-called "Function Calling
    >>> Sequence" defined in the Intel386 Architecture Processor
    >>> Supplement of the System V Application Binary Interface (ABI)
    >>> document.
    >>>
    >>> http://www.caldera.com/developers/devspecs/abi386-4.pdf

    >>
    >> There is a 'C calling convention' in that right to left passing of
    >> arguments, how those arguments are passed based upon size
    >> adjustments, and that the caller is responsible to 'cleanup' the call
    >> after it returns. This right to left passing is required for
    >> functions that allow a variable number of arguments.

    >
    > comp.lang.c readers: are any of these assertions correct? I don't see
    > any reference to "right to left passing of arguments" or cleanup or
    > "size adjustments" in the C89 draft.
    >
    > http://rm-f.net/~orange/devel/specifications/c89-draft.html
    >
    > I think float parameters in variadic functions are promoted to double ??
    > but that is the only "size adjustment" I can think of.


    IMHO, as long as variadic functions are supported, and [thus] the semantics
    of 7.15 (Variable arguments) are supported, it's up to the implementation:
    there's certainly no need for a mandatory right-left [or whatever] and the
    std says nothing whatsoever about the term 'stack'.
    pemo, Jan 9, 2006
    #2
    1. Advertising

  3. Grumble wrote:
    > [ Hello comp.lang.c,
    >
    > As far as I understand, C89 and C99 leave the details of parameter
    > passing up to the implementation. For that reason, I've claimed in
    > comp.lang.asm.x86 that there is no such thing as "the C calling
    > convention". Am I mistaken? ]
    >
    > David J. Craig wrote:
    >
    > > Grumble wrote:
    > >
    > >> Randy Hyde wrote:
    > >>
    > >>> Grumble wrote:
    > >>>
    > >>>> shellcode wrote:
    > >>>>
    > >>>>> [...] The stack function subtracts 4 from esp and saves ebp
    > >>>>> (to comply with the C calling convention).
    > >>>>
    > >>>> Just a nit:
    > >>>>
    > >>>> There is no "C calling convention".
    > >>>
    > >>> Actually, just to "nit" right back at you, there *is* a
    > >>> *convention*. What there isn't is a requirement.
    > >>
    > >> How can you claim there is such a thing as the "C calling
    > >> convention" when C compilers run on hundreds of different
    > >> platforms?
    > >>
    > >> What you (probably) have in mind is the so-called "Function Calling
    > >> Sequence" defined in the Intel386 Architecture Processor
    > >> Supplement of the System V Application Binary Interface (ABI)
    > >> document.
    > >>
    > >> http://www.caldera.com/developers/devspecs/abi386-4.pdf

    > >
    > > There is a 'C calling convention' in that right to left passing of
    > > arguments, how those arguments are passed based upon size
    > > adjustments, and that the caller is responsible to 'cleanup' the call
    > > after it returns. This right to left passing is required for
    > > functions that allow a variable number of arguments.

    >
    > comp.lang.c readers: are any of these assertions correct? I don't see
    > any reference to "right to left passing of arguments" or cleanup or
    > "size adjustments" in the C89 draft.
    >
    > http://rm-f.net/~orange/devel/specifications/c89-draft.html
    >
    > I think float parameters in variadic functions are promoted to double ??
    > but that is the only "size adjustment" I can think of.


    "C calling convention" is a term used to refer to the
    implementation-specific details of how function calls are performed,
    usually defined as part of a platform-specific ABI. This convention
    differs from platform to platform but often consists of the following
    details:

    * Arguments passed on a stack from right to left
    * The function performing the call prepares the arguments on the stack
    for the called function and removes them from the stack when the
    function returns
    * Registers that are expected to be used for specific purposes and
    which registers are expected to be preserved and overwritten during a
    function call.

    So, as far as Standard C is concerned, there is no "C calling
    convention", any such convention would be part of the implementation
    defined details not specified by the Standard. The calling conventions
    themselves are based on the architecture and the implementation on that
    architechture and are just that, conventions. The x86 platform has a
    set of conventions that almost all implementations follow, for example
    that the EAX, ECX, and EDX registers are not expected to be preserved
    through a function call. Although these conventions must be followed
    to conform to Intel's x86 ABI, it is entirely possible to create a
    Standard-conforming implementation without following them.

    Robert Gamble
    Robert Gamble, Jan 9, 2006
    #3
  4. Grumble

    Guest

    Grumble wrote:
    > [ Hello comp.lang.c,
    >
    > As far as I understand, C89 and C99 leave the details of parameter
    > passing up to the implementation. For that reason, I've claimed in
    > comp.lang.asm.x86 that there is no such thing as "the C calling
    > convention". Am I mistaken? ]


    There is no "C calling convention" imposed by the C standard --
    instead, on the x86 platform the convention exists that is adhered to
    by a number of C compilers (and other platforms have a similar scheme
    -- its also called "the ABI".) It provides a way of mapping call
    parameters in C to the assembly registers and stack in a standard way.
    This is how it is possible for Fortran and C libraries to call each
    other, even when you vary compilers on each side. As an example, the
    typical Pascal compilers for x86 from yester year used another
    convention called "Pascal calling convention" which, in fact, older
    Microsoft C compilers also supported as an option.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Jan 9, 2006
    #4
  5. Grumble

    Chuck F. Guest

    Grumble wrote:
    >
    > As far as I understand, C89 and C99 leave the details of
    > parameter passing up to the implementation. For that reason,
    > I've claimed in comp.lang.asm.x86 that there is no such thing as
    > "the C calling convention". Am I mistaken? ]


    No. However, C is almost unique among languages in having the
    error prone variadic functions available, which in turn mandate
    having the first parameter in a known place, and makes the reverse
    order (assuming a stack, which is not necessary) attractive.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Chuck F., Jan 9, 2006
    #5
  6. Grumble

    jacob navia Guest

    a écrit :
    > Grumble wrote:
    >
    >>[ Hello comp.lang.c,
    >>
    >>As far as I understand, C89 and C99 leave the details of parameter
    >>passing up to the implementation. For that reason, I've claimed in
    >>comp.lang.asm.x86 that there is no such thing as "the C calling
    >>convention". Am I mistaken? ]

    >
    >
    > There is no "C calling convention" imposed by the C standard --
    > instead, on the x86 platform the convention exists that is adhered to
    > by a number of C compilers (and other platforms have a similar scheme
    > -- its also called "the ABI".) It provides a way of mapping call
    > parameters in C to the assembly registers and stack in a standard way.
    > This is how it is possible for Fortran and C libraries to call each
    > other, even when you vary compilers on each side. As an example, the
    > typical Pascal compilers for x86 from yester year used another
    > convention called "Pascal calling convention" which, in fact, older
    > Microsoft C compilers also supported as an option.
    >


    There is no C calling convention. The "C" calling convention is defined
    by the compiler that compiles the operating system, usually written
    in C.

    Under the linux OS, the gcc compiler defines the calling convention
    rules, and other compilers must obey whatever gcc decides is the
    calling convention. If not, they would be faced with the
    herculean task of rewriting the whole OS.

    Under the windows OS, the compiler that compiled the OS is MSVC,
    and other compilers must follow the conventions of that compiler.

    In newer systems, like the new x64 systems, there is no "right to left",
    nor "left to right" since four or more arguments are passed in
    the register file.

    For instance, you can pass up to 4 arguments to a function directly
    in registers under windows 64 bits. Linux 64 bits is even more ambitious
    and much more parameters are passed in registers using both the
    integer and the floating point register file. (for x86 systems)

    In general, in each system there is something like an "ABI" (Application
    Binary Interface) that defines what the conventions of the OS are. Since
    C is a language that interfaces directly to the OS, calling conventions
    are highly OS specific.

    Most compilers give the user the possibility of choosing the calling
    convention for either all the functions or for specific functions
    using markers in the declaration header of each function. For instance:

    int _stdcall fn(int a,int b) { /* ... */ }

    In most compilers the "cdecl" marker is the default, i.e. the ABI
    defined calling convention. Note that the standard never defines
    "cdecl".

    jacob
    jacob navia, Jan 9, 2006
    #6
  7. Grumble

    osmium Guest

    "Chuck F. " wrote:

    > Grumble wrote:
    >>
    >> As far as I understand, C89 and C99 leave the details of
    >> parameter passing up to the implementation. For that reason,
    >> I've claimed in comp.lang.asm.x86 that there is no such thing as
    >> "the C calling convention". Am I mistaken? ]

    >
    > No. However, C is almost unique among languages in having the error prone
    > variadic functions available, which in turn mandate having the first
    > parameter in a known place, and makes the reverse order (assuming a stack,
    > which is not necessary) attractive.


    When a knowledgeable person says "C calling convention", *this* is what he
    means. There is nothing analogous to printf() with it's indeterminate
    number of parameters in, Pascal, for example.
    osmium, Jan 9, 2006
    #7
  8. "osmium" <> writes:
    > When a knowledgeable person says "C calling convention", *this* is
    > what he means. There is nothing analogous to printf() with it's
    > indeterminate number of parameters in, Pascal, for example.


    Yes, there is. Write() and WriteLn() both take a variable number of
    arguments. There is however no way for the programmer to define a
    procedure which takes a variable number of arguments.

    DES
    --
    Dag-Erling Smørgrav -
    =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=, Jan 9, 2006
    #8
  9. Grumble

    Grumble Guest

    Robert Gamble wrote:

    > Grumble wrote:
    >
    >>[ Hello comp.lang.c,
    >>
    >>As far as I understand, C89 and C99 leave the details of parameter
    >>passing up to the implementation. For that reason, I've claimed in
    >>comp.lang.asm.x86 that there is no such thing as "the C calling
    >>convention". Am I mistaken? ]
    >>
    >>David J. Craig wrote:
    >>
    >>
    >>>Grumble wrote:
    >>>
    >>>
    >>>>Randy Hyde wrote:
    >>>>
    >>>>
    >>>>>Grumble wrote:
    >>>>>
    >>>>>
    >>>>>>shellcode wrote:
    >>>>>>
    >>>>>>
    >>>>>>>[...] The stack function subtracts 4 from esp and saves ebp
    >>>>>>>(to comply with the C calling convention).
    >>>>>>
    >>>>>>Just a nit:
    >>>>>>
    >>>>>>There is no "C calling convention".
    >>>>>
    >>>>>Actually, just to "nit" right back at you, there *is* a
    >>>>>*convention*. What there isn't is a requirement.
    >>>>
    >>>>How can you claim there is such a thing as the "C calling
    >>>>convention" when C compilers run on hundreds of different
    >>>>platforms?
    >>>>
    >>>>What you (probably) have in mind is the so-called "Function Calling
    >>>>Sequence" defined in the Intel386 Architecture Processor
    >>>>Supplement of the System V Application Binary Interface (ABI)
    >>>>document.
    >>>>
    >>>>http://www.caldera.com/developers/devspecs/abi386-4.pdf
    >>>
    >>>There is a 'C calling convention' in that right to left passing of
    >>>arguments, how those arguments are passed based upon size
    >>>adjustments, and that the caller is responsible to 'cleanup' the call
    >>>after it returns. This right to left passing is required for
    >>>functions that allow a variable number of arguments.

    >>
    >>comp.lang.c readers: are any of these assertions correct? I don't see
    >>any reference to "right to left passing of arguments" or cleanup or
    >>"size adjustments" in the C89 draft.
    >>
    >>http://rm-f.net/~orange/devel/specifications/c89-draft.html
    >>
    >>I think float parameters in variadic functions are promoted to double ??
    >>but that is the only "size adjustment" I can think of.

    >
    >
    > "C calling convention" is a term used to refer to the
    > implementation-specific details of how function calls are performed,
    > usually defined as part of a platform-specific ABI. This convention
    > differs from platform to platform but often consists of the following
    > details:
    >
    > * Arguments passed on a stack from right to left
    > * The function performing the call prepares the arguments on the stack
    > for the called function and removes them from the stack when the
    > function returns
    > * Registers that are expected to be used for specific purposes and
    > which registers are expected to be preserved and overwritten during a
    > function call.


    The calling convention on IA-64 is rather different:
    http://blogs.msdn.com/oldnewthing/archive/2004/01/13/58199.aspx
    http://www.intel.com/design/itanium/downloads/245358.htm

    --
    Regards, Grumble
    Grumble, Jan 9, 2006
    #9
  10. jacob navia <> writes:
    [snip]
    > There is no C calling convention. The "C" calling convention is defined
    > by the compiler that compiles the operating system, usually written
    > in C.
    >
    > Under the linux OS, the gcc compiler defines the calling convention
    > rules, and other compilers must obey whatever gcc decides is the
    > calling convention. If not, they would be faced with the
    > herculean task of rewriting the whole OS.
    >
    > Under the windows OS, the compiler that compiled the OS is MSVC,
    > and other compilers must follow the conventions of that compiler.
    >
    > In newer systems, like the new x64 systems, there is no "right to left",
    > nor "left to right" since four or more arguments are passed in
    > the register file.
    >
    > For instance, you can pass up to 4 arguments to a function directly
    > in registers under windows 64 bits. Linux 64 bits is even more ambitious
    > and much more parameters are passed in registers using both the
    > integer and the floating point register file. (for x86 systems)
    >
    > In general, in each system there is something like an "ABI" (Application
    > Binary Interface) that defines what the conventions of the OS are. Since
    > C is a language that interfaces directly to the OS, calling conventions
    > are highly OS specific.
    >
    > Most compilers give the user the possibility of choosing the calling
    > convention for either all the functions or for specific functions
    > using markers in the declaration header of each function. For instance:
    >
    > int _stdcall fn(int a,int b) { /* ... */ }
    >
    > In most compilers the "cdecl" marker is the default, i.e. the ABI
    > defined calling convention. Note that the standard never defines
    > "cdecl".


    All of this is x86-specific.

    I have no idea whether "most compilers" have things called "_stdcall"
    or "cdecl", but I've never used either.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 9, 2006
    #10
  11. Grumble

    Chuck F. Guest

    Dag-Erling Smørgrav wrote:
    > "osmium" <> writes:
    >
    >> When a knowledgeable person says "C calling convention",
    >> *this* is what he means. There is nothing analogous to
    >> printf() with it's indeterminate number of parameters in,
    >> Pascal, for example.

    >
    > Yes, there is. Write() and WriteLn() both take a variable
    > number of arguments. There is however no way for the programmer
    > to define a procedure which takes a variable number of
    > arguments.


    <OT>
    No there isn't. writeln(f) is the actual function. If the source
    code reads "writeln(f, x, y)" it is expanded, in the compiler, to
    "write(f, x); write(f, y); writeln(f)". A similar process applies
    to write(f, x, y) which expands to "write(f, x); write(f, y)". The
    same process applies to read and readln. If the first parameter
    does not specify a file then output (or input) is assumed.

    Since the expansion is done before code generation, there is no
    need for a variadic function mechanism, and all parameter types can
    be properly checked.

    Another point is that the individual write (or read) calls operate
    on a single item, of known type. The compiler calls the
    appropriate i/o routine for the type, so a linkage is likely to
    show such things as writeint, writereal, writestring, etc. This
    totally avoids the expense of loading a monster interpreter to
    process format strings.

    Don't argue with me on this; I have been using and implementing
    Pascal for nearly 30 years. If you want more details see the
    Pascal standards (ISO7185 and ISO10206) or use email.
    </OT>

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Chuck F., Jan 9, 2006
    #11
  12. "Chuck F. " <> writes:
    > Grumble wrote:
    >> As far as I understand, C89 and C99 leave the details of
    >> parameter passing up to the implementation. For that reason,
    >> I've claimed in comp.lang.asm.x86 that there is no such thing as
    >> "the C calling convention". Am I mistaken? ]

    >
    > No. However, C is almost unique among languages in having the error
    > prone variadic functions available, which in turn mandate having the
    > first parameter in a known place, and makes the reverse order
    > (assuming a stack, which is not necessary) attractive.


    Not just the first parameter; there can be one or more parameters
    before the "...".

    Before C89's introduction of prototypes, an particularly the "..."
    syntax, there was generally no way for a compiler to tell whether
    some_func(a, b, c, d);
    was an ordinary function call or a call to a function expecting a
    variable number and type of arguments. The compiler had to generate
    the same kind of call for either case, and the function had to use
    some technique that knew where to find the parameter values (typically
    using the old <varargs.h> header, but there were uglier techniques
    before that was introduced).

    With modern prototypes, compilers are free to use a different and more
    efficient calling convention for ordinary functions than for functions
    that take a variable number of arguments (since a call to the latter
    without a prototype invokes undefined behavior) -- but as far as I
    know, most compilers have kept the old calling conventions. So, for
    example, printf("%s\n", "Hello, world") is likely to work correctly
    even if no prototype is visible, because the calling convention was
    designed before prototypes existed.

    This is, of course, no excuse the required "#include <stdio.h>".

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 9, 2006
    #12
  13. (Dag-Erling Smørgrav) writes:
    > "osmium" <> writes:
    >> When a knowledgeable person says "C calling convention", *this* is
    >> what he means. There is nothing analogous to printf() with it's
    >> indeterminate number of parameters in, Pascal, for example.

    >
    > Yes, there is. Write() and WriteLn() both take a variable number of
    > arguments. There is however no way for the programmer to define a
    > procedure which takes a variable number of arguments.


    Yes, but as I recall the Write and WriteLn procedures, unlike C's
    printf(), are "magical". There's no format string, so it's up to the
    compiler to generate code based on the actual argument types. A
    compiler might typically generate a distinct procedure call for each
    argument. It's more like special-case overloading than C's "..."
    mechanism. Since the compiler can do whatever it likes, there's no
    need for special-purpose calling conventions to make everything come
    out right.

    This is perhaps marginally off-topic, but it does illustrate some of
    the design decisions that went into C. C implements its I/O functions
    using (more or less) ordinary function calls, while Pascal uses
    compiler magic.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 9, 2006
    #13
  14. Keith Thompson <> writes:

    > (Dag-Erling Smørgrav) writes:
    >> "osmium" <> writes:
    >>> When a knowledgeable person says "C calling convention", *this* is
    >>> what he means. There is nothing analogous to printf() with it's
    >>> indeterminate number of parameters in, Pascal, for example.

    >>
    >> Yes, there is. Write() and WriteLn() both take a variable number of
    >> arguments. There is however no way for the programmer to define a
    >> procedure which takes a variable number of arguments.

    >
    > Yes, but as I recall the Write and WriteLn procedures, unlike C's
    > printf(), are "magical". There's no format string, so it's up to the
    > compiler to generate code based on the actual argument types. A
    > compiler might typically generate a distinct procedure call for each
    > argument. It's more like special-case overloading than C's "..."
    > mechanism. Since the compiler can do whatever it likes, there's no
    > need for special-purpose calling conventions to make everything come
    > out right.
    >
    > This is perhaps marginally off-topic, but it does illustrate some of
    > the design decisions that went into C. C implements its I/O functions
    > using (more or less) ordinary function calls, while Pascal uses
    > compiler magic.


    Actually gcc for example will typically silently replace

    printf("Hello\n");

    with

    puts("Hello\n");


    This makes hello.c 3k long on my system. The compiler does interpret
    the format string, and uses the full printf where needed. This also
    allows it to catch errors where the parameters do not match the format
    string.


    --

    John Devereux
    John Devereux, Jan 9, 2006
    #14
  15. Grumble

    jacob navia Guest

    Keith Thompson a écrit :
    > jacob navia <> writes:
    > [snip]
    >
    >>There is no C calling convention. The "C" calling convention is defined
    >>by the compiler that compiles the operating system, usually written
    >>in C.
    >>
    >>Under the linux OS, the gcc compiler defines the calling convention
    >>rules, and other compilers must obey whatever gcc decides is the
    >>calling convention. If not, they would be faced with the
    >>herculean task of rewriting the whole OS.
    >>
    >>Under the windows OS, the compiler that compiled the OS is MSVC,
    >>and other compilers must follow the conventions of that compiler.
    >>
    >>In newer systems, like the new x64 systems, there is no "right to left",
    >>nor "left to right" since four or more arguments are passed in
    >>the register file.
    >>
    >>For instance, you can pass up to 4 arguments to a function directly
    >>in registers under windows 64 bits. Linux 64 bits is even more ambitious
    >>and much more parameters are passed in registers using both the
    >>integer and the floating point register file. (for x86 systems)
    >>
    >>In general, in each system there is something like an "ABI" (Application
    >>Binary Interface) that defines what the conventions of the OS are. Since
    >>C is a language that interfaces directly to the OS, calling conventions
    >>are highly OS specific.
    >>
    >>Most compilers give the user the possibility of choosing the calling
    >>convention for either all the functions or for specific functions
    >>using markers in the declaration header of each function. For instance:
    >>
    >>int _stdcall fn(int a,int b) { /* ... */ }
    >>
    >>In most compilers the "cdecl" marker is the default, i.e. the ABI
    >>defined calling convention. Note that the standard never defines
    >>"cdecl".

    >
    >
    > All of this is x86-specific.
    >
    > I have no idea whether "most compilers" have things called "_stdcall"
    > or "cdecl", but I've never used either.
    >


    If you re-read what I said, you will notice that I never said that
    "most compilers have things called _stdcall", but that they have
    "markers" to indicate the preferred calling convention. The _stdcall
    was just an example of a marker. Gcc uses other markers, and Borland
    yet another. There are compilers (definitely) with only ONE calling
    convention but most of them do have several, and they do use some
    syntax to allow the user to specify which one he/she prefers.

    The _stdcall calling convention is called "pascal" in some compilers,
    and means that insetad of the caller adjusting the stack after a call,
    it is the callee that does it. This is more efficient and can save
    approximately 5% of code size, depending on the machine.

    jacob
    jacob navia, Jan 9, 2006
    #15
  16. Grumble

    Mark B Guest

    "John Devereux" <> wrote in message
    news:...

    <snip>
    > Actually gcc for example will typically silently replace
    >
    > printf("Hello\n");
    >
    > with
    >
    > puts("Hello\n");


    Doubtful... those 2 lines are not equivalent.
    Mark B, Jan 9, 2006
    #16
  17. John Devereux wrote:
    > Keith Thompson <> writes:
    >
    > > (Dag-Erling Smørgrav) writes:
    > >> "osmium" <> writes:
    > >>> When a knowledgeable person says "C calling convention", *this* is
    > >>> what he means. There is nothing analogous to printf() with it's
    > >>> indeterminate number of parameters in, Pascal, for example.
    > >>
    > >> Yes, there is. Write() and WriteLn() both take a variable number of
    > >> arguments. There is however no way for the programmer to define a
    > >> procedure which takes a variable number of arguments.

    > >
    > > Yes, but as I recall the Write and WriteLn procedures, unlike C's
    > > printf(), are "magical". There's no format string, so it's up to the
    > > compiler to generate code based on the actual argument types. A
    > > compiler might typically generate a distinct procedure call for each
    > > argument. It's more like special-case overloading than C's "..."
    > > mechanism. Since the compiler can do whatever it likes, there's no
    > > need for special-purpose calling conventions to make everything come
    > > out right.
    > >
    > > This is perhaps marginally off-topic, but it does illustrate some of
    > > the design decisions that went into C. C implements its I/O functions
    > > using (more or less) ordinary function calls, while Pascal uses
    > > compiler magic.

    >
    > Actually gcc for example will typically silently replace
    >
    > printf("Hello\n");
    >
    > with
    >
    > puts("Hello\n");


    ITYM:
    puts("Hello");

    Robert Gamble
    Robert Gamble, Jan 9, 2006
    #17
  18. Grumble

    jacob navia Guest

    John Devereux a écrit :
    >
    > Actually gcc for example will typically silently replace
    >
    > printf("Hello\n");
    >
    > with
    >
    > puts("Hello\n");
    >
    >
    > This makes hello.c 3k long on my system. The compiler does interpret
    > the format string, and uses the full printf where needed. This also
    > allows it to catch errors where the parameters do not match the format
    > string.
    >
    >


    Replacing printf with puts can be only done when the return value
    is not used, since puts returns "some nonnegative value" according to
    the standard, not the number of characters written.
    jacob navia, Jan 9, 2006
    #18
  19. Grumble

    Flash Gordon Guest

    jacob navia wrote:
    > John Devereux a écrit :
    >>
    >> Actually gcc for example will typically silently replace
    >> printf("Hello\n");
    >>
    >> with
    >>
    >> puts("Hello\n");
    >>
    >> This makes hello.c 3k long on my system. The compiler does interpret
    >> the format string, and uses the full printf where needed. This also
    >> allows it to catch errors where the parameters do not match the format
    >> string.

    >
    > Replacing printf with puts can be only done when the return value
    > is not used, since puts returns "some nonnegative value" according to
    > the standard, not the number of characters written.


    If the implementation wants to do that replacement, it can make puts
    return the number of characters written, since in this universe the
    number of characters written will always be non-negative. I assume that
    gcc only makes this replacement on systems where it knows that this is
    the non-negative value that will be returned.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Jan 9, 2006
    #19
  20. "Robert Gamble" <> writes:

    > John Devereux wrote:
    >> Keith Thompson <> writes:
    >>
    >> > (Dag-Erling Smørgrav) writes:
    >> >> "osmium" <> writes:
    >> >>> When a knowledgeable person says "C calling convention", *this* is
    >> >>> what he means. There is nothing analogous to printf() with it's
    >> >>> indeterminate number of parameters in, Pascal, for example.
    >> >>
    >> >> Yes, there is. Write() and WriteLn() both take a variable number of
    >> >> arguments. There is however no way for the programmer to define a
    >> >> procedure which takes a variable number of arguments.
    >> >
    >> > Yes, but as I recall the Write and WriteLn procedures, unlike C's
    >> > printf(), are "magical". There's no format string, so it's up to the
    >> > compiler to generate code based on the actual argument types. A
    >> > compiler might typically generate a distinct procedure call for each
    >> > argument. It's more like special-case overloading than C's "..."
    >> > mechanism. Since the compiler can do whatever it likes, there's no
    >> > need for special-purpose calling conventions to make everything come
    >> > out right.
    >> >
    >> > This is perhaps marginally off-topic, but it does illustrate some of
    >> > the design decisions that went into C. C implements its I/O functions
    >> > using (more or less) ordinary function calls, while Pascal uses
    >> > compiler magic.

    >>
    >> Actually gcc for example will typically silently replace
    >>
    >> printf("Hello\n");
    >>
    >> with
    >>
    >> puts("Hello\n");

    >
    > ITYM:
    > puts("Hello");



    Yes, you are correct! - I admit I never knew that puts() appends a
    newline... In fact the only reason I ever encountered it in the first
    place is tracking down why printf was not being linked in!

    #include <stdio.h>

    int main(void)
    {
    printf("Hello, World!\n");
    }


    <sorry for OT-ness>:

    .file "test.c"
    .section .rodata
    ..LC0:
    .string "Hello, World!"
    .text
    ..globl main
    .type main, @function
    main:
    pushl %ebp
    movl %esp, %ebp
    subl $8, %esp
    andl $-16, %esp
    movl $0, %eax
    addl $15, %eax
    addl $15, %eax
    shrl $4, %eax
    sall $4, %eax
    subl %eax, %esp
    subl $12, %esp
    pushl $.LC0
    call puts
    addl $16, %esp
    leave
    ret
    .size main, .-main
    .ident "GCC: (GNU) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)"
    .section .note.GNU-stack,"",@progbits


    --

    John Devereux
    John Devereux, Jan 9, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Mabee
    Replies:
    4
    Views:
    497
    Jonathan Mcdougall
    Dec 26, 2004
  2. Replies:
    4
    Views:
    374
    Branimir Maksimovic
    Oct 20, 2005
  3. Surinder Singh
    Replies:
    1
    Views:
    1,188
    Richard Bos
    Dec 20, 2007
  4. omkarenator

    stack pointer alignment on x86 and x86_64

    omkarenator, May 1, 2009, in forum: C Programming
    Replies:
    2
    Views:
    1,444
    omkarenator
    May 1, 2009
  5. Casey Hawthorne
    Replies:
    3
    Views:
    1,079
    Flash Gordon
    Nov 1, 2009
Loading...

Share This Page