By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,305 Members | 1,704 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,305 IT Pros & Developers. It's quick & easy.

Function call with wrong number of parameters

P: n/a
Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?

Thanks in advance,
arne

Mar 14 '07 #1
Share this Question
Share on Google+
16 Replies


P: n/a
arne wrote:
Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?
The behaviour is undefined if you even declare a function
inappropriately, let alone actually call it with the wrong number of
arguments. If you're lucky, you'll get a crash.

Mar 14 '07 #2

P: n/a
"arne" <ar***********@gmail.comwrites:
imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?
It's undefined behavior.

In a properly written program, a prototype for foo() will be visible
at the point of the call (probably in a "foo.h" header), and a call
with the wrong number of arguments will be a constraint violation
requiring a compile-time diagnostic.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 15 '07 #3

P: n/a
On Mar 14, 5:05 pm, "arne" <arne.wieba...@gmail.comwrote:
Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;

}

main.c:
int main( void )
{
foo( 21 );
return 0;

}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?
The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).

C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues

On the other hand, the fact that these features did not make
it into C99 suggests that I am wrong.

- William Hughes

Mar 15 '07 #4

P: n/a
In article <11*********************@e1g2000hsg.googlegroups.c om>,
William Hughes <wp*******@hotmail.comwrote:
....
>The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).

C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues
The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.

Mar 15 '07 #5

P: n/a
On Mar 15, 7:14 am, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
In article <1173920462.602572.99...@e1g2000hsg.googlegroups.c om>,William Hughes <wpihug...@hotmail.comwrote:

...
The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).
C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues

The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.

But why do you say "C just isn't that sort of language"?

Is there something about the theory of the C language
that precludes this sort of feature?

It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.

What am I missing?
- William Hughes

Mar 15 '07 #6

P: n/a
William Hughes wrote:
On Mar 15, 7:14 am, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
>In article <1173920462.602572.99...@e1g2000hsg.googlegroups.c om>,William Hughes <wpihug...@hotmail.comwrote:

...
>The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).
>C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues

The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.

But why do you say "C just isn't that sort of language"?
Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.
Is there something about the theory of the C language
that precludes this sort of feature?
"It's not useful enough".
It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.

What am I missing?
There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".

--
Chris "electric hedgehog" Dollin
"Our future looks secure, but it's all out of our hands"
- Magenta, /Man and Machine/

Mar 15 '07 #7

P: n/a
On Mar 15, 9:57 am, Chris Dollin <chris.dol...@hp.comwrote:
William Hughes wrote:
On Mar 15, 7:14 am, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
In article <1173920462.602572.99...@e1g2000hsg.googlegroups.c om>,William Hughes <wpihug...@hotmail.comwrote:
...
The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).
C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues
The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.
But why do you say "C just isn't that sort of language"?

Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.
Is there something about the theory of the C language
that precludes this sort of feature?

"It's not useful enough".
It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.
What am I missing?

There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".
True, but the same things apply to
e.g. prototypes and complex number support.

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

- William Hughes

Mar 15 '07 #8

P: n/a
William Hughes wrote:
On Mar 15, 9:57 am, Chris Dollin <chris.dol...@hp.comwrote:
>William Hughes wrote:
Is there something about the theory of the C language
that precludes this sort of feature?

"It's not useful enough".
It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.
What am I missing?

There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".

True, but the same things apply to
e.g. prototypes and complex number support.
Indeed.

They were winners. There were doubtless losers.
If the argument is simply

We can't add all features, this is one we decided not
to add

OK.
It's more: these are the features that have been proposed
(and have implementations), which of these provides the
appropriate bang per buck /in this committee's opinion/.
However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.
I don't know if that feature was /proposed/ for C99. If it
wasn't, it had no chance. If it was, it would have to have
got broad agreement. Perhaps it didn't -- for whatever reason.

What I'm saying is, the decision about which features make it
in and which don't is made by people with passions and prejudices
and mandates and finite time. A lot like life, really.

