How does the compiler do with this code? - Linux

This is a discussion on How does the compiler do with this code? - Linux ; Måns Rullgård wrote: > Ronald writes: > > >>//it's all >>int main() >>{ >> printf("hello\n"); >>} >> >>Without ``#include ", it can be compiled, linked and run. >>Will there be a chance for bugs? > > > Yes, anything can ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 49

Thread: How does the compiler do with this code?

  1. Re: How does the compiler do with this code?

    Måns Rullgård wrote:
    > Ronald writes:
    >
    >
    >>//it's all
    >>int main()
    >>{
    >> printf("hello\n");
    >>}
    >>
    >>Without ``#include ", it can be compiled, linked and run.
    >>Will there be a chance for bugs?

    >
    >
    > Yes, anything can happen. On some systems, arguments are passed
    > differently depending on how the function is declared. Specifically,
    > functions declared as taking a variable number of arguments often get
    > them passed differently than functions with a fixed argument list.


    Isn't this usually handled in the *called* functions only?

    I don't know many different architectures or gcc versions, but when
    trying to sort out how this was done in i386 and x86_64 architectures, I
    found that the calling function was unaware of the called function's
    handling. It put the arguments in the same locations (e.g. x86_64 puts
    the first 6 arguments in registers), irrespective of variable arguments.
    The called function would then first arrange to put the arguments where
    they were needed for varargs.

    Josef
    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  2. Re: How does the compiler do with this code?

    Ronald wrote:
    > //it's all
    > int main()
    > {
    > printf("hello\n");
    > }
    >
    > Without ``#include ", it can be compiled, linked and run.

    It then assumes printf takes the amount of argumnets you call it with
    of type int, and returns an int.
    On some machines that assumption happens to be compatible with
    the actual printf function, on others it does not.

    > Will there be a chance for bugs?

    Yes.

  3. Re: How does the compiler do with this code?

    "Nils O. Selåsdal" wrote:
    >Ronald wrote:
    >> //it's all
    >> int main()
    >> {
    >> printf("hello\n");
    >> }
    >> Without ``#include ", it can be compiled, linked and
    >> run.

    >It then assumes printf takes the amount of argumnets you call it with
    >of type int, and returns an int.


    It does assume the int return, but it assumes that the format
    argument specifies the number and type of all following arguments.

    The potential for error is that the compiler cannot verify the
    parameter list is valid (which it may or many not attempt to do
    even if a prototype for printf is in scope).

    >On some machines that assumption happens to be compatible with
    >the actual printf function, on others it does not.


    The above assumption will be correct on *all* machines,
    otherwise it is not the C language, which specifies how printf
    works.

    >> Will there be a chance for bugs?

    >Yes.


    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  4. Re: How does the compiler do with this code?

    Nils O. Selåsdal wrote:
    > Ronald wrote:
    >
    >> //it's all
    >> int main()
    >> {
    >> printf("hello\n");
    >> }
    >>
    >> Without ``#include ", it can be compiled, linked and run.

    >
    > It then assumes printf takes the amount of argumnets you call it with
    > of type int,


    In that case, Ronald's usage would be wrong, as he calls it with a
    pointer argument.

    IIRC the compiler assumes that the *supplied* arguments are correct and
    that the function ...
    > and returns an int.

    Which is correct, in this case.

    So, effectively, the assumed prototype would be "int printf(...);"
    (though I'm not sure if this is indeed a syntacally correct).

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  5. Re: How does the compiler do with this code?

    "Nils O. Selåsdal" writes:

    > Ronald wrote:
    > > //it's all
    > > int main()
    > > {
    > > printf("hello\n");
    > > }
    > > Without ``#include ", it can be compiled, linked and run.

    > It then assumes printf takes the amount of argumnets you call it with
    > of type int, and returns an int.


    Not quite -- floats get promoted to double.

    > On some machines that assumption happens to be compatible with
    > the actual printf function, on others it does not.


    Are there any actual machines for which it's not?

    > > Will there be a chance for bugs?

    > Yes.

    --
    Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
    Department of Computer Science FAX -- (505) 646-1002
    New Mexico State University http://www.cs.nmsu.edu/~pfeiffer

  6. Re: How does the compiler do with this code?

    Josef Moellers wrote:
    >Nils O. Selåsdal wrote:
    >> Ronald wrote:
    >>
    >>> //it's all
    >>> int main()
    >>> {
    >>> printf("hello\n");
    >>> }
    >>>
    >>> Without ``#include ", it can be compiled, linked and run.

    >> It then assumes printf takes the amount of argumnets you call
    >> it with
    >> of type int,

    >
    >In that case, Ronald's usage would be wrong, as he calls it with
    >a pointer argument.
    >
    >IIRC the compiler assumes that the *supplied* arguments are
    >correct and that the function ...
    >> and returns an int.

    >Which is correct, in this case.
    >
    >So, effectively, the assumed prototype would be "int
    >printf(...);" (though I'm not sure if this is indeed a
    >syntacally correct).


    Actually it would be assumed to be

    int printf( const char * restrict format, ... );

    The string pointed to by /format/ specifies the minimum number
    of arguments that must be in the parameter list. Fewer
    arguments than specified will cause undefined behavior. Extra
    arguments will be evaluated prior to execution of the function,
    but will be ignored by the function itself.

    Which means this is valid C,

    int foo (void) {putchar('H');}
    int main(void)
    {
    printf("ello world!\n", foo());
    return 0;
    }

    and will in fact print "Hello world!" to stdout when compiled
    like this

    gcc -ansi -pedantic foo.c

    On the other hand, this is also valid C,

    int foo (void) {putchar('H');}
    int bar (void) {putchar('e');}
    int main(void)
    {
    printf("llo world!\n", foo(), bar());
    return 0;
    }

    But it is ambiguous and might print either of "Hello world!" or
    "eHllo world!", and both would be correct, depending on the
    platform.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  7. Re: How does the compiler do with this code?

    Floyd L. Davidson wrote:
    > Josef Moellers wrote:
    >
    >>Nils O. Selåsdal wrote:
    >>
    >>>Ronald wrote:
    >>>
    >>>
    >>>>//it's all
    >>>>int main()
    >>>>{
    >>>> printf("hello\n");
    >>>>}
    >>>>
    >>>>Without ``#include ", it can be compiled, linked and run.
    >>>
    >>>It then assumes printf takes the amount of argumnets you call
    >>>it with
    >>>of type int,

    >>
    >>In that case, Ronald's usage would be wrong, as he calls it with
    >>a pointer argument.
    >>
    >>IIRC the compiler assumes that the *supplied* arguments are
    >>correct and that the function ...
    >>
    >>>and returns an int.

    >>
    >>Which is correct, in this case.
    >>
    >>So, effectively, the assumed prototype would be "int
    >>printf(...);" (though I'm not sure if this is indeed a
    >>syntacally correct).

    >
    >
    > Actually it would be assumed to be
    >
    > int printf( const char * restrict format, ... );


    How can it assume the first argument if "stdio.h" was not included (that
    was the OP's question!)?

    OTOH gcc (or at least one version or the other or one combination of
    compiler flags) seems to know something about printf's format string, as
    I recall having seen error messages like

    "unsigned int argument expected but signed int argument provided".

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  8. Re: How does the compiler do with this code?

    Josef Moellers wrote:
    >Floyd L. Davidson wrote:
    >> Josef Moellers wrote:
    >>
    >>>Nils O. Selåsdal wrote:
    >>>
    >>>>Ronald wrote:
    >>>>
    >>>>
    >>>>>//it's all
    >>>>>int main()
    >>>>>{
    >>>>> printf("hello\n");
    >>>>>}
    >>>>>
    >>>>>Without ``#include ", it can be compiled, linked and run.
    >>>>
    >>>>It then assumes printf takes the amount of argumnets you call
    >>>>it with
    >>>>of type int,
    >>>
    >>>In that case, Ronald's usage would be wrong, as he calls it with
    >>>a pointer argument.
    >>>
    >>>IIRC the compiler assumes that the *supplied* arguments are
    >>>correct and that the function ...
    >>>
    >>>>and returns an int.
    >>>
    >>>Which is correct, in this case.
    >>>
    >>>So, effectively, the assumed prototype would be "int
    >>>printf(...);" (though I'm not sure if this is indeed a
    >>>syntacally correct).

    >> Actually it would be assumed to be
    >> int printf( const char * restrict format, ... );

    >
    >How can it assume the first argument if "stdio.h" was not
    >included (that was the OP's question!)?


    Because that is the way the function is *defined*, it *is* going
    to assume the first argument is a format string. Of course if
    it is not, having a prototype in scope when it is compiled
    might, depending on the compiler, allow the compiler to catch
    the fact that it isn't (or that the number of arguments and
    their type to not match the format string). If there is no
    prototype, then the arguments are passed as is to the printf()
    function and they either work or they don't...

    >OTOH gcc (or at least one version or the other or one
    >combination of compiler flags) seems to know something about
    >printf's format string, as I recall having seen error messages
    >like
    >
    >"unsigned int argument expected but signed int argument provided".


    The GNU C compiler can match the format string to the arguments
    provided. It is not required by the C language to do that
    though. Use either the -Wformat or the -Wall options to enable
    such matching (for printf and scanf and similar functions).

    Even with the warnings enabled it will still compile and be
    executable...

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  9. Re: How does the compiler do with this code?

    Floyd L. Davidson wrote:
    > Josef Moellers wrote:
    >
    >>Floyd L. Davidson wrote:
    >>
    >>>Josef Moellers wrote:
    >>>
    >>>
    >>>>Nils O. Selåsdal wrote:
    >>>>
    >>>>
    >>>>>Ronald wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>//it's all
    >>>>>>int main()
    >>>>>>{
    >>>>>> printf("hello\n");
    >>>>>>}
    >>>>>>
    >>>>>>Without ``#include ", it can be compiled, linked and run.
    >>>>>
    >>>>>It then assumes printf takes the amount of argumnets you call
    >>>>>it with
    >>>>>of type int,
    >>>>
    >>>>In that case, Ronald's usage would be wrong, as he calls it with
    >>>>a pointer argument.
    >>>>
    >>>>IIRC the compiler assumes that the *supplied* arguments are
    >>>>correct and that the function ...
    >>>>
    >>>>
    >>>>>and returns an int.
    >>>>
    >>>>Which is correct, in this case.
    >>>>
    >>>>So, effectively, the assumed prototype would be "int
    >>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>syntacally correct).
    >>>
    >>>Actually it would be assumed to be
    >>> int printf( const char * restrict format, ... );

    >>
    >>How can it assume the first argument if "stdio.h" was not
    >>included (that was the OP's question!)?

    >
    >
    > Because that is the way the function is *defined*, it *is* going
    > to assume the first argument is a format string. Of course if
    > it is not, having a prototype in scope when it is compiled
    > might, depending on the compiler, allow the compiler to catch
    > the fact that it isn't (or that the number of arguments and
    > their type to not match the format string). If there is no
    > prototype, then the arguments are passed as is to the printf()
    > function and they either work or they don't...


    ??? Who/What is "it" as in "it *is* going to assume"?

    Ronald was asking about *calling* printf() (he even gave a code snippet).
    If the compiler which compiles the *call* to printf() has no prototype
    of printf() handy, how does it (i.e. the compiler which compiles the
    *call* to printf()) know that the first argument is expected to be a
    "const char *"? In the absence of a prototype of printf() it will pass
    the arguments as they are given (maybe converting the odd float into a
    double) and hope for the best.

    When compiling printf() itself, I don't see how compiling it without
    knowing what its first argument is going to be would work.

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  10. Re: How does the compiler do with this code?

    2006-12-18 ,
    Josef Moellers wrote:
    > Måns Rullgård wrote:
    >> Ronald writes:
    >>
    >>
    >>>//it's all
    >>>int main()
    >>>{
    >>> printf("hello\n");
    >>>}
    >>>
    >>>Without ``#include ", it can be compiled, linked and run.
    >>>Will there be a chance for bugs?

    >>
    >>
    >> Yes, anything can happen. On some systems, arguments are passed
    >> differently depending on how the function is declared. Specifically,
    >> functions declared as taking a variable number of arguments often get
    >> them passed differently than functions with a fixed argument list.

    >
    > Isn't this usually handled in the *called* functions only?


    That depends on the architecture.

    >
    > I don't know many different architectures or gcc versions, but when
    > trying to sort out how this was done in i386 and x86_64 architectures,


    You can't name just two architectures when saying what's "usually" done,
    even on comp.os.linux.development.apps - you'd at least have to look at
    all the architectures that linux officially exists for.

  11. Re: How does the compiler do with this code?

    2006-12-18 <877iwpl6uq.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    > Josef Moellers wrote:
    >>Nils O. Selåsdal wrote:
    >>> Ronald wrote:
    >>>
    >>>> //it's all
    >>>> int main()
    >>>> {
    >>>> printf("hello\n");
    >>>> }
    >>>>
    >>>> Without ``#include ", it can be compiled, linked and run.
    >>> It then assumes printf takes the amount of argumnets you call
    >>> it with
    >>> of type int,

    >>
    >>In that case, Ronald's usage would be wrong, as he calls it with
    >>a pointer argument.
    >>
    >>IIRC the compiler assumes that the *supplied* arguments are
    >>correct and that the function ...
    >>> and returns an int.

    >>Which is correct, in this case.
    >>
    >>So, effectively, the assumed prototype would be "int
    >>printf(...);" (though I'm not sure if this is indeed a
    >>syntacally correct).

    >
    > Actually it would be assumed to be
    >
    > int printf( const char * restrict format, ... );


    That's the _actual_ prototype.

    The assumed prototype would be int printf(char *x); or an assumed
    declaration of int printf();

    The point is that the one it assumes is, in fact, incorrect, due to the
    lack of stdio.h

  12. Re: How does the compiler do with this code?

    Josef Moellers wrote:
    >>>>>So, effectively, the assumed prototype would be "int
    >>>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>>syntacally correct).
    >>>>
    >>>>Actually it would be assumed to be
    >>>> int printf( const char * restrict format, ... );
    >>>
    >>>How can it assume the first argument if "stdio.h" was not
    >>>included (that was the OP's question!)?

    >> Because that is the way the function is *defined*, it *is*
    >> going
    >> to assume the first argument is a format string. Of course if
    >> it is not, having a prototype in scope when it is compiled
    >> might, depending on the compiler, allow the compiler to catch
    >> the fact that it isn't (or that the number of arguments and
    >> their type to not match the format string). If there is no
    >> prototype, then the arguments are passed as is to the printf()
    >> function and they either work or they don't...

    >
    >??? Who/What is "it" as in "it *is* going to assume"?


    The printf function is going to assume that the parameter list
    consists of a format string and then a series of arguments
    specified by the format string:

    int printf( const char * restrict format, ... );

    >Ronald was asking about *calling* printf() (he even gave a code snippet).


    Ronald asked why "it can be compiled, linked and run."

    >If the compiler which compiles the *call* to printf() has no
    >prototype of printf() handy, how does it (i.e. the compiler
    >which compiles the *call* to printf()) know that the first
    >argument is expected to be a "const char *"?


    If you mean simply the preprocessor and the code generator
    stages, they don't know, and don't need to know in order for the
    program to compile, link, and run. The only unique purpose the
    prototype serves in those stages is for error checking, which is
    not mandatory. (A non-unique purpose is as a declaration, but
    that can be accomplished in other ways, as in the example
    cited.)

    >In the absence of a
    >prototype of printf() it will pass the arguments as they are
    >given (maybe converting the odd float into a double) and hope
    >for the best.


    And maybe converting arrays into pointers too, but that is not
    pertinent to the OP's question.

    The compiler is going to assume the arguments are correct. The
    correct arguments are as I described above. There need not be
    any error checking, and if the program is compiled, linked and
    run it will either work when they are correct, or fail in some
    way when they are not.

    >When compiling printf() itself, I don't see how compiling it
    >without knowing what its first argument is going to be would
    >work.


    As I said, the definition of printf is where the arguments are
    "known". Whatever actually is passed *is* going to be treated
    as per the definition, even if the passed arguments are not
    correct.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  13. Re: How does the compiler do with this code?

    Random832 wrote:
    >2006-12-18 <877iwpl6uq.fld@apaflo.com>,
    >Floyd L. Davidson wrote:
    >> Josef Moellers wrote:
    >>>Nils O. Selåsdal wrote:
    >>>> Ronald wrote:
    >>>>
    >>>>> //it's all
    >>>>> int main()
    >>>>> {
    >>>>> printf("hello\n");
    >>>>> }
    >>>>>
    >>>>> Without ``#include ", it can be compiled, linked and run.
    >>>> It then assumes printf takes the amount of argumnets you call
    >>>> it with
    >>>> of type int,
    >>>
    >>>In that case, Ronald's usage would be wrong, as he calls it with
    >>>a pointer argument.
    >>>
    >>>IIRC the compiler assumes that the *supplied* arguments are
    >>>correct and that the function ...
    >>>> and returns an int.
    >>>Which is correct, in this case.
    >>>
    >>>So, effectively, the assumed prototype would be "int
    >>>printf(...);" (though I'm not sure if this is indeed a
    >>>syntacally correct).

    >>
    >> Actually it would be assumed to be
    >>
    >> int printf( const char * restrict format, ... );

    >
    >That's the _actual_ prototype.
    >
    >The assumed prototype would be int printf(char *x);


    There is no reason it would assume that prototype.

    >or an assumed
    >declaration of int printf();


    That is correct.

    >The point is that the one it assumes is, in fact, incorrect, due to the
    >lack of stdio.h


    It doesn't assume anything other than that the *correct*
    arguments have been passed. Hence, it is "assuming" the actual
    prototype.

    What it is *not* doing is *anything* with that prototype, other
    than assuming it is correct and passing the parameter list to
    the printf function.

    (It appears we might argue over the right words to describe it
    for a week, but we are both *thinking* the same thing.)

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  14. Re: How does the compiler do with this code?

    Floyd L. Davidson wrote:
    > Josef Moellers wrote:
    >
    >>>>>>So, effectively, the assumed prototype would be "int
    >>>>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>>>syntacally correct).
    >>>>>
    >>>>>Actually it would be assumed to be
    >>>>> int printf( const char * restrict format, ... );
    >>>>
    >>>>How can it assume the first argument if "stdio.h" was not
    >>>>included (that was the OP's question!)?
    >>>
    >>>Because that is the way the function is *defined*, it *is*
    >>>going
    >>>to assume the first argument is a format string. Of course if
    >>>it is not, having a prototype in scope when it is compiled
    >>>might, depending on the compiler, allow the compiler to catch
    >>>the fact that it isn't (or that the number of arguments and
    >>>their type to not match the format string). If there is no
    >>>prototype, then the arguments are passed as is to the printf()
    >>>function and they either work or they don't...

    >>
    >>??? Who/What is "it" as in "it *is* going to assume"?

    >
    >
    > The printf function is going to assume that the parameter list
    > consists of a format string and then a series of arguments
    > specified by the format string:
    >
    > int printf( const char * restrict format, ... );


    Yes, that's when compiling the printf function for includion into the libc.

    >>Ronald was asking about *calling* printf() (he even gave a code snippet).

    >
    >
    > Ronald asked why "it can be compiled, linked and run."


    A program which calls printf from the libc.

    >>If the compiler which compiles the *call* to printf() has no
    >>prototype of printf() handy, how does it (i.e. the compiler
    >>which compiles the *call* to printf()) know that the first
    >>argument is expected to be a "const char *"?

    >
    >
    > If you mean simply the preprocessor and the code generator
    > stages, they don't know, and don't need to know in order for the
    > program to compile, link, and run. The only unique purpose the
    > prototype serves in those stages is for error checking, which is
    > not mandatory. (A non-unique purpose is as a declaration, but
    > that can be accomplished in other ways, as in the example
    > cited.)


    Beg to differ.

    When I compile the following program

    # include

    int f(double f); /* <<<<<<<< */

    int
    main(int argc, char *argv[])
    {
    unsigned long long int i = 5;

    f(i);
    }

    int
    f(double f)
    {
    printf("%f\n", f);
    }

    When compiled as given, "i" is converted to double and "5.000000" is
    output. If the marked line is removed, "0.000000" is output.

    > The compiler is going to assume the arguments are correct. The
    > correct arguments are as I described above. There need not be
    > any error checking, and if the program is compiled, linked and
    > run it will either work when they are correct, or fail in some
    > way when they are not.


    ACK.

    >>When compiling printf() itself, I don't see how compiling it
    >>without knowing what its first argument is going to be would
    >>work.

    >
    >
    > As I said, the definition of printf is where the arguments are
    > "known". Whatever actually is passed *is* going to be treated
    > as per the definition, even if the passed arguments are not
    > correct.


    OK.

    Josef

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  15. Re: How does the compiler do with this code?

    Josef Moellers wrote:
    >Floyd L. Davidson wrote:
    >>>
    >>>??? Who/What is "it" as in "it *is* going to assume"?

    >> The printf function is going to assume that the parameter list
    >> consists of a format string and then a series of arguments
    >> specified by the format string:
    >> int printf( const char * restrict format, ... );

    >
    >Yes, that's when compiling the printf function for includion into the libc.


    That is when the compiler outputs any code linked to libc and
    calls the printf function. The definition of the function is
    assuming that the arguments it receives are as indicated, and
    operates on them as if that is true.

    >>>Ronald was asking about *calling* printf() (he even gave a code snippet).

    >> Ronald asked why "it can be compiled, linked and run."

    >
    >A program which calls printf from the libc.
    >
    >>>If the compiler which compiles the *call* to printf() has no
    >>>prototype of printf() handy, how does it (i.e. the compiler
    >>>which compiles the *call* to printf()) know that the first
    >>>argument is expected to be a "const char *"?

    >> If you mean simply the preprocessor and the code generator
    >> stages, they don't know, and don't need to know in order for the
    >> program to compile, link, and run. The only unique purpose the
    >> prototype serves in those stages is for error checking, which is
    >> not mandatory. (A non-unique purpose is as a declaration, but
    >> that can be accomplished in other ways, as in the example
    >> cited.)

    >
    >Beg to differ.
    >
    >When I compile the following program


    The above is in reference specifically to the code example
    given, which is calling a function with variable arguments.
    Your example is not the same.

    Here is a discussion from the 1999 C Standard:

    6.5.2.2 Function calls
    Constraints
    ...
    Semantics

    7 If the expression that denotes the called function has a
    type that does include a prototype, the arguments are
    implicitly converted, as if by assignment, to the types of
    the corresponding parameters, taking the type of each
    parameter to be the unqualified version of its declared
    type. The ellipsis notation in a function prototype
    declarator causes argument type conversion to stop after the
    last declared parameter. The default argument promotions are
    performed on trailing arguments.

    8 No other conversions are performed implicitly; in
    particular, the number and types of arguments are not
    compared with those of the parameters in a function
    definition that does not include a function prototype
    declarator.

    The only argument that is examined for promotion due to the
    prototype for printf is the first argument, which is followed by
    an ellipsis that causes only default promotions for the trailing
    arguments.


    ># include
    >
    >int f(double f); /* <<<<<<<< */
    >
    >int
    >main(int argc, char *argv[])
    >{
    > unsigned long long int i = 5;
    >
    > f(i);
    >}
    >
    >int
    >f(double f)
    >{
    > printf("%f\n", f);
    >}
    >
    >When compiled as given, "i" is converted to double and
    >"5.000000" is output. If the marked line is removed, "0.000000"
    >is output.
    >
    >> The compiler is going to assume the arguments are correct. The
    >> correct arguments are as I described above. There need not be
    >> any error checking, and if the program is compiled, linked and
    >> run it will either work when they are correct, or fail in some
    >> way when they are not.

    >
    >ACK.


    ?? (I'm not sure what that means.)

    >>>When compiling printf() itself, I don't see how compiling it
    >>>without knowing what its first argument is going to be would
    >>>work.

    >> As I said, the definition of printf is where the arguments are
    >> "known". Whatever actually is passed *is* going to be treated
    >> as per the definition, even if the passed arguments are not
    >> correct.

    >
    >OK.



    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  16. Re: How does the compiler do with this code?

    2006-12-18 <87tzztjkwo.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    > Random832 wrote:
    >>2006-12-18 <877iwpl6uq.fld@apaflo.com>,
    >>Floyd L. Davidson wrote:
    >>> Josef Moellers wrote:
    >>>>Nils O. Selåsdal wrote:
    >>>>> Ronald wrote:
    >>>>>
    >>>>>> //it's all
    >>>>>> int main()
    >>>>>> {
    >>>>>> printf("hello\n");
    >>>>>> }
    >>>>>>
    >>>>>> Without ``#include ", it can be compiled, linked and run.
    >>>>> It then assumes printf takes the amount of argumnets you call
    >>>>> it with
    >>>>> of type int,
    >>>>
    >>>>In that case, Ronald's usage would be wrong, as he calls it with
    >>>>a pointer argument.
    >>>>
    >>>>IIRC the compiler assumes that the *supplied* arguments are
    >>>>correct and that the function ...
    >>>>> and returns an int.
    >>>>Which is correct, in this case.
    >>>>
    >>>>So, effectively, the assumed prototype would be "int
    >>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>syntacally correct).
    >>>
    >>> Actually it would be assumed to be
    >>>
    >>> int printf( const char * restrict format, ... );

    >>
    >>That's the _actual_ prototype.
    >>
    >>The assumed prototype would be int printf(char *x);

    >
    > There is no reason it would assume that prototype.
    >
    >>or an assumed
    >>declaration of int printf();

    >
    > That is correct.


    If you call int printf(); with a single argument of type char *, the
    call will be the same as if there had been a declaration
    int printf(char *); - that's all I was saying.

    And my statement was closer to the truth than yours, which incorrectly
    claimed that it would make a correct assumption.

    >
    >>The point is that the one it assumes is, in fact, incorrect, due to the
    >>lack of stdio.h

    >
    > It doesn't assume anything other than that the *correct*
    > arguments have been passed. Hence, it is "assuming" the actual
    > prototype.


    No, it is assuming a prototype for which the arguments that were passed
    would be correct. It is, in particular, not assuming that there is any
    kind of "..." in the prototype. The fact that there, in fact, ought to
    be a "..." means that it will screw up by not knowing about it.

    > What it is *not* doing is *anything* with that prototype, other
    > than assuming it is correct and passing the parameter list to
    > the printf function.


    Right. It is assuming that the prototype [declaration, really] int
    printf() is correct. It is NOT assuming that the prototype is int
    printf(const char *, ...); - that would be a correct assumption, and it
    is not one that is being made.

    > (It appears we might argue over the right words to describe it
    > for a week, but we are both *thinking* the same thing.)


    I have absolutely no idea how what I am thinking can possibly be
    expressed by a reasonable person with these words:

    >>> Actually it would be assumed to be
    >>>
    >>> int printf( const char * restrict format, ... );


    If, as I suspect, you don't actually believe that, it would be better to
    plead temporary inanity than to claim that those words somehow mean
    something that is true. [1]

    [1] Added emoticon so you don't think i'm trying to insult you

  17. Re: How does the compiler do with this code?

    2006-12-18 <87y7p5jlh3.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    > Josef Moellers wrote:
    >>>>>>So, effectively, the assumed prototype would be "int
    >>>>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>>>syntacally correct).
    >>>>>
    >>>>>Actually it would be assumed to be
    >>>>> int printf( const char * restrict format, ... );
    >>>>
    >>>>How can it assume the first argument if "stdio.h" was not
    >>>>included (that was the OP's question!)?
    >>> Because that is the way the function is *defined*, it *is*
    >>> going
    >>> to assume the first argument is a format string. Of course if
    >>> it is not, having a prototype in scope when it is compiled
    >>> might, depending on the compiler, allow the compiler to catch
    >>> the fact that it isn't (or that the number of arguments and
    >>> their type to not match the format string). If there is no
    >>> prototype, then the arguments are passed as is to the printf()
    >>> function and they either work or they don't...

    >>
    >>??? Who/What is "it" as in "it *is* going to assume"?

    >
    > The printf function is going to assume that the parameter list
    > consists of a format string and then a series of arguments
    > specified by the format string:
    >
    > int printf( const char * restrict format, ... );


    We were previously talking about what the compiler would assume in its
    interpretation of the code that calls printf with no prototype, not what
    printf would assume. printf, at link time, knows nothing about
    prototypes or calling conventions or anything. I think it was clear from
    context at the time that this is what he meant when he said:

    >>>>>>So, effectively, the assumed prototype would be "int
    >>>>>>printf(...);"


    Now, to answer the original question: On i386 linux, the calling
    convention is the same for variable arguments vs fixed arguments. This
    is not the case on other architectures, so the code might not work
    anywhere else.

  18. Re: How does the compiler do with this code?

    Random832 wrote:
    >2006-12-18 <87tzztjkwo.fld@apaflo.com>,
    >Floyd L. Davidson wrote:
    >> Random832 wrote:
    >>>2006-12-18 <877iwpl6uq.fld@apaflo.com>,
    >>>Floyd L. Davidson wrote:
    >>>> Josef Moellers wrote:
    >>>>>Nils O. Selåsdal wrote:
    >>>>>> Ronald wrote:
    >>>>>>
    >>>>>>> //it's all
    >>>>>>> int main()
    >>>>>>> {
    >>>>>>> printf("hello\n");
    >>>>>>> }
    >>>>>>>
    >>>>>>> Without ``#include ", it can be compiled, linked and run.
    >>>>>> It then assumes printf takes the amount of argumnets you call
    >>>>>> it with
    >>>>>> of type int,
    >>>>>
    >>>>>In that case, Ronald's usage would be wrong, as he calls it with
    >>>>>a pointer argument.
    >>>>>
    >>>>>IIRC the compiler assumes that the *supplied* arguments are
    >>>>>correct and that the function ...
    >>>>>> and returns an int.
    >>>>>Which is correct, in this case.
    >>>>>
    >>>>>So, effectively, the assumed prototype would be "int
    >>>>>printf(...);" (though I'm not sure if this is indeed a
    >>>>>syntacally correct).
    >>>>
    >>>> Actually it would be assumed to be
    >>>>
    >>>> int printf( const char * restrict format, ... );
    >>>
    >>>That's the _actual_ prototype.
    >>>
    >>>The assumed prototype would be int printf(char *x);

    >>
    >> There is no reason it would assume that prototype.
    >>
    >>>or an assumed
    >>>declaration of int printf();

    >>
    >> That is correct.

    >
    >If you call int printf(); with a single argument of type char *, the
    >call will be the same as if there had been a declaration
    >int printf(char *); - that's all I was saying.


    It will be the same as if there had been a declaration of

    int printf(const char * restrict, ...);

    >And my statement was closer to the truth than yours, which incorrectly
    >claimed that it would make a correct assumption.
    >>
    >>>The point is that the one it assumes is, in fact, incorrect, due to the
    >>>lack of stdio.h

    >>
    >> It doesn't assume anything other than that the *correct*
    >> arguments have been passed. Hence, it is "assuming" the actual
    >> prototype.

    >
    >No, it is assuming a prototype for which the arguments that were passed
    >would be correct. It is, in particular, not assuming that there is any
    >kind of "..." in the prototype. The fact that there, in fact, ought to
    >be a "..." means that it will screw up by not knowing about it.


    The effect is the same if it is there, or not. It will *not* "screw up
    by not knowing about it".

    >> What it is *not* doing is *anything* with that prototype, other
    >> than assuming it is correct and passing the parameter list to
    >> the printf function.

    >
    >Right. It is assuming that the prototype [declaration, really] int
    >printf() is correct. It is NOT assuming that the prototype is int
    >printf(const char *, ...); - that would be a correct assumption, and it
    >is not one that is being made.


    No prototype and using the elipse result in the same action: The
    compiler will stop doing parameter promotions according to the
    prototype, and do only the "default promotions".

    >> (It appears we might argue over the right words to describe it
    >> for a week, but we are both *thinking* the same thing.)

    >
    >I have absolutely no idea how what I am thinking can possibly be
    >expressed by a reasonable person with these words:


    My mistake. Please read the ISO C Standard in regard to how
    function prototypes are used, specificially when it includes an
    elipses (section 6.5.2.2).

    >>>> Actually it would be assumed to be
    >>>>
    >>>> int printf( const char * restrict format, ... );

    >
    >If, as I suspect, you don't actually believe that, it would be better to
    >plead temporary inanity than to claim that those words somehow mean
    >something that is true. [1]
    >
    >[1] Added emoticon so you don't think i'm trying to insult you


    The words are true. The only place where the parameter list is
    expected to conform to any specific prototype will be when the
    arguments are handed to the actual function. *THAT* is what the
    printf function is going to assume.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  19. Re: How does the compiler do with this code?

    Random832 wrote:
    >2006-12-18 <87y7p5jlh3.fld@apaflo.com>,
    >>
    >> The printf function is going to assume that the parameter list
    >> consists of a format string and then a series of arguments
    >> specified by the format string:
    >>
    >> int printf( const char * restrict format, ... );

    >
    >We were previously talking about what the compiler would assume in its


    We were discussing why a snippet of code would *compile*,
    *link*, and *run*.

    >interpretation of the code that calls printf with no prototype, not what
    >printf would assume. printf, at link time, knows nothing about
    >prototypes or calling conventions or anything. I think it was clear from
    >context at the time that this is what he meant when he said:
    >
    >>>>>>>So, effectively, the assumed prototype would be "int
    >>>>>>>printf(...);"

    >
    >Now, to answer the original question: On i386 linux, the calling
    >convention is the same for variable arguments vs fixed arguments. This
    >is not the case on other architectures, so the code might not work
    >anywhere else.


    Can you provide an example.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  20. Re: How does the compiler do with this code?

    2006-12-19 <8764c8kaob.fld@apaflo.com>,
    Floyd L. Davidson wrote:
    >>>>> Actually it would be assumed to be
    >>>>>
    >>>>> int printf( const char * restrict format, ... );

    >>
    >>If, as I suspect, you don't actually believe that, it would be better to
    >>plead temporary inanity than to claim that those words somehow mean
    >>something that is true. [1]
    >>
    >>[1] Added emoticon so you don't think i'm trying to insult you

    >
    > The words are true. The only place where the parameter list is
    > expected to conform to any specific prototype will be when the
    > arguments are handed to the actual function. *THAT* is what the
    > printf function is going to assume.


    WE ARE NOT TALKING ABOUT WHAT THE PRINTF FUNCTION WILL ASSUME! we are
    talking about what the compiler will assume when it sees a call to
    printf. I don't know how I can make this more clear. I don't know how it
    was unclear in the first place. I think you're being deliberately
    obtuse.

    I can't explain this any better than I already have.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast