I use LLMs in my toolchain, same as I also use compilers. In fact, I use the LLMs to generate end-to-end test suites, and the test running is automated as well.
There are many studies about this subject, but mind that complexity in code something different than 'complex' systems. You will need to dive into complexity science , but hard and 'soft' aspects should be taken into account when it comes to cyber security!
Worst things happen always when 2 or more systems are combined because each system might be simple on its own, yet a combination is always much more complex.
For something the the prior statement it is never a weird question to ask of there actually evidence of this or just it seems like it should be true so we believe it.
There are tons of things that seem like they would obviously be true, but it turns out they aren't.
System is more complex based on possible states it can have or inputs/outputs.
That is just maths here working. Two systems combined always will have more states and inputs/outputs.
There is nothing to check here as it can be proven purely by maths.
Complex systems having more attack surface are obviously less secure.
They might be less interesting for attackers if they have to scan huge attack surface like IPv6 vs IPv4 but no one is claiming IPv6 network is more secure.
Cyclomatic complexity is funny math, though. The article demonstrates how. They took a single function that makes state changes to an object, and scattered that logic across four different functions that make the same set of state changes. That’s all. This had adverse impact on the complexity of the system - the logic and behavior of the top level function are the same. It’s just as stateful and has just as many linearly independent code paths. They just got shuffled around to game the way that cyclomatic complexity treats function calls.
But in the process they created three additional functions to call. That means the overall system has more possible code paths, and introduces a need to think about what happens if they are ever called from somewhere other than the original entry point. Introducing ways to screw things up that did not previously exist is not reducing complexity and it is not increasing maintainability.
Your insistence that this somehow managed complexity is exactly why I wrote the top level comment cautioning people about how they interpret cyclomatic complexity. If you don’t understand what it’s actually measuring - not complexity, not really - then it will mislead you into bad decisions.
It’s not obvious to me because cyclomatic complexity is not a straightforward proxy for the number of systems that are being combined.
It’s also the case that some of the most common sources of vulnerabilities, such as SQL injection, introduce no additional cyclomatic complexity. Heck, buffer overflows are good for your cyclomatic complexity - those array bounds checks are all extra branches.
Buffer overflow checks are really only going to be a linear growth in CC. It's when things move towards exponential growth or higher that it gets really easy to introduce flaws of many kinds.
Now, it's probably not a direct correlation. I'd think security bugs are more likely from programmers that unintentionally raise CC without really realizing it. Aka, overreaching their own knowledge when simpler structures are avaliable.
Sure. It’s just that there’s also so much research that has found that cyclomatic complexity is theoretically ill-founded, and that it tends to underperform other ways of measuring complexity. Most notably, just counting lines of code. (Not per function, in total.)
I'd argue that assuming something is obvious without any empirical validation is the root of a huge number of misconceptions that humanity has historically had. There's a reason science suddenly started moving a lot faster after we moved past Aristotle and started measuring things in experiments.
Interesting! I have also implemented a version of TLSF for my (currently single-threaded) programming language. I also found it to be good for my use case (embedded / minimal code size). I'll compare it against yours. One improvement I did is some kind of preallocation for small blocks.
https://github.com/thomasmueller/bau-lang/blob/main/src/main...
For me (having written my own tiny 400 line chess engine, that now I'm not able to beat - sure I'm not a good player, but still), the reason to have Stockfish is not really to play against it, and then inevitably lose, but to use it to show which moves are best. I assume that's how most (hobby and professional) chess players use Stockfish nowadays.
You just try it yourself and go down the different lines. "Okay, Stockfish suggests this, but I wanted to do that, let's try my idea, oh, I didn't think of that response to my move". Etc., play along some lines, think about them. Sometimes it's obvious, other times it just sets up something far in the future you must be a grandmaster to see the subtlety of.
The Square One Chess channel on youtube turns this kind of exploration/commentary into quite digestible content, though the thumbnails are, like everything else these days, a little clickbaity.
It's been fun viewing for me and my chess-interested 9-year-old.
Stockfish has created entirely new lines in chess which people incorporate into their play. For instance an early pawn push to h4 is now common among chess pros. It's value was not recognized before Stockfish.
For some reason this question reminds me of all of the drama about Navier-Stokes from the last few days. Tangential to the ethical questions are tons of examples where in history when word gets out about a solution to a problem, not even the solution itself just rumors that there is a solution, suddenly competing solutions appear.
So maybe it matters like that? Just knowing that an oracle like stockfish is saying "this is the best move" may trigger pathways in your brain that promote understanding?
Right, but for a fan, it would work. Cars heat up mostly in direct sunlight. The solar panel could be wired directly to a fan. This would also prevent heat death of dogs and forgotten children.
Great. I'm also writing a new language with the same memory management idea (Perceus-style reference counting / ownership). My language [1] is not functional and currently lacks multi-threading and networking, so there are big differences. But I really like the moto "easy to use memory safety without tracing GC".
There are studies that show cancer risk is higher near a nuclear plant. The reason is likely that poorer people live near a nuclear plant; it's _probably_ not because of radiation. My point is: Just having nuclear plants nearby lowers the market price of the property. If there _is_ an accident, the market price of many properties drops to zero. That's why no insurance company will insure the full risk of a nuclear accident: the remaining risk is on the population and land owners. (Property owners may get compensated - paied by taxes.)
In Switzerland there is now again the idea to build nuclear plants, by some (I'm pretty sure the political party that initiated this gets a lot of money from the nuclear lobby - unfortunately the money flow is intransparent in Switzerland.) A recent study in Switzerland [1] has shown nuclear plant are not competitive with solar, wind, hydro, and batteries, not even taking into account that accidents are not fully insured.
Whether or not that's the case, the problem is that if you put together all the nuclear, solar, wind and hydro we can manage, we will still have less energy than what we get easily with oil.
I don't get why they even compete against each other: we need as much as we can of everything that we can.
You can only spend a dollar once, so any money going into nuclear won't go into solar, wind, or hydro - which have far better payoff when it comes to reducing CO2 emissions.
Solar produces power even on cloudy days. So the simple answer is you overbuild solar to produce enough power even on cloudy days.
That requires about a 10x overbuild. In reality you do about a 3x overbuild, exporting to the cloudy places in the rest of Europe when you are cloudy and importing from the sunny places when you are cloudy. It's sometimes cloudy in most of Europe but it's never cloudy in all of Europe.
Then you do a similar thing with wind. Wind and solar are anti-correlated.
You can also make it easier by not shutting down existing nuclear. New nuclear is horribly expensive, but keeping existing plants running is cost effective.
> the simple answer is you overbuild solar to produce enough power even on cloudy days
Which in practice means you put down gas turbines while that overcapacity comes online. Solar + wind + nuclear makes the most sense for decarbonisation amidst demand growth.
So how do you propose the energy is supplied in the 20 years it would take for the first nuclear reactors to become offline? Let me guess: gas turbines?
So we either fully rely on gas turbines for the base load for the next 20 years, orrrr we rely on gas turbines during the few days it is both dark and wind-less for the next 20 years.
> That overcapacity can come online a lot faster than new nuclear can be built
No, it can’t. We’re already building solar as fast as we can, the economics drive that. The marginal supply will come from something else. That margin is what we’re talking about, not the bulk. Most of the new energy will come from solar. But we can’t manufacture and install PVs quickly enough, particularly over the next 20 years, to close the gap.
We have statistics on solar performance at the huge countries levels. And it shows that, in reality, we're talking about 20x overbuild. Not 3x and not even 10x. And there is no way around it.
Wind and solar anti-correlation does not lowering this number. Number is still 20x, just it's more rare now, but it is still there.
it'll still not work if you bothered to look at energy charts data for Europe. Plenty of 3+days of low capacity factor for solar+wind. No amount of realistic oversupply will save you there. "Wind and solar are anti-correlated." - just weakly, if you zoom in at hourly/minute production situation is different. New nuclear makes sense if you hate gas.
Those are all less safe than nuclear. It's a simple fact, look it up.
All the places that can use hydro already do. Oh, and it's pretty damaging to the environment, it turns out.
Wind and solar are pretty cool, but also unreliable, so it's not so clear that they're really cheaper after you account for overprovisioning and storage costs.
If only there was a safe and reliable source of energy we could use to complement them...
I don't have a strong opinion what is better in this case, but my view is:
> document and express intent clearly
Arguably, the void* does that as well?
> Any seasoned C++ developer seeing this knows what this reinterpret_cast means.
Same for void*?
> it's a bit more text to read
If you have to call it many times, this adds up.
> Some might also say it complexifies and uglifies the code
I think the point is that it adds security, which the other options don't. And, it doesn't add complexity on the caller, but only at one place: the implementation.
Sort of (I mean: seeing void* and a size probably means 'arbitrary sequence of bytes' or something like that, but well it's void* so it can be like anything whereas with std::span you get more of a hint what's going on just based on the type), but not at the callsite which is what the author is referring to when it's about reinterpret_cast.
> I think the point is that it adds security, which the other options don't
Imo span also does that to some extent, but already when writing the code and not afterwards in e.g. static analysis. E.g. if I get an std:span<const char> I'd have to do counterintuitive things to misuse it. Annotating a void* still leaves it a void* which I then need to cast to char* if I think that's what it is intended.
Don't get me wrong: I've written my fair share of void* but these days I really feel like there's almost always a better thing which can be used instead. Though I do admit that since I've written and consumed a lot of code with such alternatives I'm not hindered by readability/apparent complexity of it anymore but I understand that's not the same for everyone.
> whereas with std::span you get more of a hint what's going on just based on the type
You don’t if it’s a span of bytes (or equivalent).
Encoding the length in a span is a meaningful thing. But the fact that it holds a random memory pointer labeled “byte” instead of “void” doesn’t change anything.
How do you figure? The type is a pointer to quite literally anything, including nothing (ie a pointer that cannot be dereferenced). If you're working with bytes, indicate this with the type.
2. The functions in question here operate on raw memory. void * conveys the same information as byte *. It’s not untyped vs typed. It’s two different types that convey the same information but require slightly different mechanics to obtain.
3. The author explained his reasoning for preferring void * over byte * (or uint8_t *)
4. A reference also isn’t the same thing as a pointer in C++
reply