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

Undefined Behavior in 2017

blog.regehr.org

Post reply on HN
Print view View original

71–80 of 120 posts

Re: Undefined Behavior in 2017

#71

Post by wamaral »

jerf wrote: post #65
wamaral wrote: post #64

Earlier quoted context omitted.

Then by all means reject it, way better than blowing up in production.

You just destroyed all C code in the world. At that level of paranoia, you've basically defined a brand new language, and if you're going to do that, why make it C at all? Smart people with a ton of experience in C have already examined the possibility of defining a C dialect with much less undefined behavior in it. In fact, I believe it's been seriously tried more than once by independent groups. And the result has…

OP was talking about a compiler option, that most likely would not break anything unless you enable the flag.

As for choice, I'll take "here's what happens" vs "your code is in the hands of fate now" any day. Glad we do have choice.

Re: Undefined Behavior in 2017

#72

Post by caf »

userbinator wrote: post #56
the8472 wrote: post #46

> Loops that Neither Perform I/O nor Terminate > Summary: This UB is probably not a problem in practice (even if it is moderately displeasing to some of us). Since LLVM is mostly based around C/C++ semantics this actually turned out to be a problem for rust, because rust can encode diverging functions in its type system and assume certain code sections to be unreachable. If the compiler then optimizes out code and th…

I think that's a great example of how optimisers have gone off the deep end: no reasonable human programmer would think "I can't figure out if this loop terminates, so let's just leave it out", but that appears to be the default behaviour in this case --- when what should happen when the optimiser "gives up" is that it should just translate the code verbatim.

N1528: Why undefined behavior for infinite loops? (Boehm)

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

Re: Undefined Behavior in 2017

#73

Post by runevault »

clarry wrote: post #55
userbinator wrote: post #51

Earlier quoted context omitted.

I think it's the compilers that have perverted the language to such an extent that it's become ridiculously difficult to understand, and so it's the compilers that must change back to being less obtuse and adversarial. The C standard even suggests, when defining undefined behaviour, that one of the possible options is "behaving during translation or program execution in a documented manner characteristic of the envir…

> If signed int arithmetic on the hardware wraps around upon overflow, then take that into account when optimising and don't assume it can't overflow. This is how C programmers want the language to work; Don't speak for all of us. Some of us may take the language for what it is, instead of assuming it to be a "high level portable assembler" which it is not, but which a particular implementation of it may be, thanks t…

They CAN accommodate all users, just have compile time options you can enter in your make file/on the command line/etc to say what level of bounds checking/etc you want compiled into your code. Hell that way even within a given project you can choose "this library I'm nervous about so I'll eat the hit on bounds checking".

Re: Undefined Behavior in 2017

#74

Post by lorenzhs »

unrealhoang wrote: post #70
jabot wrote: post #36

Earlier quoted context omitted.

"Very easy" - well, if you think garbage collection is easy... And yes, if you want to allow manual allocation of objects and setting pointers to arbitrary objects, then your two choices are: 1) garbage collection 2) undefined behavior (use-after-free, double-free, dangling pointers, etc.)

Or RAII, a la Rust

