Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.
So when is WG14 standardising modern hardware into the C standard?
Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?
No, it doesn't "cancel out", but courts (not law) absolutely do "both sides" issues.
Rebukes for "winning" sides of a suit are relatively common.
For example, here's a case in Australia where the defence are criticised for over-reliance on AI, where the defendant was still found innocent by reason of insanity. [0] Most of the ruling is criticisms for the "winning" party.
We already have a huge number of safety regulations for cars, that take into account all these various things. There's also insurance that covers flood damage and cars. These are the things that red flag something you need to test, if you want to take over driving the car.
"volatile" tells the compiler it is _not_ safe to optimise away any read or write, so it can't just optimise that section away at all.
> An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.
A compliant compiler is only free to optimise away, where it can determine there are no side-effects. But volatile in 5.1.2.3 has:
> Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects.
Yes, but undefined behaviour is undefined behaviour, and that behaviour can legally be that the code is not emitted at all, volatile (or any other side effect) or not. (and compilers do reason about undefined behaviour when optimising, so this isn't necessarily a completely theoretical argument, though I don't know whether the in compiler's actual logic which of 'don't optimise volatile' or the 'do assume undefined behaviour is impossible and remove code that definitely invokes it' would 'win', or whether there's any current compiler that would flag this as unconditionally undefined behaviour in the first place).
GCC calls that out [0] - volatile means things in memory may not be what they appear to be, and that there are asynchronous things happening, so something that may not appear to be possible, may become so, because volatile is a side-effect.
So about the only optimisation allowed to happen, is combining multiple references.
Clang is similar:
> The compiler does not optimize out any accesses to variables declared volatile. The number of volatile reads and writes will be exactly as they appear in the C/C++ code, no more and no less and in the same order.
This is all assuming that the code is not invoking undefined behaviour. If the code is invoking undefined behaviour, GCC and clang are both well within their rights to say 'none of the rest of our documentation applies' (and have historically done so on bug reports).
I've mentioned elsewhere the standards, and compilers as well, disagreeing with you here.
But feel free to run against the various compilers through godbolt. [0] They won't optimise the branch away. Access to a volatile, must be preserved, in the order that they exist. No optimisation, UB or otherwise, is allowed to impede that. Because an access is a side-effect.
> Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.
I quoted the C standard, first. Not compiler behaviour.
I showed where it requires the compiler not to optimise this.
How about, instead of one-line throwaway disagreements, you point out where they are permitted to do this, instead?
The compiler is required to not optimise out reads/writes through volatile. That's unrelated to code also having UB: you can't sprinkle volatile through arbitrary UB and suddenly have it be defined.
> A compliant compiler is only free to optimise away, where it can determine there are no side-effects
A compliant compiler is also allowed to assume UB cannot occur.
> that can easily be solved by a minute or two on godbolt...
Unfortunately it's not that simple when it comes to UB. If the snippet in question does in fact exhibit UB then there's no guarantee whatever Godbolt shows will generalize to other programs/versions/compilers/environments/etc.
Also, at behavioural edges what you'll see on Godbolt is compiler bugs. So you learn nothing about what should happen.
All popular modern C++ compilers have known bugs and while I'm sure there are C compilers with no known bugs that will be because nobody tested very hard.
No, claim A is 'x may be removed by a conforming C compiler'. Whether any given version of a given compiler actually does so in any given circumstance is a different question (the answer being: probably not, because while this is undefined behaviour it's not likely something that is going to be flagged as such by a compiler's optimizer. Also, from some testing with GCC and forcing a null point dereference, it seems like volatile at least does win in that case with the current version of it x86, and it dutifully emits the null pointer dereference and then the 'ud2' instruction instead of the rest of that execution path).
I made the weaker claim that x can be removed. This is something I could prove with compiler output but I would have to find a compiler willing to make this optimization which is not something I can guarantee.
When compiler decides something is UB aka "result of this code is not defined and could be any" it selects the most performant version of undefined behavior - doing nothing by optimizing code away.
The compiler is not free to remove accesses to something marked volatile - its defined as a side-effect.
Volatile means something else may be acting here. Something else may install anything into the register at any time - and every time you access.
The compiler is required to preserve the order of accesses. In almost every C compiler, today, there are almost no optimisations the moment a volatile is introduced, for this reason.
If code has undefined behavior, the entire execution path that leads to that UB has no assigned semantics in the C model. So there are no volatile accesses in this code according to the C abstract machine - the entire execution path is UB, so it can be assumed it doesn't happen at all.
> An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine
The execution path has unknown side effects, and so the execution path must be strictly followed. That's uh... The entire point of that section in the C standard. Its why volatile is called out, in the semantic model for the abstract machine.
Otherwise... Why call it out, at all? It must be strictly followed, not lazily, as in other areas of the standard.
UB supersedes volatile, once the compiler hits UB then all bets are off. Compilers can and do optimize out UB branches, which is almost never what you want... yet here we are.
>> The moment you enter a compilation unit (assuming no link optimizations) with a state which at some point will run into undefined behavior all bets are of. [...] Yes, UB can "time travel"
> Close, but not quite. This is a common misconception in the reverse direction.
> Abstractly, what UB can do is performing the inverse of the preceding instructions, effectively making the abstract machine run in reverse. However, this is only equivalent to "time-traveling" until you get to the point of the last side effect (where "side effect" here refers to predefined operations in the standard that interact with the external world, such as I/O and volatile accesses), because only everything since that point can be optimized away under the as-if rule without altering the externally visible effects of the program.
> As a concrete, practical example, this means the following: if you do fflush(stdout); return INT_MAX + 1; the compiler cannot omit the fflush() call merely because the subsequent statement had undefined behavior. That is, the UB cannot time-travel to before the flush. What the program can do is to write garbage to the file afterward, or attempt to overwrite what you wrote in the file to revert it to its previous state, but the fflush() must still occur before anything wild happens. If nobody observes the in-between state, then the end result can look like time-travel, but if the system blocks on fflush() and the user terminates the program while it's blocked, there is no opportunity for UB.
The print example has no defined order of accesses, function parameters can be evaluated in any order. But further, the entire problem with UB is that it supercedes the regular guarantees that you get (like with volatile) when it's encountered. Yes gcc and clang do the obvious thing that makes the most sense in this example, but what people are trying to tell you is that they could just not do that and they would still be complying with the standard. For example, you can imagine a more serious example of UB that causes the program to fail to compile completely, and then do you emit the correct number of in order reads of volatile variables? Obviously not.
Function parameters cannot be evaluated in any order, when one of them is a volatile.
> The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject
And what I am trying to tell people, is the standard has expectations around the volatile keyword, that the compilers took into account when designing how they would work - it isn't just kindness, its compliance. But no one is actually talking about the quotes from the standard, and just quoting themselves and their own understandings.
That quote doesn't have anything to do with parameter evaluation order. There is no order for function parameter evaluation.
And no, there is no exception for undefined behavior. There can't be, otherwise the behavior would be... defined. It's in the name. Again, what do you think the compiler emits when the undefined behavior causes the program to not compile altogether?
That's a highly creative interpretation of events. The software license agreement usually upfront covers what can or cannot not change. It is pretty rare in most countries to see successful legal action for changed features, but best of luck.
They will just fine them into oblivion; they are known to fine companies AUD10M to AUD50M for this sort of thing, and from 1st April this year they can now fine up to AUD100M.
Will this mean that Bambu will withdraw from the Australian market? Possibly maybe probably, but the ACCC takes a very hard stance against bait and switch.
The largest ACCC fine to date for a company undertaking anti consumer practices is $483m against an educational provider for misleading students.
I'd be reasonably happy to lodge a complaint if I could find a version that's reasonably articulated. As a Bambu customer in Australia I switched my printer to local mode and its been great.
It's a whole lot better than the US, but AUD100M isn't enough to scare a lot of companies. A law with real teeth would go after an increasing percentage of their revenue for each offense.
As a percentage of global revenue, sure, it's not much. But as a percentage of what that company is likely to make in the Australian market, it can be significant.
Taking functionality away from a product after you bought it is a scum move. If the law lets them get away with it, the law should be changed.
When I buy a product, I look at reviews and make my purchasing decision on the features and functionality at the time of sale. If a software update later ruins that, I want the option to get my money back.
No, it’s not creative at all, it’s what happened — I have first hand experience to corroborate this.
Regardless, at least in the US, not only are software-based ToS becoming unenforceable, but there’s a large upswing towards “right to repair” legislation, which, I think, is what you’re arguing against here… and I really think you’re going to be on the wrong side of history with your current line of thinking (despite what Bambu Labs does).
No, it is with you -- the legislators are doing "fine" (and, again, are heading in a fine direction wrt RTR and software ToS).
I have no idea why you think copyright violations apply here? You seem to be throwing legal terms around without regard for their actual meaning. It's clear you're here to argue for the sake of argument, but I'd really encourage you to reflect and think about why you're so loyal to a corporate entity instead of your fellow consumers (of which there are many in the parent and sibling comments... hint: you may be on the wrong side).
Just for fun, pretend you bought a propane grill for cooking on Monday. On Tuesday, you cooked some bbq chicken and some corn. Later on Thursday, and without your knowledge or authorization, the grill no longer allowed you to use the propane apparatus for cooking non-meats unless you call a special telephone number and said a magic word whenever the call was answered. As a minimum, I feel, it'd be very confusing because, even though you're doing the exact same thing as Tuesday, the outcome is not the same.
Your freedoms have been restricted by someone else; if you are okay with that, then have fun licking boots. The rest of us will still be here advocating for your freedoms.
The "agreement" is at best coerced, and under blackmail of hardware you bought and paid for.
At worst, its a fraudulent indefinite rental masquerading as a 'sale'.
And lets discuss 'updates that fuck over your hardware'. In dwcent countries, thats hacking, and a serious criminal charge. But lol, companies are somehow exempt.
Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.
Now, I should probably explain why I’m using Lua 5.1 instead of the latest “official” version of Lua. Lua has an interesting history; in particular Lua 5.1 is the most popular version and the version which is most commonly used or forked against. Adobe Illustrator uses Lua 5.1, and Roblox uses a fork of Lua 5.1 called “luau”. LuaJIT is based on Lua 5.1, and other independent implementations of Lua (Moonsharp, etc.) are based on versions mostly compatible with Lua 5.1.
Lua 5.1 has a remarkably good security history, and of course I take responsibility for any security bugs in the Lua 5.1 codebase since I use the code with the relatively new coLunacyDNS server (Lua 5.1 isn’t used with the MaraDNS or Deadwood servers).
Lua 5.1 is used to convert documentation, but those scripts are run offline and the converted documents are part of the MaraDNS Git tree.
Yeah, I've had patches submitted to Moonscript, Fengari, and luau. Don't need to sell on why 5.1 is useful. Each version is a new lang, not just a few fixes or niceties.
I'm not convinced that vendoring, instead of embedding, is the right way.
The patch landing in 2021, instead of 2014, being one of those concerns.
(And you might want to recheck your assumption of how big 'int' will be, for rg32. C defines it in terms of minimum size, not direct size. int16_t isn't necessarily an alias.)
And, yes, this can be easily checked with a tiny C program:
#include <stdint.h>
#include <stdio.h>
int main() {
uint32_t foo = 0xfffffffd;
uint64_t bar = 0xfffffffd;
uint32_t a = 0;
for(a=0;a<20;a++) { printf("%16llx:%16llx\n",foo++,bar++); }
return 0;
}
If there’s a system where uint32_t is 64 bits, that’s a bug with the compiler (which isn’t following the spec), not MaraDNS.
Are you going to make any other negative false implications about MaraDNS? Because you’re making a lot of very negative accusations without bothering to check first.
Edit: Here’s a version of the above C program which works in
tcc 0.9.25:
#include <stdint.h>
#include <stdio.h>
void shownum(uint64_t in) {
int32_t a;
for(a=60;a>=0;a-=4) {
int n = (in >> a) & 0xf;
if(n < 10) {printf("%c",'0'+n);}
else {printf("%c",'a'+(n-10)); }
}
return;
}
int main() {
uint32_t foo = 0xfffffffd;
uint64_t bar = 0xfffffffd;
uint32_t a = 0;
for(a=0;a<20;a++) {
shownum(foo++);
printf(":");
shownum(bar++);
puts(""); }
return 0;
}
Which is the point. In 2020, when you added Lua, you added a vulnerability that had officially been fixed for six years. Because you vendored, and did not depend on any system package.
Apologies for being confrontational; accusations of there being security holes are serious accusations in my book, and need to be backed up with solid facts. Yes, that’s how seriously I take security with the software I make available on the Internet.
That number is a 32-bit number in the C code, but it’s converted in to a 16-bit number. I used “int” to have it interface with other Lua code, but safely assume “int” can fit 16 bits, and yes I do convert the number to a 16-bit one before passing it off to other Lua code:
Vendoring Lua 5.1 was forced; since I wanted to use Lua 5.1 (for reasons described above, e.g. LuaJIT compatibility), I had to use code which hasn’t been updated upstream since 2012.
I don't think you should take responsibility for bugs. Debugging is the act of removing bugs, so programming is the act of putting them in. Free software, per license, must not come with guarantees because the legal implications of any warranty whatsoever could cripple free software projects. The license of your nice DNS server includes the "as-is" wording for good reason.
That said, it is comendable that you've gone out of your way to hold up your software against very high standards. That kind of quality speaks for itself :)
Very good question. I can tell you why I chose Lua 5.1 for MaraDNS:
• Lua 5.1 is smaller than Lua 5.4
• Lua 5.1 is LuaJIT compatible; Lua 5.4/5.5 isn’t as compatible
LuaJIT is a version of Lua 5.1 which is an incredibly fast scripting language because it, in real time, compiles Lua 5.1 code in to native instructions. The only wart LuaJIT has is that its RISC-V port is incomplete, but that will undoubtedly change as RISC-V slowly gets more popular.
The other reason to stick to Lua5.1 is because Lua changes its syntax between versions; e.g. bitwise operations in Lua 5.4 are very different than how they are done in Lua5.1, to the point it’s difficult to make a polyglot library which can do bitwise operations in both Lua 5.1 and Lua 5.4. I am of the opinion Lua 5.3 should had been named Lua 6.0 for the simple reason that having native integers in Lua is a pretty significant backwards compatibility breaking change.
Since Lua (well, Lunacy) is the only tool in MaraDNS which isn’t standardized (e.g. MaraDNS uses only POSIX-comatible shell scripts, it uses “make” because that’s a standardized tool with multiple implementations, C is also a standard with multiple implementations, etc.), sticking to Lua5.1 allows me to use a version of Lua with multiple implementations and, as such, is informally standardized.
Unless the service accepts Lua code from the internet (and that would be a completely insane thing), the CVE-2014-5461 will not apply. And while I have not reviewed every Lua CVE, I bet most (all?) of then require a specifically crafted code, or at least highly-complex user input (such as arbitrary json)
It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
I should explain how MaraDNS uses Lua 5.1 (actually, Lunacy, my own fork with security bugs fixed as well as security hardening—including, yes, a patch against CVE-2014-5461), so you can get an idea of its attack surface.
MaraDNS has three components:
• MaraDNS, the authoritative server, which goes back all the way to 2001
• Deadwood, the recursive server, which was started back in 2007
• coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic
Neither MaraDNS nor Deadwood use Lunacy (except as a scripting engine for converting documents); only coLunacyDNS uses Lunacy. coLunacyDNS uses a sandboxed and security hardened version of Lunacy (and, yes, I would accept bugs where someone could escape that sandbox), and the Lua scripts which coLunacyDNS uses can only be controlled by a local user and there is no capability to run Lua scripts remotely.
You weren’t replying to me. The parent poster made a good point—a vulnerability in Lua doesn’t mean software running Lua can necessarily be exploited—but, more to the point, I do update Lunacy and make sure it’s secure, just as I still take responsibility for verified important security holes in MaraDNS.
> It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.
I did not suggest there was nothing to find. But is also very different to count all CVE's found and reported (there are less than 30 total for 2025 and 2026 per [1]) by anyone and everyone vs. what was found in a short time by someone prompting a model.
Is not the selling of the model, that it is as capable as anyone and everyone?
> Claude Mythos is Anthropic's most specialized model, trained exclusively on security research, vulnerability disclosures, and attack pattern literature. Its reasoning reflects how the world's best security researchers think. [0]
Even if I was selling the model, which I am not, it still does not follow that you can judge that on a single run, given that no security researchers have found all of these bugs on their own in a short amount of time either.
Okay, to respin this - Daniel doesn't say that curl is secure-enough. Half the point of the talks this year, is there has been an uptick in detecting security bugs, not a downturn. And here's some graphs. [0]
> Given the look of these graphs I don’t think we are close to zero bugs yet. These two curves do not seem to even start to fall yet.
If the author thinks there is more to find, then the soil probably isn't dry.
But, from the author's mouth:
> My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing. [1]
Even worse than a rubber ducky: the O.MG cable does the same thing, but looks like a regular USB cable. Their Apple Lightning-dupe [0] is my favorite. The creator was on Darknet Diaries a while ago, too. [1]
That's almost 12 years now. A novice can now get ATmega32 USB devices Prime delivered. Not a cutting edge theoretical attack anymore but a basic tool in a every pen tester's toolbox now.
The PDP-11 had both 8 and 9-bit bytes. Thats a complexity that few programmers have to touch on, today.
reply