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

191–200 of 275 posts

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

#191

Post by GuB-42 »

lionkor wrote: post #153
GuB-42 wrote: post #90

I actually like unreachable() a lot. What it does is that it invokes undefined behavior, that's all. It does nothing trickier than any other kind of UB. In fact, I could implement unreachable() like this: void unreachable() { (char *)0 = 1; }. Standardizing it however gives interesting options for compilers and tool writers. The best use I can find is to bound the values of the argument of a function. For example, if…

Respectfully, you would already be doing this in any C codebase, with `assert()`, right? We are all checking our preconditions with assert... right?

AFAIK, assert() is not undefined behavior, so it can't be used for optimization. It is either implementation-defined in debug mode, or does nothing in release mode.

For example:

  assert(a >= 0);
  if (a
In release mode, assert() will be gone, so the if/printf() will stay. If we used "if (a < 0) unreachable();" instead of assert(), it would optimize away both lines.

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

#192

Post by carlmr »

codeflo wrote: post #125
ternaryoperator wrote: post #97

Earlier quoted context omitted.

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…

Of course, that's technically incorrect. The way the standards are written, the compiler is free to replace the program with any other program that has the same (in a precisely defined sense) observable behavior (these are the famous "as if" formulations in language specs). Heating up the CPU is not considered observable behavior. If someone really just wants a delay, it's easy to either (for programs running on norm…

>Heating up the CPU is not considered observable behavior.

Neither is measuring delays of cached versus non-cached instructions. Yet it turns out to be very observable.

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

#193

Post by wruza »

masklinn wrote: post #150
wruza wrote: post #34

Earlier quoted context omitted.

With int statuses, not with bools. It’s just a twisted logic in return value you have to deal with in your head. “If checked operation has a status, then it failed.” - ok “If checked operation [is true], then it failed.” - wat

> With int statuses, not with bools Which C historically did not have, so int played that role. The function is the same, and the existing idioms remain.

I find it strange to introduce real bools (which these macros return according to their official signatures) and then to assign them a meaning of a still-nonexistent but widely used C type. At least my C intuition stumbles upon that immediately, no matter how long I think about it.

Ah, anyway, standard C/libc is basically a lost cause. It can’t get any worse, since you have to refer to a manual at every call to not step on a landmine.

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

#194

Post by pjmlp »

heywhatupboys wrote: post #182
pjmlp wrote: post #141

And zero focus on improving the root causes of memory corruption due to strings and array indexing errors. The security world will keep burning it seems.

> The security world will keep burning it seems. There is no alternative to network protocols and IPC that the stringtypes C has. You get a length and a byte array. If you trust the user, you can assume length is correct. Otherwise no.

Sure there are, as proven by distributed networking stacks not written in C.

In fact Ethernet early days goes back to Mesa not C.

UNIX did not invent networking, networking predates UNIX for at least a decade.

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

#195

Post by bee_rider »

liquidify wrote: post #133
bee_rider wrote: post #119

Earlier quoted context omitted.

“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.

There are so many less hurtful words, I can’t accept the idea that style requires these particular words. I mean the sentence is clunky with “neurodivergent” anyway, and this unusual use of the word sticks out and is distracting. The style is not improved by this pick.

How about “awful” “asinine” or “shit-tastic” instead?

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

#196

Post by wizzwizz4 »

liquidify wrote: post #133
bee_rider wrote: post #119

Earlier quoted context omitted.

“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.

There's no way to say "this thing is rubbish" without the potential to bother people who like it. But it's entirely possible to say it without pissing off those who don't speak, or have motor disabilities, or like Justin Bieber.

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

#197

Post by __s »

coliveira wrote: post #58
peppermint_gum wrote: post #30

Earlier quoted context omitted.

>It's only tone deaf to people who understand "undefined behavior" as an epithet or as synonymous with giving a license to compilers to screw you over. The term doesn't have either of those meaning to those on the C committee. It's unfortunate but not surprising that the C committee isn't aware of the problems with the undefined behavior. In fact, after I started reading WG14 meetings minutes, I completely lost faith…

This is not a problem with the committee and is not a problem with compiler writers. The committee is only marking certain behaviors as UB. Compilers can do what they think is more sensible in these situations. And compiler writers are not forcing you to accept these extreme optimizations. You always have the option of disabling optimizations and accept that your code has bugs (UB). You just need to test the code you…

"just disable optimizations" is not a solution unless the compiler allows enough fine grained control where that solution is `-ffree-zero-sized-realloc`

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

#198

Post by codeflo »

carlmr wrote: post #192
codeflo wrote: post #125

Earlier quoted context omitted.

Of course, that's technically incorrect. The way the standards are written, the compiler is free to replace the program with any other program that has the same (in a precisely defined sense) observable behavior (these are the famous "as if" formulations in language specs). Heating up the CPU is not considered observable behavior. If someone really just wants a delay, it's easy to either (for programs running on norm…

>Heating up the CPU is not considered observable behavior. Neither is measuring delays of cached versus non-cached instructions. Yet it turns out to be very observable.

Of course these things are “observable” in the literal sense. And yet, they aren’t considered to be observable by the memory model of any language spec that I know of. Same as CPU power draw, which has been used as a side-channel to extract bits of crypto keys, and is very much influenced by common optimizations.

Practically, if you need to execute a specific sequence of machine instructions in order to prevent side-channel attacks, then you have to rely on assembler, compiler intrinsics and/or OS support. But that was true way before Spectre.

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

#199

Post by pclmulqdq »

mafuy wrote: post #185
chongli wrote: post #63

Earlier quoted context omitted.

This would mean you’d have to insert a check every time you add two signed integers together, because signed overflow is UB. You’d also have to wrap every memory access with bounds checks, because OOB memory access is UB. There are also tons and tons of loop optimizations compilers do for side-effect free loops which would have to be removed completely. This is because infinite loops without side effects are UB. So i…

> you’d have to insert a check every time you add two signed integers together, This is exactly what is done in serious code. It is typically combined with contracts and static analysis (often human), e.g. "it is guaranteed that this input is in range 10-20, so adding it with this other 16 bit int can be assumed to be below sint32_max".

Great, those checks can stay in "serious" code, and those of us who don't want them can take the UB. C++ 20 actually ended up specifying that all ints are twos complement, removing this from the category of "UB," but a lot more weird stuff is programmed in C.
Post reply on HN