511–520 of 978 posts
Numeric overflows in things like calculation of buffer sizes can lead to vulnerabilities.
Signed overflow is UB, and due to integer promotion signs creep in unexpected places.
It's not trivial to check if overflow happened due to UB rules. A naive check can make things even worse by "proving" the opposite to the optimizer.
And all of that is to read one bit that CPUs have readily available.
Earlier quoted context omitted.
Does it concern you how aggressively compiler teams are exploiting UB?
I would say that there is a lot of concern in the committee about how compilers are optimizing based on pointer providence. There has been a study group looking at this. It now appears that they are likely to publish their proposal as a Technical Report.
I think you meant "provenance" (mentioning it for the sake of anyone who wants to search for it).
Earlier quoted context omitted.
Could we instead just have standard-defined integer types which saturate or trap on overflow? Sometimes you're writing code where it really, really matters and you're more than willing to spend the extra cycles for every add/mul/etc. Having these new types as a portable idiom would help.
There was a proposal for a checked integer type that you might want to look at: N2466 2020/02/09 Svoboda, Towards Integer Safety http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf The committee asked the proposers for further work on this effort. Integer types that saturate are an interesting idea. Because signed integer overflow is undefined behavior, implementations are not prohibited from implementing satur…
The entire notion that "since this is undefined behavior it does not exist" is the biggest fallacy in modern compilers.
Earlier quoted context omitted.
That’s quite precise, can you give a sense of why it’s useful to have? Does it translate as “you can never know whether two mallocs are adjacent, so don’t even try merging them”?
One concrete reason why “unspecified” means “anything and not always the same thing” is to enable the maximum of optimizations. Write a function c that compares pointers in a compilation unit, and in another compilation using, define: int a, b; X1 = (&a == &b + 1); X2 = c(&a, &b + 1); The compiler can optimize the computation of X1 on the basis that comparing an offset of &a to an offset of &b will always: - be false…
Imagine a standard stated that > and I guessed above that this is kinda like having hashmaps iterate in a random order: compilers do spooky things when you try to check whether two allocas/mallocs are adjacent, so don’t do it. Is that accurate? Or does it mean that compilers can move things around on the stack if they want, without worrying about updating the registers or locations that store the pointers, i.e. this is mainly to make compilers easier to write? If it’s that, I imagine I would want some other pointer comparisons on the list. The reason it’s in there is what I wanted you to shed some light on.
Earlier quoted context omitted.
It would presumably involve a new type that didn't exist in the current ABI. Those pointers would stay the same, and the new (twice as big) pointers would be used for the array feature.
The point of uintptr_t is that it's an integer type to which any pointer type can be cast. If you introduce a new class of pointers which are not compatible with uintptr_t, then suddenly you have pointers which are not pointers.
There's no guarantee that a function pointer type can be converted to uintptr_t without loss of information.
C currently has two kinds of pointer types: object pointer types and function pointer types. "Fat pointers" could be a third. And since a fat pointer would internally be similar to a structure, converting it to or from an integer doesn't make a whole lot of sense. (If you want to examine the representation, you can use memcpy to copy it to an array of unsigned char.)
int f (a, n) int n; int a[n][n]; { return a[n-1][n-1]; }
How could one define this function without using the obsolete syntax?
Earlier quoted context omitted.
I would say that there is a lot of concern in the committee about how compilers are optimizing based on pointer providence. There has been a study group looking at this. It now appears that they are likely to publish their proposal as a Technical Report.
What's the best way to keep an eye out for that TR? Periodically checking http://www.open-std.org/jtc1/sc22/wg14/ ? I can't ever tell if I'm looking in the right place. :)
Earlier quoted context omitted.
When they say "existing practice" they mean things already implemented in compilers -- not existing practice among developers.
This seems like a poor way to establish criteria for standardization. It essentially encourages non-standard practice and discourages portable code by saying that to improve the language standard we have to have mutually incompatible implementations. It has been said that design patterns (not just in the GOF sense of the term) are language design smells, implying that when very common patterns emerge it is a de facto…
In order to uphold that principle, it's important that the standard consider not just "is this useful" but "is this going to be reasonably straightforward for compiler authors to add". Seeing that people have already implemented a feature helps C to avoid landing in the "useful feature which nobody can use because it's not widely available" trap. (For example, C99 made the mistake of adding floating-point complex types in -- but these ended up not being widely implemented, so C11 backed that out and made them an optional feature.)