Add option to output result in C include file style (#242)

[wpcwzy]

This pull request introduces a new feature that adds an option to output the result in C include file style, similar to the -i or --include option of the xxd command. This functionality allows users to generate hex dumps in a format that can be easily embedded as arrays in various programming languages.

When hexyl accepts input from stdin, users can expect the following output format:

$ echo -n "Hello, world!" | hexyl -i
  0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
  0x21

When hexyl accepts a filename as an argument and reads from the file, users can expect the following output format:

$ hexyl -i hello.txt
unsigned char hello_txt[] = {
  0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
  0x21
};
unsigned int hello_txt_len = 13;

The above behavior is consistent with the behavior of xxd -i.

I also added the functionality to accept input from a slice and output the bytes in C include file style, as I noticed that there is a corresponding use case in examples/simple.rs. When hexyl accepts input from a slice, its behavior is consistent with accepting input from stdin.

This is my first time contributing a new feature to an open-source project, so if there are any areas where I may have fallen short or could improve, I would really appreciate your feedback. Thank you!

[sharkdp]

This looks great, thank you very much! Sorry for taking such a long time to review this.

@sharifhsn Only if you are interested: do you have any thoughts on this PR?

[sharifhsn]

This is nice. It's quite separate from most of hexyl's functionality, so there's not much to comment on. Squeezing is inappropriate in this context and color schemes are also not relevant.

LGTM

[wpcwzy]

Thank you for the review! If there's anything else I need to address or improve, please let me know. Happy to help!

[sharkdp]

Thank you very much, both of you. @wpcwzy would you mind fixing the merge conflicts here?

[wpcwzy]

Looks like the conflicts are resolved and the CI is happy now. 🙂

[sharkdp]

This is really great. Thanks for fixing the merge conflicts.

I have a final question regarding CLI design. I don't really like the flag name --include. We should support it for compatibility with xxd, but I wonder if our default name should be something else. Like --output-code or --source-code. We could also make that a real option instead of just a a flag. It could take the programming language as an argument. --output-code=c would output C source code, and --output-code=rust would output Rust code. --include could then be an alias for --output-code=c. We certainly don't have to add support for other languages in this PR, but I'd like us to think about the general design a bit. And maybe consider adding that option here.

[wpcwzy]

Sorry for not replying to you sooner. I completely agree with your point. We should keep --include for compatibility reasons, but we can also support a wider variety of code output formats.

I'm planning to continue exploring how to add these features to hexyl. Would you prefer that I design and implement the related interface in this PR, or should I implement the basic functionality now and refactor this part in a follow-up PR later?

Thanks again for your feedback and guidance!

[sharkdp]

Sorry for the late reply. Let's merge this as-is, and add the --output-code option (or whatever we choose) later.