--
Chris "electric hedgehog" Dollin
"I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/

Mar 15 '07 #9

P: n/a

"William Hughes" <wp*******@hotmail.comwrote in message
news:11*********************@p15g2000hsd.googlegro ups.com...
On Mar 15, 9:57 am, Chris Dollin <chris.dol...@hp.comwrote:
William Hughes wrote:
On Mar 15, 7:14 am, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
>In article
<1173920462.602572.99...@e1g2000hsg.googlegroups.c om>,William Hughes
<wpihug...@hotmail.comwrote:
>...
>The behaviour is undefined (and if a prototype is in scope a
>diagnostic must be issued (many compilers will issue a diagnostic
>if a prototype is not is scope)).
>C has neither named parameters, no default values for ommited
>parameters. Why I don't know. It strikes me that adding
>these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues
>The fact is that C just isn't that sort of language. If you want VB
(or
>even C++), you know where to find it.
But why do you say "C just isn't that sort of language"?
Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.
Is there something about the theory of the C language
that precludes this sort of feature?
"It's not useful enough".
It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.
What am I missing?
There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".

True, but the same things apply to
e.g. prototypes and complex number support.

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.
I am not sure why its usefull. Provided you pass pointers then can't you
just pass "NULL" for any thing you want to omit. I am also not sure about
difficulty to add. Assuming you have separate compilation units then at
present code can work without function prototypes. This would require them
(I think) because I am pretty sure the caller would have to create dummy
paramters for the missing ones. If I had a vote I don't think its one I
would give it to...
- William Hughes

Mar 16 '07 #10

P: n/a
In article <11*********************@p15g2000hsd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:

[ About default parameter values and named arguments.]
If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.
I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Mar 16 '07 #11

P: n/a
Dik T. Winter wrote:
In article <11*********************@p15g2000hsd.googlegroups. com"William Hughes" <wp*******@hotmail.comwrites:

[ About default parameter values and named arguments.]
If the argument is simply
>
We can't add all features, this is one we decided not
to add
>
OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
Oh, that's easy-peasy: "the effect is undefined"!
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.
If we don't like it, we demonise it. Er ... not that I'd reccommend
that as a general rule.

--
Chris "Buffy hedgehog" Dollin
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/

Mar 16 '07 #12

P: n/a
On Mar 15, 8:44 pm, "Dik T. Winter" <Dik.Win...@cwi.nlwrote:
In article <1173973746.784806.53...@p15g2000hsd.googlegroups. com"William Hughes" <wpihug...@hotmail.comwrites:

[ About default parameter values and named arguments.]
If the argument is simply
>
We can't add all features, this is one we decided not
to add
>
OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.
--
If you call a function without a declaration or definition in scope,
or only a
delclaration without parameter informationan, with the wrong
number and/or type of parameters then you are in nasal demon
territory. If a
declaration does not match the definition you are in nasal demon
territory [1].
Nothing new here. Still, I am not advocating the addition of default/
named parameters,
merely wondering whether there absence is due to some factor I had
not considered.

- William Hughes

[1] You do, of course, include foo.h in foo.c to catch this.

Mar 16 '07 #13

P: n/a
On Mar 15, 6:02 pm, "David Wade" <g...@yahoo.comwrote:
"William Hughes" <wpihug...@hotmail.comwrote in message

news:11*********************@p15g2000hsd.googlegro ups.com...On Mar 15, 9:57 am, Chris Dollin <chris.dol...@hp.comwrote:
William Hughes wrote:
On Mar 15, 7:14 am, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
In article

<1173920462.602572.99...@e1g2000hsg.googlegroups.c om>,William Hughes

