Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

hex2bin - thread205-1155185

Status
Not open for further replies.

riteshshah

Programmer
Feb 8, 2005
12
US
thread205-1155185.

Spoke to Dave Sinkula and he gave me a great function to convert hex to bin (below). It's taken a while for me to get round to finishing this but I seem to have conversion errors when I look at the binary file. Some of the end of the pages look corrupt. - Usually the last line.

Any ideas why this may occur?

Thanks folks!


#include <stdio.h>

int main(void)
{
static const char infilename[] = "file.txt";
static const char outfilename[] = "file.bin";
FILE *infile = fopen(infilename, "r");
FILE *outfile = fopen(outfilename, "wb");
if ( infile && outfile )
{
int ch;
while ( fscanf(infile, "%2x", &ch) == 1 )
{
fputc(ch, outfile);
}
fclose(infile);
fclose(outfile);
}
return 0;
}
 
Please use the [tt][ignore]
Code:
[/ignore][/tt]
tags when posting code.

Can you post a few lines of your input file as well, so we have something to test with.

--
 
Sure Salem,

It's not pretty:


"E1D90500809B3A3C9B4CE1D90500809B3A3C9B4CE1D90500809B3"

When it finishes processing 4c, it fails to convert E1 and returns EOF. The pattern is repeated before this point and it converts successfully. Possibly a buffering issue?

Thanks!!
 
I've no idea, it works as expected here (Linux/gcc).
Code:
$ cat file.txt
E1D90500809B3A3C9B4CE1D90500809B3A3C9B4CE1D90500809B3
$ od -Ax -t x1 file.bin
000000 e1 d9 05 00 80 9b 3a 3c 9b 4c e1 d9 05 00 80 9b
000010 3a 3c 9b 4c e1 d9 05 00 80 9b 03
00001b
You should note that your example is an odd number of characters long.

--
 
Ok.. Sussed what is happening.. fscanf returns an EOF part way through the scanning of the 'hex' file. What is wierd is that it reports EOF in a repeating pattern towards the end of the file, after it has already successfully trnaslated an earlier repeat of the pattern. I think it maybe something to do with buffers. It may have to write out the current buffer to file before it continues.. However, I added a fflush statement after the fputc statement, initially just to see if it is a buffer issue, but it has not made a difference:

Code:
       fflush( outfile );
[\code]

So.. although I can see where it is failing.. I'm still not sure why.. I'm now thinking of using something else instead of fscanf.

Any thoughts?

Thanks!
 
What OS? Some leave rubbish up to the end of the buffer when they write the file, but don't include the extra in the file length count. Could that be happening, or is the repeating pattern really there and valid?
 
It's on unix/solaris 8.. I'm using cc. And the pattern is definitely repeating.. Going to try the fgetc route and see if I can convert that to binary and write one at a time.. fingers x'ed!!
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Sponsor

Back
Top