I spent several years working on a production grade compiler and I can assure you it's not. But keep just making things up off the top of your head if it makes you feel smart.
It's not just any, typical kind of dead store elimination. It also would require other optimization passes that I can assure you no mainstream compiler actually does. You can disagree with me if you want, but you're simply wrong.
> This is the kind of thing that can break by accident and ruin everyone's month.
Not in practice. Compilers make use of undefined behaviour to optimize things that are widely applicable and profitable. No real compiler does what you're saying and no future compiler is likely to without explicitly being asked to.
I agree that, by the letter of the spec, you're right, but you're still most certainly overstating the relevance.
I'm not arguing that this isn't a real problem or that people shouldn't use memzero_explicit() (or similar) where security is on the line, as I already said several times in another sub-thread -- I'm just saying that this kind of thing is extreme language-lawyering beyond the realms of probability. It's still not an excuse to be lax, but let's be realistic about the actual likelihood of it happening.
As soon as a pointer to said memory is passed to an extern function in another translation unit, the compiler can't prove anything about how it's used, which is the case in pretty much all of the examples mentioned in this thread.
Also, type-punning is a thing. memset is byte-oriented/memory-oriented. Just because you're using it to zero a struct of a particular kind doesn't mean that's the only way the memory will accessed. Just because reading the padding of some struct is undefined behaviour doesn't mean accessing those bits by some other means is also undefined.
A compiler usually can't eliminate a call to memset() in most practical cases of initialization (where memory leakage is also a concern) because they almost always pass a reference to a routine in another translation unit. Something like memzero_explicit() can be used anyway -- but you're massively overstating the relevance of compilers eliminating dead stores done via memset(). It's much more of an issue for post-destruction memory sanitizing (which is the primary use case for memzero_explicit) than it is for compiler f*ckery when memset() is used for initialization.
You mean it can remove a memset() that doesn't cause the observable behaviour to change?
For the sake of argument, can you show me some example code where it would be conforming to remove a memset() call? Preferably a realistic example and not a Google'd copypasta. Because it's all too easy to just regurgitate things you heard and think you understood, but no so easy to demonstrate it yourself.
I guess we are misunderstanding each other's point. I just found hermitdev's comment to be misleading (despite being correct), but perhaps it's just my reading of it.
To be fair though, memset() usually IS a fix. As mentioned by the kernel memzero_explicit() docs:
A conforming C compiler can't just remove memset() as it pleases. The case that most often requires memzero_explicit() is when zeroing an object after destruction, because the compiler thinks it can statically determine that it's a dead store. It very rarely happens that a compiler elides a memset() used for initialization.
I'm not sure why you seem to think that memset() can just be dropped at will for no reason whatsoever or that it's somehow always undefined behaviour.
Right, but I didn't make a case that memset() is any more secure, did I? The parent comment was talking about undefined behaviour as if it's some kind of universal get-out clause.
What's even more weird is making every 10 line function a "library" and the average program having 500+ dependencies. JS people are so hung up on "re-usability" that they completely miss the concept of dependency hygiene.
If you pass partially uninitialized objects (including padding) between kernel space and user space, there's a chance that the (less privileged) user space code can recover information it shouldn't be able to see, regardless of what the spec says about undefined behaviour. Such information may include secrets that previously occupied the memory where a new, unrelated struct now resides. The same can also apply to passing objects between different machines.
All "undefined behaviour" means is that the spec can no longer guarantee anything about the execution of a program once a constraint is violated. It doesn't say anything about the practicality of actually doing it on any given implementation.
FWIW I didn't downvote you, but your reasoning about undefined behaviour seems overly simplistic. It should never be used to explain away security concerns.
What has he done, besides The Cathedral and the Bazaar...?
Most of his open source contributions seem to be littering up source files with long-winded comments and grandiose attributions to himself. I've read a fair bit of his code and it's certainly not impressive. Quite the opposite actually.
I'm further right on the political spectrum than ESR is. It's his delusions of grandeur and constant, smug championing of his own relevance that I can't stand...
> Everyone forgets that SASS is meant to be programmable CSS
That sounds like a solution looking for a problem... The vast majority of real SASS I've seen has been much like the stuff this article mentions.
> If you treat it as CSS+ then you're not really benefitting from it's true potential
People aren't looking for "potential", they're looking for a way to accomplish their design goals whilst keeping their stylesheets maintainable. The real use cases where SASS is actually worth the complexity overheads are getting fewer and fewer.
> Holding `CTRL` essentially lops off the first three bits
No, it inverts the 7th bit (or subtracts 64).
The Linux `ascii(7)` man page has a similar table, but with 2 columns. The first 32 control characters listed there have their "caret notation" character in the opposite column.
I spent several years working on a production grade compiler and I can assure you it's not. But keep just making things up off the top of your head if it makes you feel smart.