Vikrama Ditya wrote:
> As I understand, logMsg and taskSpawn used to support variable number of
> arguments with 5.0 version. Later due to "some" problems with variable
> arguments in "some" architecture, VxWorks introduced __PROTOTYPE_5_0 (which
> is not defined by default) directive to enable variable arguments and by
> default set 7 fixed arguments for logMsg and 10 fixed arguments for
> taskSpawn.
>
> What I would like to know what is exactly the problem with variable
> arguments. Is it the processing or no control on function stack size? Which
> specifc processor architecture has this problem? I am using MPC8260
> processor will I have any issue if I enable __PROTOTYPE_5_0 directive?
>
> Thanks for any help.
> --
> Vikram

Vikram,
I am not aware of the exact reason behind this.I will give my guess
from my side:
In vxworks for any task stack we are only allocating the memory.So we
can decide based on the worst case scenerio and provide the value for
the stack size.But,when you consider the case where numerous number of
arguments may be passed,selecting the stack size may be a problem.In
that case,either you will waste memory or you will make stack overflow
..But still if we are very sure about the worst case scnerio for the max
number of arguments,then you should be able to provide enough stack
with variable arguments.

But in general,its tough to get a rough figure if we go for variable
arguments.

I believe the same applies for LogMsg functionality too.

This is my guess.May be others might provide you more reasons.

Regards,
s.subbarayan