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

Undefined behavior in C is a reading error

yodaiken.com

Post reply on HN
Print view View original

371–380 of 503 posts

Re: Undefined behavior in C is a reading error

#371

Post by junke »

a1369209993 wrote: post #351
hnjst wrote: post #344

Earlier quoted context omitted.

> Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. I'm not completely sure I understand that correctly, but do you mean that statements that are constant unless considering a possible (and "credible"?) implementation of UB shouldn't be fair-game for the compiler to optimize out? EDIT: I think I see a more tricky ca…

> Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to: if(!p) abort(); use(*p); it may do so (undefined behaviour!), but if it chooses not to do so, it may not later pretend that it did, and remove a explict `if(!p)` that the programmer wr…

What is the meaning of use(*p) in case p is null? what should the compiler emit?

Re: Undefined behavior in C is a reading error

#372

Post by throwaway2048 »

pjmlp wrote: post #363
rectang wrote: post #296

Earlier quoted context omitted.

The result is a perpetually unstable situation fostering inevitable errors when the programmer is surprised by the compiler. There's no remedy except to move away from C to more tightly specified languages.

The problem is ecosystems like UNIX based platforms, that will never move to something else. The only solution is to throw them away, e.g. Android style.

Android threw away a unix based platform? News to me.

Re: Undefined behavior in C is a reading error

#373

Post by pjmlp »

PeterisP wrote: post #289
Animats wrote: post #221

Most of this discussion revolves around integer overflow. Part of the problem is that most of the computer hardware is now twos-complement arithmetic. Programmers think of that as part of the language. It's not, for C. C has run, in the past, on - 36 bit ones complement machines (DEC and UNIVAC) - Machines with 7-bit "char" (DEC) - Machines with 9-bit "char" (UNIVAC, DEC) - Machines where integer overflow yields a pr…

Explicit bounds everywhere mean that those bounds need to be automatically checked every time instead of only where explicitly specified by the programmer. This leads to safer code at a nontrivial performance tradeoff, one which would not be acceptable for C.

Something that Ada, Modula and Pascal compilers are able to optimize away in most cases.

C keeps targeting an hardware model that even most Arduinos are super computers by comparisasion.

Re: Undefined behavior in C is a reading error

#374

Post by pjmlp »

tomcam wrote: post #273
I_Byte wrote: post #197

Earlier quoted context omitted.

C was created during a time where instructions were executed linearly with no vectorization, memory was a flat space with no CPU caches, and there wasn’t a branch predictor that may or may not execute the correct program branch in advance. The list goes on but the rest is beyond my scope. C was designed for a now obsolete computer architecture model and over the years this old model has essentially become an abstract…

Thanks for the link. Excellent article. Those are all great points and I like having them summarized in one place, because I am indeed a little behind in my modern architecture theory. However it has always been acknowledged that C was by definition a sort of simplified computing model. For example, when I first learned see the 8086 architecture was popular but it was competing with many others and it was already dra…

C originated as an evolution from BCPL, with B a stopgap, as means to rewrite UNIX.

Thing is, BCPL main goal was an interim solution to Bootstrap CPL, nothing more than that.

https://en.wikipedia.org/wiki/CPL_(programming_language)

Unfortunely, UNIX's success means we got stuck with something that shouldn't be more than a portable macro assembler.

Re: Undefined behavior in C is a reading error

#375

Post by [deleted] »

nwallin wrote: post #249
layer8 wrote: post #149

Because there seems to be some confusion in this thread: - "Implementation-defined behavior" means that the C standard specifies the allowable behaviors that a C implementation must choose from, and the implementation must document its particular choice. - "Unspecified behavior" means that the C standard places no particular restrictions on the behavior, but a C implementation must pick a behavior and document its ch…

> - "Undefined behavior" means that C implementations are allowed to assume that the respective runtime condition does not ever occur, and for example can generate optimized code based on that assumption. Please note that the article is making the specific argument that this interpretation of UB is an incorrect interpretation. The author is arguing that you, me, the llvm and gcc teams are wrong to interpret UB that w…

