Dynamic Memory Allocation Unknown Filesize

[Steve_M]

Hi guys.

I'm trying to write a program that reads in an executable file (Linux/Unix)
and simply dumps its contents, in a hexadecimal format to the screen. My problem
is in trying to achieve this in a Windowed environment under GTK+. The GTK+
text view requires the file format encoded as UTF-8. My solution is to use
sprint().

sprintf(newText, "%X", (unsigned int)buffer[i]);

My question is this. How do you allocate dynamic memory to the text buffer
'newtext'? It is simple enought to get the size of the binary file and
allocate memory to hold the binary code.

//Allocate memory
buffer=(unsigned char *)malloc(fileLen+1);

But the text buffer size is more difficult to compute since my output will
contain spaces and other text format information as I concatenate the 'newtext'
string using a loop.

[cpns]

I think you have answered your own question:

You need (4 + (fileLen % 16)) * 80

(fileLen % 16) + 1 is the number of lines needed for the binary data, plus another 3 for the header/footer text, then 80 characters per line. This allows for a little padding because the header/footer do not use the whole 80 characters - but a little padding is no bad thing here.

Personally for simplicity, I migh just fprintf() the text directly to the file, and then simply use the text view box to view the file. However, a simple and efficient method, is to simply determine teh offset for the top line of the text and generate the text on teh fly from the initial offset. Then page up/dn etc. would simply modify the offset and regenerate the display text. The ammount of text needed is than exactly determined by the size of the window (which may be resizeable, so still needs dynamic allocation, but it is not not related to the binary file size). Using fseek() or lseek() for example, you need not even read in the whole file into memory.

Clifford

[cpns]

A single byte in the original binary required two bytes to represent it using %X (because 4 bits maps exactly to one hex digit). So newText must be twice the size of the original data, plus any newlines, whitespace or metadata your specific hex format might require if any. All you have told us is that it is more difficult to compute, but have given no information that might allow us to assist. We need to know your exact output format!

You could alternatively write the text to a temporary file using fprintf(), and then get the resultant file size and read the text back in.

One alternative is simply allocate much more than you know you will need as a multiple of the binary file size.

You might also use a fixed sized 'window' buffer and slide it through the file as necessary. Only reading in the currently viewed portion of the whole.

Clifford

[Steve_M]

Thanks for your reply Clifford.

I am trying to achieve the following output:

Binary file has ELF header
a.out --> file length is 93 bytes
80000000 | 7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00 | .ELF............
80000010 | 02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 | ........T...4...
80000020 | 00 00 00 00 00 00 00 00 34 00 20 00 01 00 00 00 | ........4. .....
80000030 | 00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 | ................
80000040 | 00 80 04 08 5D 00 00 00 5D 00 00 00 05 00 00 00 | ....]...].......
80000050 | 00 10 00 00 66 31 C0 66 40 B3 2A CD 80 | ....f1.f@.*.....
a.out --> end of file!!!

The above example is a TINY executable file....used as an example only. I want to use the program to
load much larger executables of any size. I directed the output of my program to produce the above
UTF-8 text file which is 553 bytes long. I am working on a solution similar to your suggestion. I have decided to display 16 bytes per line laid out as above. With spaces and other information it works out at 80 characters per line. So for every 16 bytes in the binary file I need 80 bytes space to display the code in UTF-8 format. Add in the additional 3 lines of text and it works out at 9 lines*80=720bytes.

I shall also look into your suggestion regarding a fixed sized window buffer to slide through the file as necessary.

Steve