call of variadic function

Discussion in 'C Programming' started by CryptiqueGuy, Jun 17, 2007.

  1. CryptiqueGuy

    CryptiqueGuy Guest

    Consider the variadic function with the following prototype:
    int foo(int num,...);
    Here 'num' specifies the number of arguments, and assume that all the
    arguments that should be passed to this function are of type int.
    (My question has nothing to do with the definition of the function
    foo, so don't bother about it.)

    If I call the function as:
    foo(2,3,4,5,6,7,8);/*More arguments than expected*/

    Here I call foo with too many arguments than expected by its
    definition.

    Assuming that the prototype is visible in the scope of the function
    call and the definition of function foo itself does NOT produce any
    UB, please tell me if this function call produces UB or not.

    I am not able to find any explicit clause from C99 which deals with
    this behavior.

    Though I find that:

    7.19.6.1 The fprintf function
    The fprintf function writes output to the stream pointed to by stream,
    under control of the string pointed to by format that specifies how
    subsequent arguments are converted for output. If there are
    insufficient arguments for the format, the behavior is undefined. If
    the format is exhausted while arguments remain, the excess arguments
    are evaluated (as always) but are otherwise ignored.

    This is highly specific to fprintf. I wonder if it applies to all
    variadic functions.

    Can I assume that the behavior of this function call is UB by
    ommission?
    Or am I missing something, here?
    Please clarify

    Thanks in advance for reply.
    CryptiqueGuy, Jun 17, 2007
    #1
    1. Advertising

  2. CryptiqueGuy

    Eric Sosman Guest

    CryptiqueGuy wrote:
    > Consider the variadic function with the following prototype:
    > int foo(int num,...);
    > Here 'num' specifies the number of arguments, and assume that all the
    > arguments that should be passed to this function are of type int.
    > (My question has nothing to do with the definition of the function
    > foo, so don't bother about it.)
    >
    > If I call the function as:
    > foo(2,3,4,5,6,7,8);/*More arguments than expected*/
    >
    > Here I call foo with too many arguments than expected by its
    > definition.


    Not really: You call foo with more arguments than are
    expected by its documentation, not by its definition. The
    definition can accommodate any strictly positive number of
    arguments.

    > Assuming that the prototype is visible in the scope of the function
    > call and the definition of function foo itself does NOT produce any
    > UB, please tell me if this function call produces UB or not.


    No UB. The function is not required to "run the va_list
    all the way to the end." It is not even required to initialize
    the va_list at all:

    void foo(int count, ...) {
    if (phaseOfMoon() == FULL) {
    puts ("Hoooowwwwwllll!");
    }
    else {
    va_list ap;
    va_start(ap, count);
    ...
    va_end(ap);
    }
    }

    > I am not able to find any explicit clause from C99 which deals with
    > this behavior.


    Neither can I, but there are a few passages that seem
    suggestive:

    Footnote 123 to 6.7.5.3p9: "The macros [...] may be
    used to access arguments that correspond to the
    ellipsis." Note the use of the word "may," not
    "must" or "shall." (The latter would be out of
    place in a non-normative footnote anyhow.)

    7.15p3: "[...] If access to the varying arguments
    is desired [...]" Use of <stdarg.h> facilities is
    needed only "if" access is desired, implying that
    access might not be desired, in which case va_xxx
    need not be used at all, in which case the ...
    arguments (if any) would not be retrieved.

    > Though I find that:
    >
    > 7.19.6.1 The fprintf function
    > The fprintf function writes output to the stream pointed to by stream,
    > under control of the string pointed to by format that specifies how
    > subsequent arguments are converted for output. If there are
    > insufficient arguments for the format, the behavior is undefined. If
    > the format is exhausted while arguments remain, the excess arguments
    > are evaluated (as always) but are otherwise ignored.
    >
    > This is highly specific to fprintf. I wonder if it applies to all
    > variadic functions.


    fprintf() gets a special guarantee because even though it
    is a variadic function it might not be implemented with the
    <stdarg.h> mechanisms. Like all the rest of the implementation,
    the library functions need not be written in C, and even if
    written in C they are at liberty to use "magical" constructs
    not available to ordinary code.

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 17, 2007
    #2
    1. Advertising

  3. CryptiqueGuy

    CryptiqueGuy Guest

    On Jun 17, 11:43 pm, Eric Sosman <> wrote:
    > CryptiqueGuy wrote:
    > > Consider the variadic function with the following prototype:
    > > int foo(int num,...);
    > > Here 'num' specifies the number of arguments, and assume that all the
    > > arguments that should be passed to this function are of type int.
    > > (My question has nothing to do with the definition of the function
    > > foo, so don't bother about it.)

    >
    > > If I call the function as:
    > > foo(2,3,4,5,6,7,8);/*More arguments than expected*/

    >
    > > Here I call foo with too many arguments than expected by its
    > > definition.

    >
    > Not really: You call foo with more arguments than are
    > expected by its documentation, not by its definition.


    >The definition can accommodate any strictly positive number of
    > arguments.


    Can you elaborate, on the last sentence of yours?

    >
    > > Assuming that the prototype is visible in the scope of the function
    > > call and the definition of function foo itself does NOT produce any
    > > UB, please tell me if this function call produces UB or not.

    >
    > No UB.


    This function call might be intended not to produce UB by the
    standards but where is the required specification which makes this
    call well defined?

    >The function is not required to "run the va_list
    > all the way to the end." It is not even required to initialize
    > the va_list at all:


    Yes, I agree that the implementation of the function is very much left
    to its implementer's choice. So the implementer might implement the
    function the way you implemented foo.

    But what is the behavior of the function call:
    foo(1,2,3,); for the following function, assuming that phaseOfMoon()
    returns FULL, so that all the va_start and allies are not executed?

    >
    > void foo(int count, ...) {
    > if (phaseOfMoon() == FULL) {
    > puts ("Hoooowwwwwllll!");
    > }
    > else {
    > va_list ap;
    > va_start(ap, count);
    > ...
    > va_end(ap);
    > }
    > }
    >
    > > I am not able to find any explicit clause from C99 which deals with
    > > this behavior.

    >
    > Neither can I, but there are a few passages that seem
    > suggestive:


    Can this be considered a glitch with the standards?

    >
    > Footnote 123 to 6.7.5.3p9: "The macros [...] may be
    > used to access arguments that correspond to the
    > ellipsis." Note the use of the word "may," not
    > "must" or "shall." (The latter would be out of
    > place in a non-normative footnote anyhow.)


    As you had already specified we can't base our discussions on the
    footnotes.

    >
    > 7.15p3: "[...] If access to the varying arguments
    > is desired [...]" Use of <stdarg.h> facilities is
    > needed only "if" access is desired, implying that
    > access might not be desired, in which case va_xxx
    > need not be used at all, in which case the ...
    > arguments (if any) would not be retrieved.


    Ok, this could be interpreted as, if you want you could use stdarg.h
    which is the standard way to access arguments of a variadic function
    or else go for some compiler specific funtion calls.
    Here the else clause of my sentence specifies one of the numerous non-
    portable way of accessing the arguments.

    So my conclusion is that explicit statement of behavior is definitely
    expected out of the standards when we call a variadic function with
    more number of arguments than expected.
    Absence of explicit statement of the behavior means that it is a UB.
    So the function call I gave in my original post produces UB.

    Now, I want to know where do I go wrong in my interpretation, if the
    function call I gave in my original question is not a UB?
    >
    > > Though I find that:

    >
    > > 7.19.6.1 The fprintf function
    > > The fprintf function writes output to the stream pointed to by stream,
    > > under control of the string pointed to by format that specifies how
    > > subsequent arguments are converted for output. If there are
    > > insufficient arguments for the format, the behavior is undefined. If
    > > the format is exhausted while arguments remain, the excess arguments
    > > are evaluated (as always) but are otherwise ignored.

    >
    > > This is highly specific to fprintf. I wonder if it applies to all
    > > variadic functions.

    >
    > fprintf() gets a special guarantee because even though it
    > is a variadic function it might not be implemented with the
    > <stdarg.h> mechanisms. Like all the rest of the implementation,
    > the library functions need not be written in C, and even if
    > written in C they are at liberty to use "magical" constructs
    > not available to ordinary code.


    This is the thing that keeps me wondering. When an explicit behavior
    is stated for special functions like fprintf and friends, why no
    behavior is said about a generalised variadic function?

    Is an issue like this had already come up in comp.lang.c or
    comp.std.c?

    A final question, not related to this topic.
    Do you think I need to cross post this question at comp.std.c? I think
    that I have a poor response to my question, probably because I chose a
    wrong group for this topic.

    I thank you for replying to my question.
    CryptiqueGuy, Jun 18, 2007
    #3
  4. CryptiqueGuy

    Eric Sosman Guest

    CryptiqueGuy wrote On 06/18/07 12:32,:
    > On Jun 17, 11:43 pm, Eric Sosman <> wrote:
    >
    >>CryptiqueGuy wrote:
    >>
    >>>Consider the variadic function with the following prototype:
    >>>int foo(int num,...);
    >>>Here 'num' specifies the number of arguments, and assume that all the
    >>>arguments that should be passed to this function are of type int.
    >>>(My question has nothing to do with the definition of the function
    >>>foo, so don't bother about it.)

    >>
    >>>If I call the function as:
    >>>foo(2,3,4,5,6,7,8);/*More arguments than expected*/

    >>
    >>>Here I call foo with too many arguments than expected by its
    >>>definition.

    >>
    >> Not really: You call foo with more arguments than are
    >>expected by its documentation, not by its definition.

    >
    >
    >>The definition can accommodate any strictly positive number of
    >>arguments.

    >
    >
    > Can you elaborate, on the last sentence of yours?


    One fixed argument (corresponding to num) plus zero
    or more variable arguments (for `...'). One plus zero or
    more equals one or more, hence "strictly positive."

    >
    >>>Assuming that the prototype is visible in the scope of the function
    >>>call and the definition of function foo itself does NOT produce any
    >>>UB, please tell me if this function call produces UB or not.

    >>
    >> No UB.

    >
    >
    > This function call might be intended not to produce UB by the
    > standards but where is the required specification which makes this
    > call well defined?


    What could be wrong with the call? foo() is declared
    to take one int plus any number of other arguments of any
    (promoted) types at all, so any call you can write is valid
    so long as it has at least one argument and the first is
    convertible to int.

    The call is unimpeachable, so any uncertainty you have
    must be related to what foo() does after it is called. We
    know that it may (if it wants) use <stdarg.h> facilities to
    retrieve the `...' arguments; we know it can retrieve them
    several times if it wants. There is no reason to think that
    it is obliged to retrieve them any particular number of times,
    nor that any particular "pass" over the arguments must run
    all the way through the whole list. We know the behavior
    is undefined if foo() tries to retrieve more arguments than
    are provided, or if it tries to retrieve arguments whose
    type does not agree with the (promoted) expressions in the
    call, and we know the behavior is undefined if a va_start()
    is not matched with a va_end(). But nowhere is it said
    that va_arg() must be called any specific number of times.

    >>The function is not required to "run the va_list
    >>all the way to the end." It is not even required to initialize
    >>the va_list at all:

    >
    >
    > Yes, I agree that the implementation of the function is very much left
    > to its implementer's choice. So the implementer might implement the
    > function the way you implemented foo.
    >
    > But what is the behavior of the function call:
    > foo(1,2,3,); for the following function, assuming that phaseOfMoon()
    > returns FULL, so that all the va_start and allies are not executed?


    As shown, the behavior is "diagnostic required" followed
    by whatever the compiler chooses to do next. Without the
    extraneous comma, foo writes "Hoooowwwwwllll!\n" to stdout
    and returns, doing nothing else.

    >
    >> void foo(int count, ...) {
    >> if (phaseOfMoon() == FULL) {
    >> puts ("Hoooowwwwwllll!");
    >> }
    >> else {
    >> va_list ap;
    >> va_start(ap, count);
    >> ...
    >> va_end(ap);
    >> }
    >> }
    >>
    >>
    >>>I am not able to find any explicit clause from C99 which deals with
    >>>this behavior.

    >>
    >> Neither can I, but there are a few passages that seem
    >>suggestive:

    >
    > Can this be considered a glitch with the standards?
    >
    >> Footnote 123 to 6.7.5.3p9: "The macros [...] may be
    >> used to access arguments that correspond to the
    >> ellipsis." Note the use of the word "may," not
    >> "must" or "shall." (The latter would be out of
    >> place in a non-normative footnote anyhow.)

    >
    >
    > As you had already specified we can't base our discussions on the
    > footnotes.
    >
    >
    >> 7.15p3: "[...] If access to the varying arguments
    >> is desired [...]" Use of <stdarg.h> facilities is
    >> needed only "if" access is desired, implying that
    >> access might not be desired, in which case va_xxx
    >> need not be used at all, in which case the ...
    >> arguments (if any) would not be retrieved.

    >
    >
    > Ok, this could be interpreted as, if you want you could use stdarg.h
    > which is the standard way to access arguments of a variadic function
    > or else go for some compiler specific funtion calls.
    > Here the else clause of my sentence specifies one of the numerous non-
    > portable way of accessing the arguments.
    >
    > So my conclusion is that explicit statement of behavior is definitely
    > expected out of the standards when we call a variadic function with
    > more number of arguments than expected.


    The function "expects" any strictly positive number of
    arguments; that's what its definition says. What it then
    decides to do with those arguments is its own business; it
    is not required to "pay attention" to every one of them.

    Let's try to simplify things by considering a (perhaps)
    more transparent function:

    int choose(int x, int y) {
    return x;
    }

    Do you think this function invokes undefined behavior? It
    uses only one of its two arguments, ignoring the other. Does
    the Standard explicitly allow choose() to ignore `y'? Do
    you think it needs to?

    > Absence of explicit statement of the behavior means that it is a UB.
    > So the function call I gave in my original post produces UB.


    Does the Standard state explictly that it is permissible
    to arrange the cases of a switch in descending order? Does
    the Standard state explicitly that it is permissible to write
    a statement label and never use it in a goto?

    > Now, I want to know where do I go wrong in my interpretation, if the
    > function call I gave in my original question is not a UB?
    >
    >>>Though I find that:

    >>
    >>>7.19.6.1 The fprintf function
    >>>The fprintf function writes output to the stream pointed to by stream,
    >>>under control of the string pointed to by format that specifies how
    >>>subsequent arguments are converted for output. If there are
    >>>insufficient arguments for the format, the behavior is undefined. If
    >>>the format is exhausted while arguments remain, the excess arguments
    >>>are evaluated (as always) but are otherwise ignored.

    >>
    >>>This is highly specific to fprintf. I wonder if it applies to all
    >>>variadic functions.

    >>
    >> fprintf() gets a special guarantee because even though it
    >>is a variadic function it might not be implemented with the
    >><stdarg.h> mechanisms. Like all the rest of the implementation,
    >>the library functions need not be written in C, and even if
    >>written in C they are at liberty to use "magical" constructs
    >>not available to ordinary code.

    >
    >
    > This is the thing that keeps me wondering. When an explicit behavior
    > is stated for special functions like fprintf and friends, why no
    > behavior is said about a generalised variadic function?
    >
    > Is an issue like this had already come up in comp.lang.c or
    > comp.std.c?
    >
    > A final question, not related to this topic.
    > Do you think I need to cross post this question at comp.std.c? I think
    > that I have a poor response to my question, probably because I chose a
    > wrong group for this topic.


    Since your question is about the interpretation of the
    meaning of the Standard, I think it would be on-topic for
    c.s.c. (I also think you'll get the same answer I've given
    you -- but you already know that's what I think ;-)

    --
    Eric Sosman, Jun 18, 2007
    #4
  5. On Mon, 18 Jun 2007 16:32:04 -0000, CryptiqueGuy
    <> wrote:

    >On Jun 17, 11:43 pm, Eric Sosman <> wrote:
    >> CryptiqueGuy wrote:
    >> > Consider the variadic function with the following prototype:
    >> > int foo(int num,...);
    >> > Here 'num' specifies the number of arguments, and assume that all the
    >> > arguments that should be passed to this function are of type int.
    >> > (My question has nothing to do with the definition of the function
    >> > foo, so don't bother about it.)

    >>
    >> > If I call the function as:
    >> > foo(2,3,4,5,6,7,8);/*More arguments than expected*/

    >>
    >> > Here I call foo with too many arguments than expected by its
    >> > definition.

    >>
    >> Not really: You call foo with more arguments than are
    >> expected by its documentation, not by its definition.

    >
    >>The definition can accommodate any strictly positive number of
    >> arguments.

    >
    >Can you elaborate, on the last sentence of yours?


    foo can be called with 1 argument, with 2 arguments, ..., with any
    positive number of arguments up to the implementation limit for
    quantity of arguments.


    Remove del for email
    Barry Schwarz, Jun 18, 2007
    #5
  6. CryptiqueGuy

    Army1987 Guest

    "Eric Sosman" <> ha scritto nel messaggio
    news:1182188575.394182@news1nwk...
    > CryptiqueGuy wrote On 06/18/07 12:32,:


    [asking wheter calling a variadic function with more arguments that
    it uses is UB]

    >> Absence of explicit statement of the behavior means that it is a UB.
    >> So the function call I gave in my original post produces UB.

    >
    > Does the Standard state explictly that it is permissible
    > to arrange the cases of a switch in descending order? Does
    > the Standard state explicitly that it is permissible to write
    > a statement label and never use it in a goto?


    It doesn't even say that the function call
    #include <stdio.h>
    #include <string.h>
    memset(stdout, 11, sizeof(FILE));

    can cause UB. But I wouldn't expect a program to continue working
    after it.
    Army1987, Jun 19, 2007
    #6
  7. CryptiqueGuy

    CryptiqueGuy Guest

    On Jun 18, 10:42 pm, Eric Sosman <> wrote:
    > CryptiqueGuy wrote On 06/18/07 12:32,:
    >
    >
    >
    >
    >
    > > On Jun 17, 11:43 pm, Eric Sosman <> wrote:

    >
    > >>CryptiqueGuy wrote:

    >
    > >>>Consider the variadic function with the following prototype:
    > >>>int foo(int num,...);
    > >>>Here 'num' specifies the number of arguments, and assume that all the
    > >>>arguments that should be passed to this function are of type int.
    > >>>(My question has nothing to do with the definition of the function
    > >>>foo, so don't bother about it.)

    >
    > >>>If I call the function as:
    > >>>foo(2,3,4,5,6,7,8);/*More arguments than expected*/

    >
    > >>>Here I call foo with too many arguments than expected by its
    > >>>definition.

    >
    > >> Not really: You call foo with more arguments than are
    > >>expected by its documentation, not by its definition.

    >
    > >>The definition can accommodate any strictly positive number of
    > >>arguments.

    >
    > > Can you elaborate, on the last sentence of yours?

    >
    > One fixed argument (corresponding to num) plus zero
    > or more variable arguments (for `...'). One plus zero or
    > more equals one or more, hence "strictly positive."


    Well, I can't think like that because I thought this specific function
    call I gave is UB.
    Now the problem is resolved. I agree with your statement.

    >
    >
    >
    > >>>Assuming that the prototype is visible in the scope of the function
    > >>>call and the definition of function foo itself does NOT produce any
    > >>>UB, please tell me if this function call produces UB or not.

    >
    > >> No UB.

    >
    > > This function call might be intended not to produce UB by the
    > > standards but where is the required specification which makes this
    > > call well defined?

    >
    > What could be wrong with the call? foo() is declared
    > to take one int plus any number of other arguments of any
    > (promoted) types at all, so any call you can write is valid
    > so long as it has at least one argument and the first is
    > convertible to int.
    >
    > The call is unimpeachable, so any uncertainty you have
    > must be related to what foo() does after it is called. We
    > know that it may (if it wants) use <stdarg.h> facilities to
    > retrieve the `...' arguments; we know it can retrieve them
    > several times if it wants. There is no reason to think that
    > it is obliged to retrieve them any particular number of times,
    > nor that any particular "pass" over the arguments must run
    > all the way through the whole list. We know the behavior
    > is undefined if foo() tries to retrieve more arguments than
    > are provided, or if it tries to retrieve arguments whose
    > type does not agree with the (promoted) expressions in the
    > call, and we know the behavior is undefined if a va_start()
    > is not matched with a va_end(). But nowhere is it said
    > that va_arg() must be called any specific number of times.
    >
    > >>The function is not required to "run the va_list
    > >>all the way to the end." It is not even required to initialize
    > >>the va_list at all:

    >
    > > Yes, I agree that the implementation of the function is very much left
    > > to its implementer's choice. So the implementer might implement the
    > > function the way you implemented foo.

    >
    > > But what is the behavior of the function call:
    > > foo(1,2,3,); for the following function, assuming that phaseOfMoon()
    > > returns FULL, so that all the va_start and allies are not executed?

    >
    > As shown, the behavior is "diagnostic required" followed
    > by whatever the compiler chooses to do next. Without the
    > extraneous comma, foo writes "Hoooowwwwwllll!\n" to stdout
    > and returns, doing nothing else.


    oops, I have not noticed that comma! It was a typographic error.
    Anyway, you are right in stating that compiler will have to generate
    diagnostic.

    >
    >
    >
    >
    >
    >
    >
    > >> void foo(int count, ...) {
    > >> if (phaseOfMoon() == FULL) {
    > >> puts ("Hoooowwwwwllll!");
    > >> }
    > >> else {
    > >> va_list ap;
    > >> va_start(ap, count);
    > >> ...
    > >> va_end(ap);
    > >> }
    > >> }

    >
    > >>>I am not able to find any explicit clause from C99 which deals with
    > >>>this behavior.

    >
    > >> Neither can I, but there are a few passages that seem
    > >>suggestive:

    >
    > > Can this be considered a glitch with the standards?

    >
    > >> Footnote 123 to 6.7.5.3p9: "The macros [...] may be
    > >> used to access arguments that correspond to the
    > >> ellipsis." Note the use of the word "may," not
    > >> "must" or "shall." (The latter would be out of
    > >> place in a non-normative footnote anyhow.)

    >
    > > As you had already specified we can't base our discussions on the
    > > footnotes.

    >
    > >> 7.15p3: "[...] If access to the varying arguments
    > >> is desired [...]" Use of <stdarg.h> facilities is
    > >> needed only "if" access is desired, implying that
    > >> access might not be desired, in which case va_xxx
    > >> need not be used at all, in which case the ...
    > >> arguments (if any) would not be retrieved.

    >
    > > Ok, this could be interpreted as, if you want you could use stdarg.h
    > > which is the standard way to access arguments of a variadic function
    > > or else go for some compiler specific funtion calls.
    > > Here the else clause of my sentence specifies one of the numerous non-
    > > portable way of accessing the arguments.

    >
    > > So my conclusion is that explicit statement of behavior is definitely
    > > expected out of the standards when we call a variadic function with
    > > more number of arguments than expected.

    >
    > The function "expects" any strictly positive number of
    > arguments; that's what its definition says. What it then
    > decides to do with those arguments is its own business; it
    > is not required to "pay attention" to every one of them.
    >
    > Let's try to simplify things by considering a (perhaps)
    > more transparent function:
    >
    > int choose(int x, int y) {
    > return x;
    > }
    >
    > Do you think this function invokes undefined behavior? It
    > uses only one of its two arguments, ignoring the other. Does
    > the Standard explicitly allow choose() to ignore `y'? Do
    > you think it needs to?
    >
    > > Absence of explicit statement of the behavior means that it is a UB.
    > > So the function call I gave in my original post produces UB.

    >
    > Does the Standard state explictly that it is permissible
    > to arrange the cases of a switch in descending order? Does
    > the Standard state explicitly that it is permissible to write
    > a statement label and never use it in a goto?


    Your argument makes sense to me. It is quite convincing. Now the issue
    has become psychological!
    I *thought* that, passing more arguments, which is not read by the
    variadic function using va_start et al or using some compiler specific
    way, is as bad as dereferencing a null pointer. So the entire problem
    was with my biased perception of this issue.

    Now, I am convinced that it isn't UB.
    Thank you very much for your cogent explanations.

    >
    >
    >
    >
    >
    > > Now, I want to know where do I go wrong in my interpretation, if the
    > > function call I gave in my original question is not a UB?

    >
    > >>>Though I find that:

    >
    > >>>7.19.6.1 The fprintf function
    > >>>The fprintf function writes output to the stream pointed to by stream,
    > >>>under control of the string pointed to by format that specifies how
    > >>>subsequent arguments are converted for output. If there are
    > >>>insufficient arguments for the format, the behavior is undefined. If
    > >>>the format is exhausted while arguments remain, the excess arguments
    > >>>are evaluated (as always) but are otherwise ignored.

    >
    > >>>This is highly specific to fprintf. I wonder if it applies to all
    > >>>variadic functions.

    >
    > >> fprintf() gets a special guarantee because even though it
    > >>is a variadic function it might not be implemented with the
    > >><stdarg.h> mechanisms. Like all the rest of the implementation,
    > >>the library functions need not be written in C, and even if
    > >>written in C they are at liberty to use "magical" constructs
    > >>not available to ordinary code.

    >
    > > This is the thing that keeps me wondering. When an explicit behavior
    > > is stated for special functions like fprintf and friends, why no
    > > behavior is said about a generalised variadic function?

    >
    > > Is an issue like this had already come up in comp.lang.c or
    > > comp.std.c?

    >
    > > A final question, not related to this topic.
    > > Do you think I need to cross post this question at comp.std.c? I think
    > > that I have a poor response to my question, probably because I chose a
    > > wrong group for this topic.

    >
    > Since your question is about the interpretation of the
    > meaning of the Standard, I think it would be on-topic for
    > c.s.c. (I also think you'll get the same answer I've given
    > you -- but you already know that's what I think ;-)
    CryptiqueGuy, Jun 19, 2007
    #7
  8. CryptiqueGuy

    CryptiqueGuy Guest

    On Jun 19, 6:30 pm, "Army1987" <> wrote:
    > "Eric Sosman" <> ha scritto nel messaggionews:1182188575.394182@news1nwk...
    >
    > > CryptiqueGuy wrote On 06/18/07 12:32,:

    >
    > [asking wheter calling a variadic function with more arguments that
    > it uses is UB]
    >
    > >> Absence of explicit statement of the behavior means that it is a UB.
    > >> So the function call I gave in my original post produces UB.

    >
    > > Does the Standard state explictly that it is permissible
    > > to arrange the cases of a switch in descending order? Does
    > > the Standard state explicitly that it is permissible to write
    > > a statement label and never use it in a goto?

    >
    > It doesn't even say that the function call
    > #include <stdio.h>
    > #include <string.h>
    > memset(stdout, 11, sizeof(FILE));
    >
    > can cause UB. But I wouldn't expect a program to continue working
    > after it.


    I think you are stating that subsequent usage of stdout either
    explicitly (using fprintf,fputc etc.) or implicitly (using printf,
    putc etc.) produces UB.
    Agreed, that it is a UB, if there is any usage of stdout.
    But there won't be any if you don't use it.

    The standards do state that subsequent usage of stdout produces UB!
    Well, if you ask me how, here I give my explanation.
    Functions like fprintf uses FILE pointer to do their job. So there
    will be dereferencing of the FILE pointer in their function call. In
    such a case if dereferencing is done on the pointer that does not
    point to a *valid* object, this produces UB. This applies to your case
    also.

    If your library function does not dereference FILE pointer or doesn't
    use it at all for any pointer arithmetics (in that case it should be
    using some complex mechanism!), then there will be no UB. But I think
    such implementations are highly unlikely though not disallowed.
    CryptiqueGuy, Jun 19, 2007
    #8
  9. CryptiqueGuy

    CryptiqueGuy Guest

    On Jun 19, 9:29 pm, CryptiqueGuy <> wrote:
    > On Jun 19, 6:30 pm, "Army1987" <> wrote:
    >
    >
    >
    >
    >
    > > "Eric Sosman" <> ha scritto nel messaggionews:1182188575.394182@news1nwk...

    >
    > > > CryptiqueGuy wrote On 06/18/07 12:32,:

    >
    > > [asking wheter calling a variadic function with more arguments that
    > > it uses is UB]

    >
    > > >> Absence of explicit statement of the behavior means that it is a UB.
    > > >> So the function call I gave in my original post produces UB.

    >
    > > > Does the Standard state explictly that it is permissible
    > > > to arrange the cases of a switch in descending order? Does
    > > > the Standard state explicitly that it is permissible to write
    > > > a statement label and never use it in a goto?

    >
    > > It doesn't even say that the function call
    > > #include <stdio.h>
    > > #include <string.h>
    > > memset(stdout, 11, sizeof(FILE));

    >
    > > can cause UB. But I wouldn't expect a program to continue working
    > > after it.

    > I think you are stating that subsequent usage of stdout either
    > explicitly (using fprintf,fputc etc.) or implicitly (using printf,


    > putc etc.) produces UB.



    I meant putchar. Sorry.
    CryptiqueGuy, Jun 19, 2007
    #9
  10. CryptiqueGuy

    Army1987 Guest

    "CryptiqueGuy" <> ha scritto nel messaggio news:...
    > On Jun 19, 6:30 pm, "Army1987" <> wrote:
    >> "Eric Sosman" <> ha scritto nel messaggionews:1182188575.394182@news1nwk...
    >>
    >> > CryptiqueGuy wrote On 06/18/07 12:32,:

    >>
    >> [asking wheter calling a variadic function with more arguments that
    >> it uses is UB]
    >>
    >> >> Absence of explicit statement of the behavior means that it is a UB.
    >> >> So the function call I gave in my original post produces UB.

    >>
    >> > Does the Standard state explictly that it is permissible
    >> > to arrange the cases of a switch in descending order? Does
    >> > the Standard state explicitly that it is permissible to write
    >> > a statement label and never use it in a goto?

    >>
    >> It doesn't even say that the function call
    >> #include <stdio.h>
    >> #include <string.h>
    >> memset(stdout, 11, sizeof(FILE));
    >>
    >> can cause UB. But I wouldn't expect a program to continue working
    >> after it.

    >
    > I think you are stating that subsequent usage of stdout either
    > explicitly (using fprintf,fputc etc.) or implicitly (using printf,
    > putc etc.) produces UB.
    > Agreed, that it is a UB, if there is any usage of stdout.
    > But there won't be any if you don't use it.
    >
    > The standards do state that subsequent usage of stdout produces UB!
    > Well, if you ask me how, here I give my explanation.
    > Functions like fprintf uses FILE pointer to do their job. So there
    > will be dereferencing of the FILE pointer in their function call. In
    > such a case if dereferencing is done on the pointer that does not
    > point to a *valid* object, this produces UB. This applies to your case
    > also.
    >
    > If your library function does not dereference FILE pointer or doesn't
    > use it at all for any pointer arithmetics (in that case it should be
    > using some complex mechanism!), then there will be no UB. But I think
    > such implementations are highly unlikely though not disallowed.


    #include <stdio.h>
    #include <string.h>

    static FILE foo;

    int main(void)
    {
    memcpy(stdout, &foo, sizeof foo);
    puts("hello, world");
    return 0;
    }

    (Now I'm no longer completely serious, the FILE object may contain
    pointers which become NULL after the call to memcpy. But I would
    expect the standard to explicitly state that if a FILE object is
    modified other than by a library function, then passing a pointer
    to it to a library function causes UB.)
    Army1987, Jun 19, 2007
    #10
    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. Colin Walters
    Replies:
    2
    Views:
    521
    Ben Pfaff
    Feb 13, 2004
  2. Ross A. Finlayson
    Replies:
    19
    Views:
    590
    Keith Thompson
    Mar 10, 2005
  3. Replies:
    2
    Views:
    343
    Dave Thompson
    Feb 27, 2006
  4. Replies:
    5
    Views:
    363
  5. Replies:
    3
    Views:
    815
Loading...

Share This Page