In response to this question asking about hex to (raw) binary conversion, a comment suggested that it could be solved in "5-10 lines of C, or any other language."
I'm sure that for (some) scripting languages that could be achieved, and would like to see how. Can we prove that comment true, for C, too?
NB: this doesn't mean hex to ASCII binary - specifically the output should be a raw octet stream corresponding to the input ASCII hex. Also, the input parser should skip/ignore white space.
edit (by Brian Campbell) May I propose the following rules, for consistency? Feel free to edit or delete these if you don't think these are helpful, but I think that since there has been some discussion of how certain cases should work, some clarification would be helpful.
- The program must read from stdin and write to stdout (we could also allow reading from and writing to files passed in on the command line, but I can't imagine that would be shorter in any language than stdin and stdout)
- The program must use only packages included with your base, standard language distribution. In the case of C/C++, this means their respective standard libraries, and not POSIX.
- The program must compile or run without any special options passed to the compiler or interpreter (so, 'gcc myprog.c' or 'python myprog.py' or 'ruby myprog.rb' are OK, while 'ruby -rscanf myprog.rb' is not allowed; requiring/importing modules counts against your character count).
- The program should read integer bytes represented by pairs of adjacent hexadecimal digits (upper, lower, or mixed case), optionally separated by whitespace, and write the corresponding bytes to output. Each pair of hexadecimal digits is written with most significant nibble first.
- The behavior of the program on invalid input (characters besides
[a-fA-F \t\r\n]
, spaces separating the two characters in an individual byte, an odd number of hex digits in the input) is undefined; any behavior (other than actively damaging the user's computer or something) on bad input is acceptable (throwing an error, stopping output, ignoring bad characters, treating a single character as the value of one byte, are all OK) - The program may write no additional bytes to output.
- Code is scored by fewest total bytes in the source file. (Or, if we wanted to be more true to the original challenge, the score would be based on lowest number of lines of code; I would impose an 80 character limit per line in that case, since otherwise you'd get a bunch of ties for 1 line).
Its an language called "Hex!". Its only usage is to read hex data from stdin and output it to stdout. Hex! is parsed by an simple python script. import sys
A 31-character Perl solution:
s/\W//g,print(pack'H*',$_)for<>
I know Jon posted a (cleaner) LINQ solution already. But for once I am able to use a LINQ statement which modifies a string during its execution and abuses LINQ's deferred evaluation without getting yelled at by my co-workers. :p
1 statement formatted for readability.
Update
Support for spaces and uneven amount of decimals (89A is equal to 08 9A)
Still one statement. Could be made much shorter by running the replace(" ", "") on hex string in the start, but this would be a second statement.
Two interesting points with this one. How to track the character count without the help of outside variables other than the source string itself. While solving this I encountered the fact that char y.CompareTo(x) just returns "y - x" while int y.CompareTo(x) returns -1, 0 or 1. So char y.CompareTo(x).CompareTo(0) equals a char comparison which returns -1, 0 or 1.
edit Checkers has reduced my C solution to 46 bytes, which was then reduced to 44 bytes thanks to a tip from BillyONeal plus a bugfix on my part (no more infinite loop on bad input, now it just terminates the loop). Please give credit to Checkers for reducing this from 77 to 46 bytes:
And I have a much better Ruby solution than my last, in
4238 bytes (thanks to Joshua Swank for the regexp suggestion):original solutions
C, in 77 bytes, or two lines of code (would be 1 if you could put the
#include
on the same line). Note that this has an infinite loop on bad input; the 44 byte solution with the help of Checkers and BillyONeal fixes the bug, and simply stops on bad input.It's even just 6 lines if you format it normally:
Ruby, 79 bytes (I'm sure this can be improved):
These both take input from STDIN and write to STDOUT
39 char perl oneliner
Edit: wasn't really accepting uppercase, fixed.
Brian's 77-byte C solution can be improved to 44 bytes, thanks to leniency of C with regard to function prototypes.