541

You can certainly change it. But should you? (lemmy.ml)

submitted 9 months ago by fl42v@lemmy.ml to c/programmer_humor@programming.dev

62 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] huginn@feddit.it 5 points 9 months ago

Ah my bad, misunderstood the use case.

I thought you were talking about keeping an unmaintained library intact but building onto it.

I thought C was a really dangerous way to use that syntactic sugar pattern. Actual manipulation of the bytecode to maintain and extend a compiled binary is wild

[-] mox 9 points 9 months ago

Actual manipulation of the bytecode to maintain and extend a compiled binary is wild

Just wait until you learn about machine code. :)

[-] huginn@feddit.it 1 points 9 months ago

I do have a degree in this. I am aware.

This is sometimes practical, too. For example, hooking and extending functions in compiled code that will never be updated by the original author, while preserving the original executable/library files.

Your original comment made it seem more like extensions - extend and preserve. That's the misunderstanding.

When I said it's wild to manipulate bytecode I means "wow that's a terrifying practice, I would hate to check that PR"

[-] mox 1 points 9 months ago* (last edited 9 months ago)

Fair enough. What threw me is that you said "bytecode", which is generally not used when referring to hardware machine instructions. My original comment is about patching the in-memory image of a running program or library, replacing machine instructions in order to intercept certain calls and extend their behavior.

I thought my phrase "compiled code" would convey this, but I guess nowadays bytecode-compiled languages are so common that some people assume that instead.

[-] huginn@feddit.it 1 points 9 months ago

Yeah and part of this is that the domain I've been working in for years now is very far from machine code, and I'm probably overly lax with my language here.

The result of being in very corporate app dev - I'm usually talking in much higher level abstractions. My bad on conflating bytecode and machine code