Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Catch-23: The New C Standard Sets the World on Fire

queue.acm.org

Post reply on HN
Print view View original

131–140 of 275 posts

Re: Catch-23: The New C Standard Sets the World on Fire

#131

Post by viraptor »

ternaryoperator wrote: post #97
Dylan16807 wrote: post #32

> C23 furthermore gives the compiler license to use an unreachable annotation on one code path to justify removing, without notice or warning, an entirely different code path that is not marked unreachable: see the discussion of puts() in Example 1 on page 316 of N3054.9 I don't agree with that description at all. Here's the code: 1 if (argc The only code path that's "entirely different" is lines 1,4,5 and in that ca…

This reminds me of a point made by the late Stan Kelly-Bootle, who for years wrote the Devil's Advocate column in UNIX Review magazine. In the early 1990s, he was discussing Microsoft's new C compiler and noted that in the promo material for the new compiler, it showed a benchmark for a loop that counted from 1 to 10,000 then printed "Hello". MS claimed that without optimization it took a few milliseconds, after opti…

Those delay loops are common on microcontrollers and the usual solution is to either make the counter volatile or insert something opaque to the compiler in the loop body.

It would be of course nice if a warning was produced for that specific case: This whole loop was removed - is it really what you wanted, or is it a broken delay loop?

Re: Catch-23: The New C Standard Sets the World on Fire

#132

Post by JonChesterfield »

Author is angry but not wrong. Lifting the most damning quote from the article as I haven't seen it for a while.

C inventor Dennis Ritchie pointed to several flaws in [ANSI C] ... which he said is a licence for the compiler to undertake agressive opimisations that are completely legal by the committee's rules, but make hash of apparently safe programs; the confused attempt to improve optimisation ... spoils the language.

—Dennis Ritchie on the first C standard

Re: Catch-23: The New C Standard Sets the World on Fire

#133

Post by liquidify »

bee_rider wrote: post #119
shagie wrote: post #72

Earlier quoted context omitted.

As an aside, this is one of the spots where GPT does a really good job of fixing things. Reword the following passage. Change euphemisms to wording that has similar meaning though no negative conotations. Indicate changed words by putting them in "{{word}}" ### Standards are supposed to lead ... Why are such requests made? Often because of arithmetic bugs. And what is a non-null pointer from malloc(0) good for? Absol…

“Unconventional” seems like a bad pick to me, too neutral. Clearly the author intends to say something negative about zero-length objects. And of course it is fine dislike things, it is just a matter of not using hurtful language.

There is no possible way to have style without the potential to bother someone. Just write how you feel. If the readers are so offended, they can stop reading. Life will go on.

Re: Catch-23: The New C Standard Sets the World on Fire

#134

Post by spc476 »

notfed wrote: post #92
RustyRussell wrote: post #9

Frankly, the C standards ctte went off the deep end when they effectively banned NULL to memset etc (obv with zero length). Not because these functions couldn't handle it, but because this assertion simplifies optimizations elsewhere . This has required adding extra checks in my code, found mainly by trial and error, and has made it less readable and less optimal. Finally, the checked arithmetic operations returning…

Isn't the return value just a carry bit?

Not every CPU C runs on has a carry bit. MIPS, SPARC, RISC-V, all don't have the concept of a "carry bit."

Re: Catch-23: The New C Standard Sets the World on Fire

#135

Post by [deleted] »

i-use-nixos-btw wrote: post #3

This is written with quite a lot of hyperbole. The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful, consistent behaviour. It is far from that, and that’s the entire reason that it was declared UB in the first place: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf . Note that this wasn’t a proposal to change something, it’s a defect report: the ori…

[deleted]

Re: Catch-23: The New C Standard Sets the World on Fire

#136

Post by layer8 »

While the situation with realloc() is unfortunate, it is also not difficult to write a wrapper that does what the author wants. I’ve done that before, because it has long been known that not all realloc() implementations conform to the (prior) C standard. One can furthermore assume that existing implementations won’t change their behavior just because C23 made it UB.

Re: Catch-23: The New C Standard Sets the World on Fire

#137

Post by the_why_of_y »

pmarin wrote: post #107
coliveira wrote: post #44

Earlier quoted context omitted.

> approximately every nontrivial program ever written has UB You can replace "UB" for "bugs" and the result is the same. UB is a bug on the part of the programmer, from the point of view of C, similar to dereferencing a null pointer. When the standard says that something is UB, it is just clarifying what these situations are.

If they are bugs they should be reported to the user and end the compilation with an error.

Compilers actually have some options to enable that.

The problem is, it only works well in the simplest cases when the code will 100% exhibit UB within a single function.

In most cases, the UB would only manifest on particular input values - if you want your compiler to warn about that then it will report one "potential UB" for every 10 lines of C code, and nobody wants to use such a compiler.

Re: Catch-23: The New C Standard Sets the World on Fire

#138

Post by benj111 »

codeflo wrote: post #126
_8j50 wrote: post #113

Earlier quoted context omitted.

Shouldn't the compiler warn or error on unreachable code?

This is not about code that's found to be unreachable through static analysis (where compilers might warn), but about a manual programmer annotation that claims the code is dynamically unreachable even though statically it might look otherwise.

Why would you want that?

Is it to aid building for multiple targets? For debug builds?

Re: Catch-23: The New C Standard Sets the World on Fire

#139

Post by brxaf »

a-bit-of-code wrote: post #108

Is it just me that thinks that the article is a [skilfully drafted] joke (or parody or whatever the correct word is)? The fact that it has been published close to April 1st raises more suspicions.

I thought the same initially, but the realloc() parts are definitely true.

Re: Catch-23: The New C Standard Sets the World on Fire

#140

Post by benj111 »

i-use-nixos-btw wrote: post #3

This is written with quite a lot of hyperbole. The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful, consistent behaviour. It is far from that, and that’s the entire reason that it was declared UB in the first place: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf . Note that this wasn’t a proposal to change something, it’s a defect report: the ori…

My understanding was that they're changing realloc() because they previously allowed zero length arrays and because you can't tell if this is a zero length array you need to either get rid of zero length arrays or change realloc().

So the feature wasn't broken to begin with, it was broken by another feature.

Post reply on HN