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

Mildly interesting quirks of C

gist.github.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Mildly interesting quirks of C

#61

Post by int_19h »

guenthert wrote: post #44

> UB is impossible What? UB is clearly undesirable , but assuming it is impossible and deducing other outcomes must be meant are clearly wrong assumptions by the compiler writer. More sensible compilers (including older version of clang) do the right thing (TM) here and yield a compiler error. There were earlier attempts at do-what-i-mean programming languages. They are rightfully buried in history.

A better way to phrase it is that UB means "anything can happen". This, by definition, includes calling the function even though the pointer is null.

Re: Mildly interesting quirks of C

#62

Post by int_19h »

Note that:

  void foo(int p[static 1]);
is effectively a standard way to declare that p must be non-null pointer. I always wondered if any compiler actually makes use of this for optimization purposes.

Re: Mildly interesting quirks of C

#63

Post by evouga »

rwmj wrote: post #6

Reminds me a bit of "Who Says C is Simple?" written by the people who wrote a C parser & analyser in OCaml (CIL): https://cil-project.github.io/cil/doc/html/cil/cil016.html Also: https://cil-project.github.io/cil/doc/html/cil/cil012.html

> return ({goto L; 0;}) && ({L: 5;});

What in the world…!!

It’s in the GCC section so I assume it’s some kind of lambda-function-like compiler extension? That allows jumping between bodies of two different functions…!

Re: Mildly interesting quirks of C

#64

Post by GuB-42 »

guenthert wrote: post #44

> UB is impossible What? UB is clearly undesirable , but assuming it is impossible and deducing other outcomes must be meant are clearly wrong assumptions by the compiler writer. More sensible compilers (including older version of clang) do the right thing (TM) here and yield a compiler error. There were earlier attempts at do-what-i-mean programming languages. They are rightfully buried in history.

Assuming undefined behavior is impossible is a way for the compiler to optimize code. In fact, it is the main reason why UB exists.

It is exemplified by the C++23 std::unreachable() function, its description is "invokes undefined behavior". It is intended to mark part of the code that are unreachable, so that they don't appear in optimized builds, but may appear in debug builds. It is an explicit use of "the power of UB", an optimizing compiler considers that calling std::unreachable() is impossible, so all code paths that lead to it can be safely pruned. In an debug build, the code may be generated anyways, and the compiler will chose something sensible for what happens when it is called, typically a crash, but it can be anything, it is UB.

Re: Mildly interesting quirks of C

#65

Post by Gibbon1 »

int_19h wrote: post #61
guenthert wrote: post #44

> UB is impossible What? UB is clearly undesirable , but assuming it is impossible and deducing other outcomes must be meant are clearly wrong assumptions by the compiler writer. More sensible compilers (including older version of clang) do the right thing (TM) here and yield a compiler error. There were earlier attempts at do-what-i-mean programming languages. They are rightfully buried in history.

A better way to phrase it is that UB means "anything can happen". This, by definition, includes calling the function even though the pointer is null.

I think 'anything can happen' needs to be extended to the C standards committee's bank accounts.

Re: Mildly interesting quirks of C

#66

Post by sbf501 »

I just fixed some neural-net code to use #7. I hate passing pointers to layers that have a fixed size, and passing an array causes problems sometimes that require too many cats. Typedef array pointer to the sized array is precisely what I needed.

Re: Mildly interesting quirks of C

#67

Post by pcwalton »

Asooka wrote: post #20
camel-cdr wrote: post #19

Here are two of my favorite obscure quirks of C: struct X { char x[8]; }; struct X awoo(void); printf("%s\n", awoo().x); The above is UB in = C11. [0] struct X { char b[8]; } foo(); int *b = foo().b; printf("%s\n", b); The above is UB in >= C11 and valid in [0] https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?c... [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1285.htm

I really wish both would be valid in C11. Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed off and defined as "whatever the platform does".

> Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed off and defined as "whatever the platform does".

Depending on what you mean by undefined behavior, now you've made register allocation an invalid optimization. You really don't want to use that version of C.

Re: Mildly interesting quirks of C

#68

Post by astrange »

still_grokking wrote: post #40

After learning about a few of these I started to understand why people coming from C always said that PHP is a well designed language… But OK, I understand that my mind is just not made for the complexity of C. Most likely I'm not a real programmer. I get instantly knots in my brain and start to bang my head against the wall when I need to look for too long on C code. Actually even C documentation is enough to trigge…

PHP is a well-designed language because it has value types (immutable data structures). That puts it far above any language without them for correctness. The poorly designed old database libraries aren’t really a language issue.

Re: Mildly interesting quirks of C

#69

Post by astrange »

antirez wrote: post #10

The top comment in the gist looks like from "Hacker News Parody Thread".

It’s also not good advice, because if you put your code through that many off by default compiler warnings, you’ll just find bugs in the warnings. eg -Wstrict-aliasing in gcc can be wrong and -Wdeprecated can be literally impossible to fix.
Post reply on HN