<span style="color:#323232;">volatile int blackhole;
</span><span style="color:#323232;">blackhole = 1;
</span><span style="color:#323232;">const int X = blackhole;
</span><span style="color:#323232;">const int Y = blackhole;
</span>
Compiler is forbidden to assume that X == 1 would be true. It’s also forbidden to assume that X == Y. const just 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 the hwreg address won’t magically change, but can’t assume the value read from that address won’t.
I try to keep my changes under 300-350 lines. Seems like a good threshold.
I’m still annoyed that Github doesn’t have good support for stacked diffs. It’s still not possible to say that one PR depends on a different one, and still has no ability to review and land them as a stack.
also iirc gitlab does offer something like this as a feature now with “merge trains” (though i’ve never really used it, usualy just go for the feature branch out of habit x) )
Making PRs against a feature branch still has the same problem.
Say you’re working on a major new feature, like adding a new log in flow. It’s a good idea to split it into many small changes: create initial log in form, implement user sessions, add SSO support, add “remember me” functionality, etc.
Those changes will likely depend on each other, for example adding the “remember me” checkbox requires the form to actually be built, and you probably don’t want to wait for the reviewers to review one change before continuing your work. This means you naturally end up with PRs that depend on each other in a chain.
Stacked PRs (or stacked diffs, stacked MRs, whatever your company calls it) means that:
The code review tool lets you specify dependencies between the PRs, for example the “remember me” PR depends on the initial login form implementation
It shows the dependencies visually in the UI, like a chain or tree
Changes can’t be landed until the PRs they depend on have been reviewed
There’s a way to land an entire stack
When you review a PR later in the stack, it doesn’t show any of the changes that were made earlier in the stack. Each PR focuses just on the changes in that part.
Making all your commits directly to a branch then creating a PR for the whole branch is similar, but reviews are a nightmare since it’s only a single review for the entire branch, which can be thousands of lines of code.
At my workplace, we use feature flags (essentially if statements that can be toggled on or off) rather than feature branches. Everyone works directly from the main branch. We use continuous deployment which means landed code is quickly pushed to production. New features are hidden behind a feature flag until they’re ready to roll out.
You can make a PR against your feature branch and have that reviewed. Then the final PR against your man branch is indeed huge, but all the changes have already been reviewed, so it’s just LGTM and merge that bad boy!
I suppose it is possible to have two PR that have changes that depend on each other. In general this just requires refactoring… typically making a third PR removing the circular dependency.
It sounds like your policy is to keep PR around a long time, maybe? Generally we try to have ours merged within a few days, before bitrot sets in.
Sorry, my comment was unclear. I didn’t mean a circular dependency, just PRs that have a chain of dependencies (e.g. PR 100 that depends on 99, that depends on 98, that depends on 97)
They’re usually not around for a long time, but there can be relatively large chains if someone is quickly adding new features.
I’m gonna make you break this up into multiple PRs before reviewing, but honestly, if your refactoring reduced the surface area by 20% I’m a happy man.
Love it when my coworkers reformat the code style, making it nigh impossible to understand what they actually changed, while greatly inflating their “contribution.”
It also blows away the git blame, making it hard to know who actually changed that one critical line of business logic 3 years ago that you need to understand before trying to fix some obscure bug.
I have one coworker who does this constantly and if you just looked at git blame, you’d think he wrote the entire code base himself.
Some decade and change ago I used to sell people Drupal installs at £200 a pop. They’d get a pretty secure codebase, the ability to add content through a gui and if necessary have customer accounts.
Pretty much what killed it as a business was everyone expected to be on the first page of Google because business advisers were telling them that sitebuilders should do SEO as standard.
Could be a “You can’t let John down now, we’re old pals, and a few people expect the site to work by the end of the week. He just needs a site like Facebook, but for gardeners”
Even just an afternoon of CSS would mean 2-4 hours, plus setting everything up, plus talking to the client, revisions, etc. You’ll quickly end up with 10h overall, even if the actual task is rather small. And that’s the optimistic case.
So you’ll end up with maybe 50€/h , probably more like 30. Not terrible, but that’s the optimistic case.
Got it. Animated background, GIFs, HTML 4.01 frames, marquee, privacy-friendly ads which are just GIFs linking to other websites. Did I go too far with the last one?
Stuff like this is part of why I dropped out of multimedia production in college, I only enjoy that stuff as a hobby for myself, doing it for other people is a creative nightmare lol
I mean you’re not wrong but I’d argue you can get more interesting cve’s using a higher more performant language such as c++. Where there are are ways to include CVE 's from C and introduce new ones to each level of your program using inheritance.
Here is the thing. Everybody, including attackers, is too overwhelmed with the boring variety of CVEs and unable to even think about the more interesting kind.
As soon as we make people stop generating those boring ones by the millions, our days will be way more interesting while we find and fix more complex CVEs. But anyway, those will also be way more common on C and C++ code than most other languages (maybe with an exception for JS).
EDIT: Oh, nevermind. I’ve forgotten that it’s using CVSS, which has a tendency to really overestimate the risk, so almost everyting is CCVE according to them :D
How exactly do you promote anything without saying “it’s better than the competition” in some way?
What else can you say about a programming language? There’s literally not a single point where a feature is not a comparison to the rest of the languages. There’s exactly one actual barrier: turing completeness. And that bar is so low, even Excel gets over it.
I really didnt put all that thought into it when I posted this (certainly wasn’t looking to evangelize Rust). It was mildly amusing (memory safety came to mind) and I needed a title somewhat related to the meme was really all there was to it.
The specifics of C’s design could barely be less important. In the 70s it was one of countless ALGOL derivatives churned out on-demand to support R&D projects like Unix.
Unix succeeded, but it could have been written in any of these languages. The C design process was governed by the difficulty of compiler implementation; everyone was copying ALGOL 68 but some of the features took too long to implement. If Dennis Ritchie had an extra free weekend in 1972, C might have a module system. But he didn’t, so it doesn’t.
That’s because Rust solves lots of issues caused by C, of course they are going to twist that knife and use it as a selling points. Humour is not bad, I’ve done lots of C and C++ and am not bothered a bit by it.
It doesn’t reduce the importance of the language at all, just sheds some light on safer languages, Rust or not.
Word, Rust shills are the most annoying and shitting of the programming language zealots I’ve seen since the Java Enterprise shilling of the early 200xs. WHat’s worse, their memes aren’t even good, unlike the JS memes.
C is the hardware language N°1 of the high-level languages. If you actually want to know and control what happens in the machine, you write in C. Rust, C++ and all the other abstractions are for people who do not understand how computers and computer memory work.
even if you write in assembly, you still may not actually understand what is going on in the machine since processors convert the instructions to “micro-ops”, and let’s not forget hardware bugs like those caused by speculative execution
I’ve written programs in C. I’ve written programs in assembly, for x86 and for microcontrollers. I’ve designed digital logic and programmed it into an FPGA. I’ve built digital logic circuits with transistors.
I’ll still take Go over C any day of the week. If I’m doing embedded, I’ll use TinyGo.
Programming languages are tools. I couldn’t care less about learning a new tool just for the sake of learning. My interest in learning tools is exclusively practical - if they help me do my work better.
I find functional languages interesting, but that’s because I find the underlying theory interesting and worth learning for its own sake, not because I actually care about the specific language it’s written in. Even then these days I’d rather learn about woodworking (which is currently my main hobby) than a programming paradigm I’m probably never going to use.
This is a misconception that’s common among beginner C programmers. They think C is high level assembly and don’t understand the kinds of optimisations modern compilers make. And they think they’re hardcore and don’t make mistakes.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.