"RAII is associated most prominently with C++ where it originated" (https://en.wikipedia.org/wiki/RAII)

Re: Undefined Behavior in 2017

#75

Post by eru »

lukego wrote: post #25
chrisdew wrote: post #2

How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?

LuaJIT is another modern low-level language. It has some remarkable undefined behavior like the evaluation order for function arguments. Scares me a bit. https://github.com/LuaJIT/LuaJIT/issues/238

Are you sure that undefined, instead of merely unspecified?

Ie function arguments are still evaluated in some (possibly changing) order. C++ undefined behavior allows to eg format your hard disk or launch the nukes.

Re: Undefined Behavior in 2017

#76

Post by eru »

caf wrote: post #50
pjmlp wrote: post #29

Earlier quoted context omitted.

Not if the language standard doesn't allow for UB to begin with, then there isn't any halting problem to worry about. This is what the alternatives in the memory safe systems programming language since Algol days do. Surely they still allow for developers to disable some of those checks explicitly , but then it is the programmers fault to choose "performance trumps correctness" instead of "correctness trumps performa…

It doesn't matter if the language defines the behaviour of, say, offsetting an array beyond its declared bounds. That doesn't change the general undecidability of statically proving the offset will always be within the bounds at compile-time - in other words, you need runtime checks in some cases (it's just a matter of whether the compiler or the programmer supplies them).

Nah, with some help from the programmer, you can produce those proofs. It's not too hard.

The halting problem is impossible to solve for arbitrarily evil programs, but that doesn't mean that it's impossible to write programs that are easy to analyse.

Re: Undefined Behavior in 2017

#77

Post by gpderetta »

eru wrote: post #76
caf wrote: post #50

Earlier quoted context omitted.

It doesn't matter if the language defines the behaviour of, say, offsetting an array beyond its declared bounds. That doesn't change the general undecidability of statically proving the offset will always be within the bounds at compile-time - in other words, you need runtime checks in some cases (it's just a matter of whether the compiler or the programmer supplies them).

Nah, with some help from the programmer, you can produce those proofs. It's not too hard. The halting problem is impossible to solve for arbitrarily evil programs, but that doesn't mean that it's impossible to write programs that are easy to analyse.

I think that statically guaranteeing something like in-bound indexing or absence of division by zero you need depended types, which is not exactly easy nor mainstream. And even with dependent types, many non-evil, otherwise correct programs will be rejected.

Re: Undefined Behavior in 2017

#78

Post by pjmlp »

runevault wrote: post #73
clarry wrote: post #55

Earlier quoted context omitted.

> If signed int arithmetic on the hardware wraps around upon overflow, then take that into account when optimising and don't assume it can't overflow. This is how C programmers want the language to work; Don't speak for all of us. Some of us may take the language for what it is, instead of assuming it to be a "high level portable assembler" which it is not, but which a particular implementation of it may be, thanks t…

They CAN accommodate all users, just have compile time options you can enter in your make file/on the command line/etc to say what level of bounds checking/etc you want compiled into your code. Hell that way even within a given project you can choose "this library I'm nervous about so I'll eat the hit on bounds checking".

They do it, but the performance culture among C devs doesn't appreciate enabling them.

https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che...

https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-...

I bet not much UNIX software compiled with gcc enables them.

Android is probably the only OS that does make use of them.

https://android-developers.googleblog.com/2017/04/fortify-in...

Re: Undefined Behavior in 2017

#79

Post by iainmerrick »

adrianN wrote: post #61
userbinator wrote: post #56

Earlier quoted context omitted.

I think that's a great example of how optimisers have gone off the deep end: no reasonable human programmer would think "I can't figure out if this loop terminates, so let's just leave it out", but that appears to be the default behaviour in this case --- when what should happen when the optimiser "gives up" is that it should just translate the code verbatim.

But the optimizer doesn't give up in this case. It successfully figures out that the loop has no side effect except heating up your processor and eliminates it.

What's the advantage of eliminating the loop?

If the compiler is able to do that analysis, why not flag the endless spin loop as a compilation error?

Re: Undefined Behavior in 2017

#80

Post by pjmlp »

jabot wrote: post #67
pjmlp wrote: post #38

Earlier quoted context omitted.

> garbage collection is easy... Garbage collection isn't the only way of writing mostly safe systems programs. ESPOL, NEWP are 10 year older than C. PL/8 was the systems programming language used by IBM for their first RISC mainframe, followed by PL/S. Mesa used at Xerox PARC. Modula-2 used at ETHZ and many 16 bit systems. Object Pascal used to write the first versions of Mac OS and Lisa. Ada and SPARK used by high i…

Well, I don't know about half of these programming languages. However: - ADA requires garbage collection - Modula-2 and Object pascal have manual memory management, i.e.: "new" and "delete" - together with double-free, use-after-free, and dangling pointers... I agree that C is by far worse, but please recognize that at least some of the undefined behavior problems are really hard to solve. EDIT: Oh, and we haven't st…

What about learning to understand English?

"writing mostly safe systems programs."

Do you understand what mostly means?

Ada and Modula-2 have multi-threading as part of their ISO/ANSI language standard.

Also you don't seem to know much about Ada given your GC remark, but here is some learning.

https://archive.fosdem.org/2016/schedule/event/ada_memory/

Of course there are still use cases where Algol derived languages are still unsafe, however those use cases are a tiny portion of what happens in C land.

Post reply on HN