Sharkdp is also responsible for some fantastic tools like hyperfine for micro benchmarking, fd for finding files, bat which is a colorized cat replacement and many more such utilities. https://github.com/sharkdp is a real treasure trove of user-friendly CLI tools.
Which is the hexadecimal dump of the ASCII contents of myfile.txt.
The #defines are used to obfuscate the code and make it harder to read, replacing printf with O1O, putchar with OlO, etc. The D() function is used to check if a byte is a printable ASCII character.
So in summary, this program opens a file, reads it byte by byte, prints the hex values, and prints the ASCII for printable characters, as a hexadecimal dump utility.
I'm well aware of how the code works. I was mostly interested in why it was written like that. nwiswell's comment[1] gave me the hint I needed to find that yes, this was part of an obfuscated C challenge[2].
I know you mean well but LLMs are the very last resource I'd turn to for help. Those things make crap up all the time.
After seeing an LLM do something like this, I've got to ask people who think that LLMs are just "stochastic parrots", "just predicting the next word", or are merely "a blurry jpeg of the web" to think about what's really going on here.
This exact code appears online as part of the IOCCC 1986 (it was a submission), so it's likely that this was indeed part of the training set for this LLM and that there is a significant corpus of text discussing this particular program and other obfuscated programs like it.
I'm not ruling out that this LLM output is "partially organic" rather than "fully regurgitated", but I'd be much more interested to see this LLM explain an obfuscated program that hasn't been floating around the Internet for 35 years.
Even if it's part of the training data and the LLM is just a better search engine, how would I have figured out what the code does without an LLM? I certainly can't paste this into Google.
I mostly agree with the stochastic parrot interpretation, but that doesn't undermine the usefulness or impressiveness. Even if it's just a highly compressed search index, that level of compression is amazing.
My experience is that ChatGPT does a very poor job writing Brainfuck programs for me, even simple programs like "add two and two" aren't correct. Maybe it would do better if I asked it to explain one instead.
In my experience, LLMs are poor at working with unpopular languages -- probably because their training data does not contain a lot of examples of programs written in those languages, or explanations of them.
So, in other words, they perform precisely how you’d expect a stochastic parrot to perform?
The more popular the language the more likely the training corpus includes both very similar code samples and explanation of those code samples, and also the more likely those two converge on a “reasonable” explanation.
Ask it something it’s likely to have seen an answer for and it’s likely to spit out that answer… interesting? Sure, impressive? Maybe… but still pretty well captured by “a fuzzy jpeg of the web”.
> Train a human mostly on English, and they'll speak English. Train them mostly on Chinese, and they'll speak Chinese.
Ahh, but ask a human a question in a language they don’t understand and they’ll look at you with bewilderment, not confidently make up a stream of hallucinatory nonsense that only vaguely looks statistically right.
> Or exactly like you’d expect a human to perform.
Not exactly, no… but with just enough of the uncanny valley to make me think the more interesting thought: are we really not much more than stochastic parrots? Or, in other words, are we naturally just slightly more interesting than today’s state of the artificially stupid?
I've seen code like this (3 letter macros for every one and a half(!) syntax construct, all macros starting in Q, seemingly random indentation). I do not understand why the developer did that or why the company let him. Just that at the end he didn't understand his own code anymore and couldn't fix some issues.
In many fonts, they are nearly indistinguishable. For example, the default font of putty for { and ( look identical to me, leading to many syntax errors in my code.
ImHex indeed looks very featureful and has a pleasant layout, but it's hard not to recognize the perverseness of a the slogan "A Hex Editor" built for those "who value their retinas when working at 3 AM" being applied to an app centered around putting text on the screen but that insists on tiny font sizes and no anti-aliasing...
It looks amazing, but I couldn't get it to run. Binary was linked to a lib that's not on my system, and when compiled from source it just crashes with a bad cast.
Was looking at hexdump alternatives a week ago and between huxdemp (hxd), xxd, hx, hd (not the alias for hexdump -C) and hexdump this was my favourite.
hx wasn't usable when parsing data streams...
And clashes with helix (hx)
On systems where I can't install anything I would just use hexdump -C or xxd
You should have been pointed to https://github.com/prso/hexcurse who forked it on the grounds that the original has broken screenshots and doesn't compile.
Hexyl is what I love to use for quickly looking at a file. For slightly more serious introspection I use Emacs' hexl-mode, which also has basic editing capabilities.
Why would you need a separate binary viewer / editor?
This reminds me the absurd, but somehow common situation where Java programmers in my office used IntelliJ IDEA to write Java, but Notepad++ to view logs or edit INI files etc.
Because people sometimes write parsers for binary file formats? In my case, it is indeed for a programming task, but not for debugging running/compiled code.
A ”raw bytes” view can be useful in many situations.
Because nothing is more awesome than wanting to quickly view a file and vscode decides it needs to not only update itself but the remote helper app as well, so your file takes 30 seconds to load.
i do this. big heavy ide with project and debugger going full blast. I might want to just pop open a log quickly and cba to drag it into the IDE, np++ context menu done. more often tho, reading logs on a non-main dev machine/vm/test/field
I don't know if you know the feeling: it's like watching inexperienced chess players play -- you want to scream when you see them making dumb moves, but then the opponent also makes a dumb move, which makes it more funny than sad.
When I look over the shoulder of people who work like you describe your workflow, just like with chess, I feel this kind of mix of embarrassment and frustration -- it was so easy to do it right, yet you decided to do something silly instead.
shrug, im drastically faster than all my work mates not that thats a good benchmark, im not bothered and have stuff that works quite well for me. what i outlined above is worst case scenario with some huge IDEs like VS or a huge idea project. some projects i do entirely in vim. others i have to use 2 remote debuggers at once with a VM in the mix. im doubtful their advice would apply
Yeah, it's kind of how it happens. Your skills suck just a tiny bit less than of those around you, and you come to unwarranted conclusion that you are doing good.
Unfortunately, our industry has few small pockets where you can still find competent programmers every now and then, but you wouldn't see them using IDEA or VS Code. And then there's an ocean of... well, not even mediocrity, it's just hands down awful. Most programmers throughout their career will never see a competent programmer, and if they stay around will be promoted into management where they will lose the very modest skill they had. And the cycle will continue.
I don't want to support people who don't want to support themselves. Also, the commenter wasn't asking for support. They proudly believe that what they do is a legitimately good way to use their computer.
I've seen way too many people like that, and have an idea how that kind of belief is formed. I don't want to help those people. I want them gone.
There aren't sysadmins today who aren't programmers.
> Programmers who don't have their editor open
Well... these aren't programmers. Maybe "aspiring programmers", as in someone who still have to learn how to use their computer. It's not anyone who would be considered a competent user.
What are you talking about? I use cat and less all the time when I'm working in the console. No need to switch tools when I want to take a quick look at the file.
I really like this tool for quick, easy debugging on binary files. okteta used to be my go to, but it's rare I need editing. I'm usually just take a quick look at the contents.
I also use XVI32. It's honestly probably not the best hex editor out there anymore, but I've been using it for well over a decade now and I'm used to its quirks.
But for my needs the hex viewer that I've wrote works best. I need those number displays at the bottom and an easy way to go to relative and absolute offsets. See the screenshot at the bottom: https://github.com/panzi/rust-hox
Game hacking for sure, and it's still a blast. Playing around with variables in cheat engine or messing with save files is a fantastic way to get started as long as you stick to single player games (multiplayer cheating is way harder and usually unethical).
When I was coming up, we didn’t have no dashed lines dividing the displays into 8-byte segments. And color? Everything was orange text on black. If you wanted green on black, you used a coworker’s terminal.
Althought it is worth remembering that hex editors with colour and lines are now a thing that is at least 35 years old, as Central Point's PC Tools for DOS had one.
Strongly related: is there a hex viewer where I can set , preferably on-the-fly or with a command line switch record delimiters so it colors the records?
I have been out of the bit land for a very, very long time -- the last of my assembly programs are old enough to drink -- but I am increasingly finding myself running hexdump again and it's not a great experience. I expected better in 2023 and here it is.