<wpihug...@hotmail.comwrote:
...
The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).
C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues
The fact is that C just isn't that sort of language. If you want VB
(or
even C++), you know where to find it.
But why do you say "C just isn't that sort of language"?
Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.
Is there something about the theory of the C language
that precludes this sort of feature?
"It's not useful enough".
It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.
What am I missing?
There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.
A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.
That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".
True, but the same things apply to
e.g. prototypes and complex number support.
If the argument is simply
We can't add all features, this is one we decided not
to add
OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I am not sure why its usefull. Provided you pass pointers then can't you
just pass "NULL" for any thing you want to omit. I am also not sure about
difficulty to add. Assuming you have separate compilation units then at
present code can work without function prototypes.
However, only if all calls to functions without prototypes use
the correct number and type of parameters. Adding default parameters
changes little. You could still call a function with default
parameters,
even without a prototype, as long as you include all parameters
(including default parameters).

If you use a coding style under which it is an error to call
a function without a prototype in scope
(except for the rare cases, eg function pointers,
where it is unavoidable) you cannot avoid prototypes.
>This would require them
Only to use the new feature. If no declaration or definition
containing
default information was in scope, then the compiler could not assume
that missing parameters exist. This does not lead to problems that
are
not already there.
- William Hughes

Mar 16 '07 #14

P: n/a
"William Hughes" <wp*******@hotmail.comwrote in message
news:11*********************@e1g2000hsg.googlegrou ps.com...
C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues

On the other hand, the fact that these features did not make
it into C99 suggests that I am wrong.
All of the new features in C99 that I care about are ones that various folks
had implemented as extensions to their C89/90 compilers. Presumably the
things you list above could also be added to C99 as extensions, and if they
became popular they could be added to the standard in C0X. Since nobody has
even bothered with implementing such extensions to date, it seems that
they're not as useful and/or as easy as you think, and therefore it makes
little sense to standardize them.

If you disagree, go grab the GCC source, submit patches, and try to get some
advocacy going over in comp.std.c. Here in comp.lang.c, we discuss what
_is_, not what _could be_.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

Mar 16 '07 #15

P: n/a
On Mar 15, 2:40 pm, "Stephen Sprunk" <step...@sprunk.orgwrote:
"William Hughes" <wpihug...@hotmail.comwrote in message

news:11*********************@e1g2000hsg.googlegrou ps.com...
C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would
-be useful
-be relatively easy
-have few if any backwards compatability
issues
On the other hand, the fact that these features did not make
it into C99 suggests that I am wrong.

All of the new features in C99 that I care about are ones that various folks
had implemented as extensions to their C89/90 compilers. Presumably the
things you list above could also be added to C99 as extensions, and if they
became popular they could be added to the standard in C0X. Since nobody has
even bothered with implementing such extensions to date, it seems that
they're not as useful and/or as easy as you think, and therefore it makes
little sense to standardize them.
Indeed, but this just shifts the problem a bit. (I am aware that C90
and C99
to a large extent standardized existing extensions. What I am not
aware
of is whether any complier offers default/named parameters as an
extension.
Apparently not.) The question now becomes "why have they not been
implemented?".
The answer "it seems that they're not as useful and/or as easy as you
think"
while accurate, is not very useful. A bit more detail would be
helpful.
>
If you disagree, go grab the GCC source, submit patches, and try to get some
advocacy going over in comp.std.c.
If I had advocated their inclusion in C this would be good advice.
Here in comp.lang.c, we discuss what
_is_, not what _could be_.
As far a topicallity goes, the question "Why is feature X not found in
C?"
seem to me a good fit for comp.lang.c, (the slightly different
question
"Should feature X be added to the next C standard?" is clearly best
suited to comp.std.c).

- William Hughes

Mar 16 '07 #16

P: n/a
William Hughes wrote:
>
.... snip ...
>
If you use a coding style under which it is an error to call a
function without a prototype in scope (except for the rare cases,
eg function pointers, where it is unavoidable) you cannot avoid
prototypes.
It is trivial to provide default parameters effects, where needed.
Two examples are:

getchar() via #define getchar() getc(stdin)
ggets(p) via #define ggets(p) fggets(p, stdin)

where getchar is part of the standard library, and ggets is defined
in my own ggets.h file.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 16 '07 #17

This discussion thread is closed

Replies have been disabled for this discussion.