I don’t think that casting a range of bits as some other arbitrary type “is a bug nobody sees coming”.
C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.
That’s why I love C++
removed by mod
Why use a strongly typed language at all, then?
Sounds unnecessarily restrictive, right? Just cast whatever as whatever and let future devs sort it out.
$myConstant = ‘15’;
$myOtherConstant = getDateTime();
$buggyShit = $myConstant + $myOtherConstant;Fuck everyone who comes after me for the next 20 years.
“C++ compilers also warn you…”
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it’s compiled?
I’ve written a little bit of C++ decades ago, and since then I’ve worked alongside devs who worked on C++ projects. I’ve never seen a codebase that didn’t produce hundreds if not thousands of lines of warnings when compiling.
My team uses the -Werror flag, so our code won’t compile if there are any warnings at all.
A production code should never have any warning left. This is a simple rule that will save a lot of headaches.
Neither should your development code, except for the part where you’re working on.
I put -Werror at the end of my makefile cflags so it actually treats warnings as errors now.
You shouldn’t have any warnings. They can be totally benign, but when you get used to seeing warnings, you will not see the one that does matter.
I know, that’s why it bothered me that it seemed to be “policy” to just ignore them.
I mostly see warnings when compiling source code of other projects. If you get a warning as a dev, it’s your responsibility to deal with it. But also your risk, if you don’t. I made it a habit to fix every warning in my own projects. For prototyping I might ignore them temporarily. Some types of warnings are unavoidable sometimes.
If you want to make yourself not ignore warnings, you can compile with
-Werrorif using GCC/G++ to make the compiler a pedantic asshole that doesn’t compile until you fix every fucking warning. Not advisable for drafting code, but definitely if you want to ship it.Except when you have to cast size_t on int and vice versa (for “small” numbers). I hate that warning.
Ideally? Zero. I’m sure some teams require “warnings as errors” as a compiler setting for all work to pass muster.
In reality, there’s going to be odd corner-cases where some non-type-safe stuff is needed, which will make your compiler unhappy. I’ve seen this a bunch in 3rd party library headers, sadly. So it ultimately doesn’t matter how good my code is.
There’s also a shedload of legacy things going on a lot of the time, like having to just let all warnings through because of the handful of places that will never be warning free. IMO its a way better practice to turn a warning off for a specific line.. Sad thing is, it’s newer than C++ itself and is implementation dependent, so it probably doesn’t get used as much.
I’ve seen this a bunch in 3rd party library headers, sadly. So it ultimately doesn’t matter how good my code is.
Yeah, I’ve seen that too. The problem is that once the library starts spitting out warnings it’s hard to spot your own warnings.
Yuuup. Makes me wonder if there’s a viable “diaper pattern” for this kind of thing. I’m sure someone has solved that, just not with the usual old-school packaging tools (e.g. automake).
0 in our case, but we are pretty strict. Same at the first place I worked too. Big tech companies.
Ignoring warnings is really not a good way to deal with it. If a compiler is bitching about something there is a reason to.
A lot of times the devs are too overworked or a little underloaded in the supply of fucks to give, so they ignore them.
In some really high quality codebases, they turn on “treat warnings as errors” to ensure better code.
I know that should be the philosophy, but is it? In my experience it seems to be normal to ignore warnings.
Depends on the age of the codebase, the age of the compiler and the culture of the team.
I’ve arrived into a team with 1000+ warnings, no const correctness (code had been ported from a C codebase) and nothing but C style casts. Within 6 months, we had it all cleaned up but my least favourite memory from that time was “I’ll just make this const correct; ah, right, and then this; and now I have to do this” etc etc. A right pain.
So, did you get it down to 0 warnings and manage to keep it there? Or did it eventually start creeping up again?
I’m not the person you’re asking but surely they just told the compiler to treat warnings as errors after that. No warnings can creep in then!
deleted by creator
I work on one of the larger c++ projects out there (20 to 50 million lines range) and though I don’t see the full build logs I’ve yet to see a component that has a warning.
C lets you shoot yourself in the foot.
C++ lets you reuse the bullet.
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 that the power cosmic would never, without sufficient warning, pull someone inside-out. 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.
Aand what is wrong with that?
Did you know 100% of C programmers were sex offenders?
The problem is that it’s undefined behavior. Quake fast inverse square root only works before the types just happen to look that way. Because the floats just happens to have that bit arrangement. It could look very different on other machines! Nevermind that it’s essentially always exactly the same on most architectures. So yeah. Undefined behavior is there to keep your code usable even if our assumptions about types and memory change completely one day.
There are no medals waiting for you by writing overly clever code. Trust me, I’ve tried. There’s no pride. Only pain.
Debugging code is always harder that writing it in the first place. If you make it as clever as you can, you won’t be clever enough to debug it.
Some junior will call it ”skill issues” and then write the most unreadable code ever.
It really depends on your field. I’m doing my master’s thesis in HPC, and there, clever programming is really worth it.
Clever as in elegantly and readable or clever as in a hack that abuses a bug/feature and you need to understand the intricacies to understand half of it?
Honestly, also the latter. If you are using hundreds of thousands of cores for over 100h, every single second counts.
Well as long you know what you’re doing and weigh the risks with the benefits you’re probably ok.
In my experience in the industry, there’s little benefit in pretending you’re John Carmack writing fast inverse square root. Understanding what you wrote 6 months ago outweighs most else.
But I must o p t i m i z e! ó_ò
Yes, let’s spend two hours on figuring out optimal values of preallocating a vector for your specific use-case. It’s worth the couple of microseconds saved! Kleinvieh macht auch Mist.
Not only that, but everyone who sees that code later is going to waste so much time trying to understand it. That includes future you.
That what comments and documentation are for.
A yes, comments.
int flubTheWozat(void *) { for (int i=0; i<4; i++) { lfens += thzn[i] % ugy; // take mod of thnz[i] with ugy and add to lefens. } return (lfens % thzn[0]) == 4; // return if it's 4ish }Haha, meaningful, informative comments that make it easier to understand the code of course. ;)
I actually do like that C/C++ let you do this stuff.
Sometimes it’s nice to acknowledge that I’m writing software for a computer and it’s all just bytes. Sometimes I don’t really want to wrestle with the ivory tower of abstract type theory mixed with vague compiler errors, I just want to allocate a block of memory and apply a minimal set rules on top.
100%. In my opinion, the whole “build your program around your model of the world” mantra has caused more harm than good. Lots of “best practices” seem to be accepted without any qualitative measurement to prove it’s actually better. I want to think it’s just the growing pains of a young field.
Even with qualitative measurements they can do stupid things.
For work I have to write code in C# and Microsoft found that null reference exceptions were a common issue. They actually calculated how much these issues cost the industry (some big number) and put a lot of effort into changing the language so there’s a lot of warnings when something is null.
But the end result is people just set things to an empty value instead of leaving it as null to avoid the warnings. And sure great, you don’t have null reference exceptions because a value that defaulted to null didn’t get set. But now you have issues where a value is an empty string when it should have been set.
The exception message would tell you exactly where in the code there’s a mistake, and you’ll immediately know there’s a problem and it’s more likely to be discovered by unit tests or QA. Something that’s an value that’s supposed to be set may not be noticed for a while and is difficult to track down.
So their research indicated a costly issue (which is ultimately a dev making a mistake) and they fixed it by creating an even more costly issue.
There’s always going to be things where it’s the responsibility of the developer to deal with, and there’s no fix for it at the language level. Trying to fix it with language changes can just make things worse.
For this example, I feel that it is actually fairly ergonomic in languages that have an
Optiontype (like Rust), which can either beSomevalue or no value (None), and don’t normally havenullas a concept. It normalizes explicitly dealing with the None instead of havingnullor hidden empty strings and such.I just prefer an exception be thrown if I forget to set something so it’s likely to happen as soon as I test it and will be easy to find where I missed something.
I don’t think a language is going to prevent someone from making a human error when writing code, but it should make it easy to diagnose and fix it when it happens. If you call it null, “”, empty, None, undefined or anything else, it doesn’t change the fact that sometimes the person writing the code just forgot something.
Abstracting away from the problem just makes it more fuzzy on where I just forgot a line of code somewhere. Throwing an exception means I know immediately that I missed something, and also the part of the code where I made the mistake. Trying to eliminate the exception doesn’t actually solve the problem, it just hides the problem and makes it more difficult to track down when someone eventually notices something wasn’t populated.
Sometimes you want the program to fail, and fail fast (while testing) and in a very obvious way. Trying to make the language more “reliable” instead of having the reliability of the software be the responsibility of the developer can mean the software always “works”, but it doesn’t actually do what it’s supposed to do.
Is the software really working if it never throws an exception but doesn’t actually do what it’s supposed to do?
It is fair to have a preference for exceptions. It sounds like there may be a misunderstanding on how
Optionworks.Have you used languages that didn’t have
nulland hadOptioninstead? If we look at Rust, you can’t forget not to check it: it is impossible to get theSomeof anOptionwithout dealing with theNone. You can’t forget this. You can mess up in a lot of other ways, but you explicitly have to decide how to handle that potentialNonecase.If you want it to fail fast and obvious, there are ways to do this. For example you, you can use the
unwrap()method to get the containedSomevalue or panic if it isNone,expect()to do the same but with a custom panic message, the?operator to get the containedSomevalue or return the function withNone, etc. Tangentially, these also work forResult, which can beOkorErr.It is pretty common to use these methods in places where you always want to fail somewhere that you don’t expect should have a
Noneor where you don’t want your code to deal with the consequences of something unexpected. You have decided this and live with the consequences, instead of it implicitly happening/you forgetting to deal with it.
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won’t just “let you” do the exact same fucking thing if you type the
unsafekeyworddeleted by creator
That’s not what I meant. I understand that rust forces things to be more secure. It’s not not like there’s some guarantee that rust is automatically safe, and C++ is automatically unsafe.
I want you to imagine that your comments in this thread were written by an engineer or a surgeon instead of a programmer.
Imagine an engineer saying “Sure, you can calculate the strength of a bridge design based on known material properties and prove that it can hold the design weight, it that doesn’t automatically mean that the design will be safer than one where you don’t do that”. Or “why should I have to prove that my design is safe when the materials could be defective and cause a collapse anyway?”
Or a surgeon saying “just because you can use a checklist to prove that all your tools are accounted for and you didn’t leave anything inside the patient’s body doesn’t mean that you’re going to automatically leave something in there if you don’t have a checklist”. Or “washing your hands isn’t a guarantee that the patient isn’t going to get an infection, they could get infected some other way too”.
A doctor or engineer acting like this would get them fired, sued, and maybe even criminally prosecuted, in that order. This is not the mentality of a professional, and it is something that programming as a profession needs to grow out of.
“washing your hands isn’t a guarantee that the patient isn’t going to get an infection, they could get infected some other way too”.
Every single doctor should know this yes.
It seems people are adding a sentence I didn’t say “rust can be unsafe and thus we shouldn’t try” on top of the one I did say “programmers should be aware that rust doesn’t automatically mean safe”.
You didn’t say “programmers should be aware that rust doesn’t automatically mean safe”. You said:
People just think that applying arbitrary rules somehow makes software magically more secure…
You then went on to mention
unsafe, conflating “security” and “safety”; Rust’s guarantees are around safety, not security, so it sounds like you really mean “more safe” here. But Rust does make software more safe than C++: it prohibits memory safety issues that are permitted by C++.You then acknowledged:
I understand that rust forces things to be more secure
…which seems to be the opposite of your original statement that Rust doesn’t make software “more secure”. But in the same comment:
It’s not not like there’s some guarantee that rust is automatically safe…
…well, no, there IS a guarantee that Rust is “automatically” (memory) safe, and to violate that safety, your program must either explicitly opt out of that “automatic” guarantee (using
unsafe) or exploit (intentionally or not) a compiler bug.…and C++ is automatically unsafe.
This is also true! “Safety” is a property of proofs: it means that a specific undesirable thing cannot happen. The C++ compiler doesn’t provide safety properties[1]. The opposite of “safety” is “liveness”, meaning that some desirable thing does happen, and C++ does arguably provide certain liveness properties, in particular RAII, which guarantees that destructors will be called when leaving a call-stack frame.
[1] This is probably over-broad, but I can’t think of any safety properties C++ the language does provide. You can enforce your own safety properties in library code, and the standard library provides some; for instance, mutexes have safety guarantees.
Then you should probably be a little more explicit about that, because I have never, not once in my life, heard someone say “well you know wearing a seatbelt doesn’t guarantee you’ll survive a car crash” and not follow it up with “that’s why seatbelts are stupid and I’m not going to wear one”.
We need to stop attaching shit someone doesn’t say to something they did. It makes commutating hostile and makes you an asshole.
Edit: okay that was a bit rude. But it’s so frustrating to say something and then have other people go “that means <this other thing you didn’t say>!!!11!”
deleted by creator
No there is not. Borrow checking and RAII existed in C++ too and there is no formal axiomatic proof of their safety in a general sense. Only to a very clearly defined degree.
In fact, someone found memory bugs in Rust, again, because it is NOT soundly memory safe.
Dart is soundly Null-safe. Meaning it can never mathematically compile null unsafe code unless you explicitly say you’re OK with it. Kotlin is simply Null safe, meaning it can run into bullshit null conditions.
The same thing with Rust: don’t let it lull you into a sense of security that doesn’t exist.
Borrow checking…existed in C++ too
Wat? That’s absolutely not true; even today lifetime-tracking in C++ tools is still basically a research topic.
…someone found memory bugs in Rust, again, because it is NOT soundly memory safe.
It’s not clear what you’re talking about here. In general, there are two ways that a language promising soundness can be unsound: a bug in the compiler, or a problem in the language definition itself permitting unsound code. (
unsafechanges the prerequisites for unsoundness, placing more burden on the user to ensure that certain invariants are upheld; if the code upholds these invariants, but there’s still unsoundness, then that falls into the “bug in Rust” category, but unsoundness of incorrectunsafecode is not a bug in Rust.)Rust has had both types of bugs. Compiler bugs can be (and are) fixed without breaking (correct) user code. Bugs in the language definition are, fortunately, fixable at edition boundaries (or in rare cases by making a small breaking change, as when the behavior of
extern "C"changed).Have you heard about cve-rs?
https://github.com/Speykious/cve-rs
Blazingly fast memory failures with no unsafe blocks in pure Rust.
Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity
Edit 2: Before the Cult of Rust™ sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I’m not a C absolutist, I am just telling you to be aware of the limitations of your tools
It’s neither arbitrary nor magic; it’s math. And
unsafedoesn’t disable the type system, it just lets you dereference raw pointers.You don’t even need
unsafe, you can just take user input and execute it in a shell and rust will let you do it. Totally insecure!Rust isn’t memory safe because you can invoke another program that isn’t memory safe?
My comment is sarcastic, obviously. The argument Kairos gave is similar to this. You can still introduce vulnerabilities. The issue is normally that you introduce them accidentally. Rust gives you safety, but does not put your code into a sandbox. It looked to me like they weren’t aware of this difference.
You don’t need
unsafeto write vulnerable code in rust.Yes I know there are other ways to do it. That’s one way.
I don’t know rust, but for example in Swift the type system can make things way more difficult.
Before they added macros if you wanted to write ORM code on a SQL database it was brutal, and if you need to go into raw buffers it’s generally easier to just write C/objc code and a bridging header. The type system can make it harder to reason about performance too because you lose some visibility in what actually gets compiled.
The Swift type system has improved, but I’ve spent a lot of time fighting with it. I just try to avoid generics and type erasure now.
I’ve had similar experiences with Java and Scala.
That’s what I mean about it being nice to drop out of setting up some type hierarchy and interfaces and just working with a raw buffers or function pointers.
What do you mean I’m not supposed to add 0x5f3759df to a float casted as a long, bitshifted right by 1?
//what the fuck?They know. It’s a comment from the code.
I don’t know which is worse. Using C++ like lazy C, or using C++ like it was designed to be used.
An acquaintance of mine once wrote a finite element method solver entirely in C++ templates.
As it should be. Airbags should go off when you crash, not when you drive near the edge of a cliff.
C++: all the footguns you need plus a lot more that you never imagined in a single language
C++ is kinky that way. You can consent to all manner of depraved programming patterns. Great for use in personal life, but maybe not appropriate for the office.
But does it have cargo-mommy :P
https://github.com/Shadlock0133/cargo-vibe
I thought it was a joke, but this is actually viable and even configurable
By default,
cargo-vibewill, on success, vibe full strength for 3 seconds.You can change that by setting
CARGO_VIBE_PATTERNenvironment variable. For example, to set it vibe for 1.5 second on 20% strength, you can do:CARGO_VIBE_PATTERN="0.2 1.5s" cargo vibe <cmd>You can also set full patterns of vibes to run, by separating them with slashes
/. Here is one example:CARGO_VIBE_PATTERN="0.4 1s/0.6 1s/0.8 0.75s/1.0 0.25s"Wait, there’s more! https://github.com/funkeleinhorn/cargo-shock
To let Cargo Shock trigger your shock collar use:
cargo shock buildTo use it everytime you can
alias cargo="cargo shock".Cargo Shock can also be combined with other tools like Cargo Mommy and Cargo Vibe like this:
cargo mommy vibe shock build ...And they have a really slick site: https://openshock.org/
TIL there’s more than one kind of “vibe” coding.
My issue is C++ will “let me do it”, and by that I mean “you didn’t cast here (which is UB), so I will optimize out a null check later, and then segfault in a random location”
Always check your programs on -O0 or pay the price
Shit gets really fun when you find out your code is a edge case for compiler optimization and should never be optimized away (although this is very very rare for -O2)
