Some people hate that C is dangerous, but personally I like its can-do attitude.
“Hey C, can I write over the main function at runtime?”
Sure, if you want to, just disable memory protection and memcpy whatever you want there! I trust you.
It’s a great attitude for a computer to have.
C is dangerous like your uncle who drinks and smokes. Y’wanna make a weedwhacker-powered skateboard? Bitchin’! Nail that fucker on there good, she’ll be right. Get a bunch of C folks together and they’ll avoid all the stupid easy ways to kill somebody, in service to building something properly dangerous. They’ll raise the stakes from “accident” to “disaster.” Whether or not it works, it’s gonna blow people away.
C++ is dangerous like a quiet librarian who knows exactly which forbidden tomes you’re looking for. He and his… associates… will gladly share all the dark magic you know how to ask about. They’ll assure you, oh no no no, the power cosmic would never pull someone inside-out, without sufficient warning. They don’t question why a loving god would allow the powers you crave. They will show you which runes to carve, and then, they will hand you the knife.
You have a talent for metaphor.
Rust is like a paranoid overprotective guardian. A “mom friend”, of sorts. Always the designated driver of the group, keeps you from staying up too late, stops you from eating things that might be choking hazards without proper precaution, and so on and so forth. You’ll never meet a person more concerned with your health and safety – until, that is, you say the magic word “unsafe”. Suddenly the alter ego that their hypnotist implanted gets activated, and their entire demeanor changes on a dime. BMX biking? Bungee jumping? Inline assembly? Sounds like a great idea! Let’s go, man! Rules are for NERDS! Then the minute the unsafe block ends, they’re back to normal, fully cognizant of the adventure they just went on and thinking absolutely nothing of it. “Whitewater rafting with you guys was really fun, especially the part where Jason jumped into the water and I went after him! I’d best go get the first aid kit, though – that scrape he got when he did that looks like it might get infected. I know he said it didn’t hurt, but better safe than sorry!”
They kinda scare you when they’re like that, if you’re honest.
I tried thinking of one for Rust, and ‘the mom friend with a safeword’ is alarmingly accurate.
The secret basement is never locked. It’s fine to go down there, alone. You’ll only be scarred on the inside.
It’s when you go down together that all bets are off.
Agreed. It’s a very adult approach. C hands you a running chainsaw and whatever happens after that is your responsibility. It is also your responsibility to decide when it’s not the right time to use C.
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.
You can do that in memory safe languages too. Kotlin extension functions, for example.
Extension functions are not the same at all. Extension functions are syntactic sugar. For example if you have an extension function like
public static class ObjectExtension { public static void DoSomething(this object input) { } }You can call that function on an object by doing
object.DoSomething()- Yes. But underneath it’s the same as doingObjectExtension.DoSomething(object)That function does not actually become part of the object, and you can’t use it to override existing functions
A closer example of how to do something similar in a memory safe language would be - in C# - using something like Castle DynamicProxy - where through a lot of black magic - you can create a DynamicProxy and fool the CLR into thinking it’s talking to an object, while it’s actually talking to a DynamicProxy instead. And so then you can actually intercept invocations to existing methods and overrule them
Generally overruling existing functions at runtime is not that easy
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
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.
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.
That actually sounds pretty cool
Sometimes what I’d like to be able to do is treat part of an app as a core and the rest like user provided scripts, but written and evaluated in the host language and not running an embedded scripting language like lua with all the extra burden.
E.g. you have an image editor and you want the user to be able to write native functions to process the image. Or you have a game engine and you want to inject new game code from the user without the engine being a compiler or the game logic being bundled scripts.
You’d probably use a different approach for that. Like you’d make your program dynamically load all the .dlls in a “plugins” folder -
Then you’d provide some plugin interface for the users to create plugins, for example:
public interface IImageEditorPlugin { public void BeforeImageEdit(int[,] imageData); public void AfterImageEdit(int[,] imageData); }And then you can load plugin classes from all the dlls with dependency injection, and execute them though something like this:
public class ImageEditor(IEnumerable<IImageEditorPlugin> plugins) { public void EditImage(int[,] imageData) { foreach (var imageEditorPlugin in plugins) { imageEditorPlugin.BeforeImageEdit(imageData); // Do internal image edit function imageEditorPlugin.AfterImageEdit(imageData); } } }This is a very simple example obviously, normally you’d send more meta-data to the plugins, or have multiple different interfaces depending on the kinda plugin it is, or have some methods to ask plugins when they’re suitable to be used. But this way a user can provide compiled versions of their plugins (in the same language as the core application) - instead of having to provide something like lua scripts
I loved C/C++ in university, finally the damn piece of rock we forced into thinking was doing exactly what I told him to do, no more and no less.
This is actually how you should declare something that you will never change, but something might change externally, like an input pin or status register.
Writing to it might do something completely different or just crash, but you also don’t want the compiler getting creative with reads; You don’t want the compiler optimizing out a check for a button press because the “constant” value is never changed.
Yeah I stumbled on this too. Surely the joke should be const mutable, not const volatile.
If you have a memory-mapped peripheral where there’s a readonly register, I could see it being
const volatile.What is the context of the original image?
Could be simply a way to make sure the button never moves again. I would have simply taken out the knob, personally.
It could be about sending a message.
A missing knob is easy to fix. Bolting a wrench to the housing holding the knob in place is very explicit. It screams “don’t touch”
Idk to me it screams “solve this puzzle and win a free wrench” /s
I like the creativity of it, and it does solve the problem in a way that’s user-safe. I thought of removing the knob because that’s what I do with my barbecue as I store items on the grill when not in use. Remove knobs, put on grill, close barbecue, cover.
Idk to me it screams “solve this puzzle and win a free wrench” /s
What too many video games does to a mfer 😄
I work on industrial controls. Very likely that the switch is momentary, meaning it’ll go back when released.
Sometimes there’s a little piece of plastic in them to remove the momentary setting, but this works too lol. Fuck it, it’s maintenance.
That actually makes sense, thank you for the tidbit!
Still kind of an overkill solution, but at least it’s funny
I’m sure they just needed a way to lock the selector knob to the primary position, and didn’t want to rewire it.
Drills and taps two holes, adds a metal strap, and sacrifices a tool to save a 5 minute fix of jumping over the contact with a 2" piece of wire lmfao
A lot of people won’t touch electrical, and the problem with modifying the wiring is you need to be able to clearly document or show what was changed in case it needs to be reversed later.
This is ugly, but it’s immediately obvious how to reverse it to anyone who looks at it. And that pipe wrench probably wasn’t being used anymore anyways. I doubt they tapped the holes, those are probably just self-tap screws that both drilled the hole and cut the thread as they screwed in. No one will call this an elegant solution, but if it works it works.
“documenting the change” is a pipe dream.
If you’ve ever worked in maintenance, active production, etc, you’ll be lucky to even have schematics. And trust me, there are a lot of hacks of people fucking with controls for 30+ years straight that soooo much of it is full of “fixes” like this, whether it’s something pushing a button in, or pieces of metal instead of fuses, or wires jumping over what’s “in the way” like whole safety systems and e-stops, contactors forced to run, etc etc etc.
Just spin the pipe wrench open and slide it up then you can switch it back real quick.
Thank you for watching this OHSA message on bad lockout procedure, now back to your regularly scheduled programming.
Context is very interesting: https://stackoverflow.com/questions/4592762/difference-between-const-const-volatile
Const flags to the code that you cannot change the value, and volatile flags to the compiler that it’s not safe to change the value.
Volatile means that the value should be read each time its accessed. It can’t be cached in a register or the read be otherwise assumed and optimized away or the instructions around its access be reordered.
Is this wrench made of chocolate?
Forbidden chocolate
const…ish
constn’t
I’m giggling like a kid that finally got the candy from the top drawer. It’s beautiful.
Looks like they didn’t want anybody using the secondary tank. Probably haven’t had time to pull Dave’s body out yet.
laughs in evil PLC programmer A little forces enabled, a change here, and maybe just move this wire over there while I am at it…
I’ve used it in the past when having flash memory blocks that could change but you need the compiler to put them into flash memory and not RAM. It’s mainly to get the compiler to stop assuming that it can optimize using the default value.
This has 14 (Peter Cline) energy here for the photo. Keep the dials at zero!
I see a Java programmer evolves into a C programmer
When you set the port speed to no negotiate.
volatile int blackhole; blackhole = 1; const int X = blackhole; const int Y = blackhole;Compiler is forbidden to assume that
X == 1would be true. It’s also forbidden to assume thatX == Y.constjust means the address and/or the data at the address is read only.const volatile int* const hwreg;-> “read only volatile value at read only address hwreg”. Compiler can assume thehwregaddress won’t magically change, but can’t assume the value read from that address won’t.
