«

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,;/*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 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,;/*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

On Jun 17, 11:43 pm, Eric Sosman <esos...@acm-dot-org.invalid> 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,;/*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 wrote On 06/18/07 12:32,:
> On Jun 17, 11:43 pm, Eric Sosman <esos...@acm-dot-org.invalid> 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,;/*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

--

On Mon, 18 Jun 2007 16:32:04 -0000, CryptiqueGuy
<> wrote:

>On Jun 17, 11:43 pm, Eric Sosman <esos...@acm-dot-org.invalid> 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,;/*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

"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.

On Jun 18, 10:42 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
> CryptiqueGuy wrote On 06/18/07 12:32,:
>
>
>
>
>
> > On Jun 17, 11:43 pm, Eric Sosman <esos...@acm-dot-org.invalid> 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,;/*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

On Jun 19, 6:30 pm, "Army1987" <please....@for.it> wrote:
> "Eric Sosman" <Eric.Sos...@sun.com> 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.

On Jun 19, 9:29 pm, CryptiqueGuy <SRRajesh1...@gmail.com> wrote:
> On Jun 19, 6:30 pm, "Army1987" <please....@for.it> wrote:
>
>
>
>
>
> > "Eric Sosman" <Eric.Sos...@sun.com> 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" <> ha scritto nel messaggio news: oups.com...
> On Jun 19, 6:30 pm, "Army1987" <please....@for.it> wrote:
>> "Eric Sosman" <Eric.Sos...@sun.com> 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.)