When your question is answered use !solved to mark the question as resolved.
Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.
#Getting the hex values for a text file.
raw galeBOT
wintry steppe
I mean your program outputs better data in my book
that od takes every four bytes and treat them as 4-byte little endian integers
and unless this is utf32 text file, displaying hex values per byte seems more sane
try od -tx1 input.txt
summer hollow
I mean your program outputs better data in my book
$ ./hexprnt
00000000 3132 3332 0A34 3930 33
$ od -tx1 input.txt
0000000 31 32 33 32 0a 34 39 30 33
0000011
The od command you gave me produces similar output,it's just missing the 0000011. Is that a EOF value?
The thing is,I need to get the hex values for other file types that aren't just .txts and I (strangely) prefer the output I get from the od -v -X <filename> command.
wintry steppe
but is you decision informed? i.e. do you understand why that version of od displays different order and why would you choose that order or the other?
beacuse this is nothing random
and yes, od seems to display input size in the last line
so you could just write address after the loop to get the same
$ echo -n "" | od -vX
0000000
$ echo -n "a" | od -vX
0000000 00000061
0000001
$ echo -n "ab" | od -vX
0000000 00006261
0000002
$ echo -n "abc" | od -vX
0000000 00636261
0000003
$ echo -n "abcd" | od -vX
0000000 64636261
0000004
$ echo -n "abcde" | od -vX
0000000 64636261 00000065
0000005
$
$ echo -n "a" | od -vX
0000000 00000061
0000001
about informed decisions - you have exactly single byte of input but in that mode od will display it as a single 4-byte number, so exactly like you would actually have 4 bytes
knotty sluice
Also note: by default od offsets are printed in octal
wintry steppe
well, that's you choice in your code
there is %o conversion after all
ah, you are not the OP
I became lost there :)
summer hollow
I became lost there :)
so,looking at your earlier response, essentially, the od command I was using displays each byte of input as a little-endian 4 byte number?
wintry steppe
nope, it displays file as a list of 32-bit little-endian values
wintry steppe
```
$ echo -n "a" | od -vX
0000000 00000061
0000001
```
about informed decisions...
see? one byte of input, "4 bytes" of output
$ echo -n "a" | xxd
00000000: 61 a
$ echo -n "a" | od -vX
0000000 00000061
0000001
$ echo -n "a" | hexdump -C
00000000 61 |a|
00000001
(hexdump without -C also groups, but as 16-bit words, so it would print 0061)
so for arbitrary binary files I will take a single byte output any time, and I would use any other one only if I knew that the file is actually some data encoded a multibyte values
because that "file" here literally has only a single byte of hex value 0x61, exactly 8 bits
summer hollow
Gotcha,the problem is that I could potentially be dealing with multibyte values, so I wanted to use that format.
summer hollow
`uint32_t buffer[16 / 4]`
I updated my program to do that,but I'm still not getting the full addresses.
00000000 323332313039340a
$ od -v -X input.txt
0000000 32333231 3039340a 00000033
0000011
This is what I get for output.
I'm not worried about the 0000011,but I'm unsure where the 33 went.
summer hollow
nevermind,fixed
raw galeBOT