uecker

Everybody in WG14 is fully aware of the GNU extensions. Also many of us are active C users (but maybe not enough). With complicated syntax you mean the "defer" proposal?. In any case, differ…

I think I have the opposite opinion. Newer C standards have a very high degree of backwards compatibility. I think we should try to transition code to the current ISO standard and in almost all case…

There are plenty of other bugs causing CVEs, but there are certainly a lot caused by memory issues. I personally believe that C needs a safe mode, but also with existing tools (static analysis, sanit…

This is not my experience. I switched from C++ to C for all my programming. C certainly does not bring much out of the box, but with some data structures libraries ts a very good language for almost …

The C header interface is simple: struct foo; struct foo *foo_alloc(); void foo_do_something(struct foo *p, ...); This gives a simple to understand API with clearly defined boundary, has a …

One can write very nice code in C and modern tools also eliminate a myriad sources of bugs. Modern C++ can be nice but adds a lot of complexity. I am much happier with C.

C is peak C for me. I think you can better modularize in C than in C++ because with APIs build around incomplete struct types the implementation stays in the C file and does not leak into the header a…

I do not have to ask myself the question: I follow energy policy closely and also look at actual data. Of course, we need a solution for time when there is no wind or solar. But this - very obviously…

In contrast nuclear, storage gets cheaper and better. Nuclear does not remain in Germany and is largely irrelevant almost everywhere else. My prediction is that it will increasingly become completely …

Industry can definitely adapt to electricity prices. This is the power of free markets, they can optimize production and demand. Fluctuating prices cause by renewables will cause investments in stor…

Summer droughts and also high energy use in winter with electric heating is where France regularly depends on imports.

Nuclear economics doesn't work. China just pulled out from Hinkley Point C. EDF made record losses and sits on an ancient fleet and is being renationalized. Westinghouse went bankrupt over two p…

True, but also coal. Coal use declined substantially in Germany. Lignite from 171 TWh production in 1990 to 92 TWh in 2020 and coal from 141 TWh to 43 TWh.

Overall, economics is killing nuclear not greens.

Nonsense: coal 1990: 141 TWh, 2000: 143 TWh, 2010: 117 TWh, 2020: 41 TWh lignite 1990: 171 TWh, 2000: 148 TWh, 2010: 146 TWh, 2020: 91 TWh Official numbers: https://ag-energiebilanzen.de&#x…

I haven't read the article, but following this effort from the compiler side, I do not think this is the case. Also there is exactly one ISO C standard. Newer versions supersede older ones from …

The process depends on the package. If there is an active upstream project, a github pull request or similar would often do. It might be a good idea to coordinate with the distributions involved. For …

It is not valid C for almost 25 years and compilers warn about it for a long time. I doubt this is an issue at all.

Implicit int was removed in C99. Since then most compilers warn about this in default compilation mode.

I don't agree. IMHO Building on top of shared libraries with stable interfaces managed by a distribution package manager is the better approach. All this fast changing dependencies where you the…

You could have similar warning in C compilers: https://godbolt.org/z/aj6TWsxK3 I agree that Rust has more comprehensive guard railes, but except for pointer ownership and sharing…

Not having UB in is a prerequesite for memory safety. In theory, WG14 could make top-down decisions. But if we would decide something implementors really do not want to do, they would simply ignore th…

Not just in principle. Compilers do have flags that turn UB into defined behavior (not all UB but e.g. signed overflow) and this often does not have high overhead. Users must learn turning on certain …

That a computed expression i + 1 can be assumed to be positive for non-zero i follows mathematically from overflow being undefined.

Integer overflow is relatively easy to detect and protect against at run-time using -fsanitize=signed-integer-overflow. (yes, needs testing. Doing it reliable at compile-time is hard.) But compilers…

Ah, ok. But it is developing rapidly...

Try -fanalyzer with new GCCs. Not finished, but already impressive.

We did! stdckdint.h if (!ckd_int(&result, a, b)) exit(1);

Or a hacker wrote the code, overflowed the stack and inserted the code, I guess. But note that C++ doubled down on the idea UB invalidates the whole program. But I also disagree that UB is the problem…

Why is it different? "program hasn't done anything incorrect" includes not overflowing i. And being able to even put variables in register relies on such assumptions in a very similar …