We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I need to be able to pass parameters to printf from another function. What I have so far works for some data types, but not character buffers, aka strings. Here is what I have that does not work. The SetDirection() are for setting the data direction of external hardware.
int xprintf (char *fmt, ...) { int rv; register int *varg = (int *)(&fmt); SetDirection(1); rv = printf(fmt, varg); SetDirection(0); return rv; }
In what way, precisely, does it "not work"?
I am trying to pass a list of variables to a function. Not sure how to pars out the information. In the above case using printf, the format is passed correctly, integer values are passed correctly, but string values are not, returning unpredictable results.
Did you try to use the va_*() macros? There is an example in the tool's user guide how use to a function with a variable-length argument list. Search for va_start().
Should be:
#include <stdarg.h> #include <stdio.h> int xprintf (char *fmt, ...) { va_list ap; int rv; va_start(ap, fmt); SetDirection(1); rv = vprintf(fmt, ap); SetDirection(0); va_end(ap); return rv; }
"Search for va_start()."
A better example in the context of what the OP is trying to do is:
http://www.keil.com/support/man/docs/c51/c51_vprintf.htm
rv = vprintf(fmt, ap);
Except that vprintf()'s return type is void.
Erm, no, it isn't. But there's a bug in its documentation (as of the version I have here).
The actual <stdio.h> and the actual function have it returning int, as required by the standard.
Thanks Dan. Works great. Don't really need the return value.
Seems I was making it much more complicated than needed.
"Erm, no, it isn't. But there's a bug in its documentation ..."
Erm, hence two posts; one assuming standard compliance and the other contrarily stating operation as documented.
When using part of a toolchain that does not claim compliance to the standard, what is your approach? Do you assume that part is compliant? Do you assume that part operates as documented? Do you assume nothing and test to deduce that part's behavior?
Did you do any of the above or take an entirely different approach to deduce that the bug was in the documentation and not the implementation?
When using part of a toolchain that does not claim compliance to the standard, what is your approach?
The approach was to doubt the documentation because I could not see any reason for a standard violation in this case. Keil doesn't claim full compliance to the standard, correct. But in my experience they do follow the standard where it's not an undue burden to do so. So I was surprised, and decided to look it up.