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
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”
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.
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
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
Just wait until you learn about machine code. :)
I do have a degree in this. I am aware.
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”
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.
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
Ah, corporate work. I hope they’re treating you well.
Different strokes - some would find what I’m doing hell. I personally love it.
The 260k/yr salary may help alleviate the pain.