361–370 of 387 posts
Earlier quoted context omitted.
> Access through a union allow the same region of memory to be interpreted as different types. …only in C. > No mainstream compiler will ever not optimise that. Actually, it's mandated by the System-V ABI for structures of an appropriate size.
Which is not supported in every OS out there.
Earlier quoted context omitted.
That says used , not read . And indeterminate , not unspecified . My point was on reading a value, not on acting on the value. I know it looks like nit-picking, and you should just not read uninitialized memory, but I don't think it's consistent with the standard to say that reading uninitialized memory is always UB.
What kind of read would not constitute "using" a value? And per your previous post an object that was not initialised is indeterminate, not just unspecified. So yes, reading uninitialized memory is always UB.
Earlier quoted context omitted.
Yes, CLion, my mistake, sorry.
Hmm, that's a bit disappointing…might I suggest trying out a LibClang-based IDE, if CLion isn't using it already? It can do wonders even to "stupid" applications. For example, my Sublime Text (by itself, with only basic knowledge of C++ keywords and such) with clangd tells me that std::make_shared comes from this code in : template inline _LIBCPP_INLINE_VISIBILITY typename enable_if ::value, shared_ptr >::type make_s…
Earlier quoted context omitted.
> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…
> At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." That's a bullshit argument very close to FUD. You don't need to know the 1400 pages of the C++ standard to use safely a subset of it. Specially with proper tooling to help you. Do you really think that every web f…
Most importantly, if someone does find a way, it's an error in either the spec or the browser implementation. It's not flagged as "undefined behavior" and we go on with the assumption some web pages just break your browser or the OS hosting it.
I can tolerate a thousand-page spec for a system that can't crash unsafely; it's a much bigger risk for one with unchecked pointer indirection as a feature.
Earlier quoted context omitted.
> At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." That's a bullshit argument very close to FUD. You don't need to know the 1400 pages of the C++ standard to use safely a subset of it. Specially with proper tooling to help you. Do you really think that every web f…
Those standards are built to be default-sound. It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. Most importantly, if someone does find a way, it's an error in either the spec or the browser implementation. It's not flagged as "undefined behavior" and we go on with the assumption some web pages just break your browser or the OS hosting it. I can tolerate…
This is a narrow view where you focus only on memory safety and buffer overflow. Undefined Behaviours goes way wilder than that.
Many problems coming by UBs do not goe into any crash, just wrong results and wrong behaviour which is something even worst.
And currently, JavaScript is full of that. Almost everything that JS can not handle (or do not know how to handle is undefined) or purely implementation specific.
Earlier quoted context omitted.
Those standards are built to be default-sound. It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. Most importantly, if someone does find a way, it's an error in either the spec or the browser implementation. It's not flagged as "undefined behavior" and we go on with the assumption some web pages just break your browser or the OS hosting it. I can tolerate…
> It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. This is a narrow view where you focus only on memory safety and buffer overflow. Undefined Behaviours goes way wilder than that. Many problems coming by UBs do not goe into any crash, just wrong results and wrong behaviour which is something even worst. And currently, JavaScript is full of that. Almost…
There are circumstances where you want the features C++ brings to solve a problem. But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit.
Earlier quoted context omitted.
The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.
This is problematic on large code bases. Huge mistakes were made on C++ design.
It turns out if you use enough layers of templates, the compiler has to carry around an awful lot of state to figure out what program it should actually output.
This is another downside to a 1400 page language specification; whether the user can hold most of it in their head or use a reliable, safe subset to avoid sharp edges, the compiler and tools still have to be aware of all of the layers of complexity in both the code a developer is writing and often whatever tricks and quirks developers chose to usein the libraries the developers code is depending on.
Earlier quoted context omitted.
> It shouldn't be possible to do wild memory access in JavaScript or via novel application of CSS or DOM structure. This is a narrow view where you focus only on memory safety and buffer overflow. Undefined Behaviours goes way wilder than that. Many problems coming by UBs do not goe into any crash, just wrong results and wrong behaviour which is something even worst. And currently, JavaScript is full of that. Almost…
And for JavaScript, that space doesn't include buffer overruns or memory safety, unless you do something very exotic and implement your own indirected memory access in JavaScript (in which case, you've sort of dug your own grave). because undefined behavior literally means undefined behavior, C++ gets to bring to the table all of the failure modes JavaScript brings to the table in addition to the plethora of ways unc…
Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.
Earlier quoted context omitted.
That says used , not read . And indeterminate , not unspecified . My point was on reading a value, not on acting on the value. I know it looks like nit-picking, and you should just not read uninitialized memory, but I don't think it's consistent with the standard to say that reading uninitialized memory is always UB.
What kind of read would not constitute "using" a value? And per your previous post an object that was not initialised is indeterminate, not just unspecified. So yes, reading uninitialized memory is always UB.
Earlier quoted context omitted.
That says used , not read . And indeterminate , not unspecified . My point was on reading a value, not on acting on the value. I know it looks like nit-picking, and you should just not read uninitialized memory, but I don't think it's consistent with the standard to say that reading uninitialized memory is always UB.
What kind of read would not constitute "using" a value? And per your previous post an object that was not initialised is indeterminate, not just unspecified. So yes, reading uninitialized memory is always UB.
From 6.2.6.1¶5:
>Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. ... Such a representation is called a trap representation.
A read from uninitialized memory is not always UB.