What's wrong with this???

What are you trying to do with the "+1" in the in va_start()?  What are you trying to do period?

Basically just to port the os_printf() to my printf() functions.

I tried without +1 also...

Is myprintf() overloaded?  Your first call has only one parameter.  I assume there is a myprintf() that takes a va_list as its second argument.  That should be fine, but I think you are initializing "arglst" incorrectly.  You should not be adding 1.  Try

VOID os_printf(char *ctl, ...)
      {
        va_list argList;

        va_start(argList, ctl);
        myPrintf("os_printf - ");
        myPrintf(ctl, argList);
        myPrintf("\n");
      }

note you shouldn't need the va_end, either.

To make long story short, I've been trying to port a TCP/IP stack to our embedded system environment.  It uses os_printf() which the developer would have to replace it with os-dependent printf() command.

Opps, I hadn't seen you message that you tried without +1, when I posted last. What does the myprintf() code look like?

myprintf() basically takes in (char * ctl, ...) and goes through each % identifier and format the message with the corresponding argument.  It function just like printf().

Wait a second.  It is not declared with a ... arguement is it?  It should take a va_list as a second argument.

Yeh, it's declared with ... as second argument.

when you call myprintf() like

    myPrintf(ctl, argList);

you are not passing the parameters that were passed to os_printf().  You are passing (as the second parameter) a pointer to where those arguments are stored on the stack.  so myPrintf() is getting only two parameters (regardless of what was passed to os-printf()) and the second parameter is a pointer to a parameter in another function, not the regular parameter.  

If this is what you are doing, this can be made to work. You have to change myprintf() a little.  I'll wait for your response before I give details, in case II'm wrong about your approach.

Well, that was a short wait.  Do you need help fixing it?

YES, I think you're on the right track.  So, how should I make it so that myPrintf() gets the exact same paramters passed in as os_printf()?  Thanks.

Apparently, you are good to go.  So I'm going to go.  I'll check in a few hours if you need more.

Okay, I got it:
The hardware dependent printf() looked like this:
myPrintf(LPSTR format, ...)
{
va_list ap;
va_start(ap, format);
format(PutChar, format, ap);
va_end(ap);
}

So, my os_printf() should be:
VOID os_printf(char *ctl, ...)
{
va_list ArgList;
va_start(ArgList, ctl);
format(PutChar, ctl, ArgList);
va_end(ArgList);
}

That looks right.  Does it work?  Note, you shouldn't need the va_end() for this, at least not for what you've shown.

It still don't work...  This is weird!

What does not work?  Compiler or run-time?  which procedure/what behavior?

Am I right in assuming that
(1) format() is existing code that you are trying to make use of,
(2) OS_printf() is code written to use format() that does work, and
(3) myprintf() is something you are writing modeling os_printf()?

If the code is too long to post, you could email it to me.  nietod@theshop.net.  If you do that, include a note pointing me to the right place.

1) format() is a chunk of code already provided by our kernel wrapper around AMX RTOS kernel.
2) os_printf() is used by FUSION TCP/IP stack that has to be defined for os-dependent output.
3) hwprintf() is another function provided by our kernel wrapper.  It will completely mimic printf()'s functionality.

Nietod, thanks for the help and the patience.  This is driving me crazy.  With the extremely tight deadline to start out with and that I'm solely responsible for making the IP network to work between PC side and the embedded side, it's really frustrating.  I've done a lot on the PC side already, like TDI-client kernel-mode drivers, IP handshake protocol driver.  But I've just been introduced to the embedded side recently...  sigh...

Well, I did a quick fix by:
#define os_printf Dprintf
(But this technique doesn't allow me to distinguish between os_printf, os_warn, or os_panic,...)
The va_list thing is still bothering me, but I have more to solve with this tight deadline.  I guess I'll leave it as it.  But I still really appreciate what you, nietod,  has helped.  Thanks.  :-)

Well, when you get back to it.  Post your questions/progress here.