I think you need to clarify a little more.
What kind of program is it?
What are cBuf[] and cInBuf[]?
In general, if you want to split an integer into its components for display, you must convert it to a string first
$ man sprintf
int n = 22;
int i;
char sbuf[6];
char tbuf[12];
/*
Especially when expanding a bufffer, make sure it holds 0's, otherwise strlen() will go amok /
memset(tbuf, 0, sizeof(tbuf));
/
init should be done in general
*/
memset(sbuf, 0, sizeof(sbuf));
sprintf(sbuf,"%d", n);
/* sbuf[] now holds '2','2', 0 */
for (i = 0; sbuf[i]; i++)
{
tbuf[i*2] = sbuf[i]; /* for speed, you can shift here */
tbuf[i*2\+1]='F';
}
/* Now, tbuf[] holds "2F2F", but somehow,
I don't think this is what you wanted?
*/
I want to convert len, which is an integer, to an array. When it is an array, i can get F2F2.
I can convert it with "itoa". But how can i write this, to get F2F2? Please help!!!
Then check the code above, this is exactly what it does.
It uses sprintf() to put the individual cifers into a char array, and then puts an 'F at every other place in the array.
If you want to use itoa() instead, that is OK, but I tried on both my Solaris, Linux box and FreeBSD box, and could not find a man itoa.
What system are you using?
I think you might want to use sprintf, unless itoa is part of your code?
I thought that this was just a crazy thread. But I just typed:
echo 22 | dd conv=ebcdic | od -x
and sure enough a character 2 in ebcdic is a F2. But if this is supposed to be a conversion to ebcdic, this isn't really converging on a solution. Still, it might be an attempt at displaying what the bytes would be in ebcdic or something.
The lack of itoa always bothered me a little too. It seems like such an obvious companion to atoi. But it's not there, so I agree that sprintf is the general solution.
If you're absolutely sure that "i" contains an integer less than 100, this might be quick:
I have never used an EBCDIC machine, and had no idea that there was a correspondence ...
I sort of 'grew up' with itoa, it was defined like this:
char *itoa(int base, char *buf)
The reason is probably that it was coded in 8086 assembly under DOS, most low-level routines were.
About making a converter, though, I think it is much better with a table, conversion should boil down to an XLAT on Intel, and probably something to that effect on other processors.