[deleted]

Re: Undefined behavior in C is a reading error

#376

Post by pjmlp »

throwaway2048 wrote: post #372
pjmlp wrote: post #363

Earlier quoted context omitted.

The problem is ecosystems like UNIX based platforms, that will never move to something else. The only solution is to throw them away, e.g. Android style.

Android threw away a unix based platform? News to me.

It did, ask termux guys.

The Linux kernel is an implementation detail.

There is nothing UNIX related exposed to userspace.

Java and Kotlin applications, while NDK APIs are clearly defined,

https://developer.android.com/ndk/guides/stable_apis

Or Treble Project for that matter,

https://source.android.com/devices/architecture/hidl

Try to use private APIs (which is what the Linux underpinnings are) and the application might be blessed with being killed by the OS.

Re: Undefined behavior in C is a reading error

#377

Post by msbarnett »

vyodaiken wrote: post #325
msbarnett wrote: post #160

Earlier quoted context omitted.

> Can you provide even one real-world example where this makes a difference, i.e. not some microbenchmark Sure. I don't even have to leave this thread to find one: https://news.ycombinator.com/item?id=27223954 reports a measurable speed impact to PostgreSQL when compiled with -fwrapv, which rules out the exact optimization in question. This shouldn't be surprising; loops are extremely common and superscalar processor…

Sure, if you leave out error checks code runs faster. Compile mutexes to no-ops and get an even better speedup.

The optimizations impacted by -fwrapv have nothing whatsoever to do with “leaving out error checks”

Re: Undefined behavior in C is a reading error

#378

Post by Gibbon1 »

pjmlp wrote: post #367
rectang wrote: post #339

Earlier quoted context omitted.

I want default behavior which does not surprise me. I have come to understand that this probably means I want a different language, because the C spec essentially requires compiler authors to make optimizations which introduce surprising semantics in order to compete on performance with other languages. It would be fine if I could opt into new semantics — something like Rust's "editions" would resolve my objections a…

Only moving away to other languages will do it. C culture and to certain extent Objective-C and C++ ones are tainted by microptimizaitons while typing, where the compilers are the worst examples. Unfortunely UNIX and C go together, so those that want to keep UNIX like platforms around bettter fix C somehow.

I think that's unfair. The taint is 100% on the C++ side of things.

Hopefully the newer compiled languages will kill C++.

Re: Undefined behavior in C is a reading error

#379

Post by [deleted] »

alerighi wrote: post #263
nwallin wrote: post #249

Earlier quoted context omitted.

> - "Undefined behavior" means that C implementations are allowed to assume that the respective runtime condition does not ever occur, and for example can generate optimized code based on that assumption. Please note that the article is making the specific argument that this interpretation of UB is an incorrect interpretation. The author is arguing that you, me, the llvm and gcc teams are wrong to interpret UB that w…

By the way, dereferencing NULL is a well defined behaviour on every computer architecture: you are basically reading at address 0 of memory. It just causes a crash if you have an operating system since it will cause a page fault, but in kernel mode or in devices without an OS is a legit thing to do (and even useful in some cases). Why should C compilers make it undefined? The standard doesn't mandate that undefined b…

[deleted]

Re: Undefined behavior in C is a reading error

#380

Post by gpderetta »

pjmlp wrote: post #369
gpderetta wrote: post #199

Earlier quoted context omitted.

Exactly. For example there were programs 30-40 years ago that relied on exact stack layouts. These days everybody would agree they are completely broken. The issue of course is that it is extremely hard to write programs that have no UB. It would be nice for compilers to have an option to automatically introduce assetions whenever they rely on some UB-derived axiom, basically as a sort of lightweight sanitizer. In fa…

We had sanitizers since C exists, 1979 to be more exact. "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find inte…

I was going to add "in open source compilers" to hedge my statement :).

That seems to be a static analysis tool though (which generally have not been great). Did it also inject runtime checks?

Post reply on HN