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

391–400 of 503 posts

Re: Undefined behavior in C is a reading error

#391

Post by pjmlp »

Gibbon1 wrote: post #378
pjmlp wrote: post #367

Earlier quoted context omitted.

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

Nope, the tait lies 100% on the copy-paste compatibilty with a C subset.

Re: Undefined behavior in C is a reading error

#392

Post by vyodaiken »

d110af5ccf wrote: post #338
vyodaiken wrote: post #314

Earlier quoted context omitted.

Leaving overflow to the processor is an example of ignoring it with unpredictable results. Deleting overflow checks because you assume, incorrectly, that overflow is impossible is not an example of ignoring with unpredictable effects, it does produce unpredictable effects, though.

How is the compiler supposed to know that a particular operation is intended as an overflow check though? It isn't a human and it doesn't actually comprehend the code it operates on. It just blindly applies rules. I want the compiler to eliminate redundant operations. That's a large part of the point of doing optimizations in my view! Best effort attempts to avoid eliminating obvious sanity checks are desired of cour…

You are advocating incorrect code that uses a few less machine operations than correct code.

Re: Undefined behavior in C is a reading error

#393

Post by vyodaiken »

saagarjha wrote: post #311
vyodaiken wrote: post #243

Earlier quoted context omitted.

That's good example, because nobody would complain if stack layouts changed and those programs failed. But if the compiler chooses to "optimize away" checks on stack layout, that's a different thing altogether. Also note that if you use pthreads or Linux clone or you are writing an operating system you can need to rely on exact stack layouts even today.

Stack layouts are only really relevant at ABI boundaries. In these cases the layout is usually specified in extensions to C or in other ways, such as handwritten assembly.

Linux clone, pthreads, and os code commonly look at stack boundaries

Re: Undefined behavior in C is a reading error

#394

Post by vyodaiken »

fooker wrote: post #257
vyodaiken wrote: post #147

Earlier quoted context omitted.

It is completely useless to allow compilers to assume false things about the code they generate.

It’s not useless. The assumption is not false if the program doesn’t have undefined behavior. The assumption allows the code to be a few times faster. To disallow this assumption would inhibit these optimizations.

a) the assumption is not false if it is not false! b) the speedup is not shown anywhere

Re: Undefined behavior in C is a reading error

#395

Post by Joker_vD »

cperciva wrote: post #170
Joker_vD wrote: post #69

Earlier quoted context omitted.

> all of the tricks which make "malloc" work, What are those, exactly? AFAIK, you can safely track memory addresses by storing them as intptr_t/uintptr_t.

The C standard says very little about how those types work. In particular, you can cast a pointer to one of them and then cast back to a pointer -- but only if you cast the exact same value back, and the intptr values are not guaranteed to be in any way meaningful. In particular, casting a pointer to intptr_t, doing arithmetic on it, and casting back is not guaranteed to do anything useful. It almost certainly will,…

> and casting back is not guaranteed to do anything useful

I believe it's implementation-specific, precisely so that malloc/free can be implemented in conformant C.

The only tricky part is how you can "bless" parts of large memory block originally pointed to by void* (returned from mmap(), for example) to safely become ints and char[]s and structs...

Re: Undefined behavior in C is a reading error

#396

Post by mjburgess »

scoutt wrote: post #385
mjburgess wrote: post #54

Commenters here seem to be missing the core thesis of this article. It's not about what the standard literally means; it's about it's spirit -- and the reason for its spirit. The issue is "undefined behaviour" should never have been interpreted this extremely. The standard may be silent on how extreme, but it is implausible to suggest that the standard was actually written to enable this. Compiler writers for C! dism…

The spirit of the article and your comment seems to underrate the efforts required to come up with something like the standard for a C compiler. It's not a "perverse shield". In C, "optimize for correctness" is the programmer's job. I don't want to sound dismissive, and I don't pretend you to write a compiler, but please tell me how would you word a global standard for generating compilers that can compile for hundre…

I am sympathetic with the view that compiler writers are trapped by the architectures they have to support.

However, I think there's just a philosophical difference here about what compilers are for: are they responsible for emitting correct programs; or are they for literal transpiling?

Regardless of the history which has led to the latter outcome for C, I have to agree with the author that I think K&R's original vision wasn't quite so accommodating.

Perhaps ignorantly, I just have to imagine there is something a little better than the present attitude.

Could there not be a --hault-on-all-undef with a serious attempt to realise that in as many respects as possible?

Re: Undefined behavior in C is a reading error

#397

Post by gpderetta »

pjmlp wrote: post #390
gpderetta wrote: post #380

Earlier quoted context omitted.

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?

No, but still not even that gets the love it deserve. And a famous commercial variant of it has been PC-lint from https://www.gimpel.com/ . Being available on open source compilers does little to change the culture, as per latest surveys only 11% of developers care to use any kind of tooling for improving their code quality in C and C++. At CppCon a couple of years ago, only about 1% of the audience answered positive…

Those numbers are indeed a bit depressing.

Re: Undefined behavior in C is a reading error

#398

Post by I_Byte »

scoutt wrote: post #386
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…

> now obsolete computer architecture model I think this is kind-of dismissive. You seem to assume that everyone is programming modern x86 machines. What about embedded? My little PIC32/STM32/ATMEGA do not have caches or predictors, and has a flat memory space. Thank god there is the C standard, that even today after more than 30 years, give compilers a clear set of rules allowing them to emit code for those thousands…

Ah, I didn’t mean to come off as dismissive. My bad. When I wrote my comment I only had consumer hardware on my mind. However, I realize that C isn’t simply limited to this new modern hardware either.

Re: Undefined behavior in C is a reading error

#399

Post by bregma »

alerighi wrote: post #259
bregma wrote: post #211

Earlier quoted context omitted.

from ISO/IEC 9899:2011 "Programming Languages -- C" 3.4.3 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner charac…

To me ignore the situation completely with unpredictable results would mean: the compiler generates an assembly that could not be correct, and then the behaviour of the program is determined by what the processor does. Doing something like removing checks is not ignoring the situation: is acting in some particular way when undefined behaviour is detected. And it has neither unpredictable results: it specifies what ha…

Compilers don't "detect undefined behaviour": they assume no undefined behaviour is present. It is not possible to change the semantics of the program that contains undefined behaviour because undefined behaviour means there are no valid semantics to begin with.

This is exactly the same situation as dividing by zero in mathematics. If your proof relies on division by zero, you can always prove anything true (the classic 1 == 0 proof for example).

Re: Undefined behavior in C is a reading error

#400

Post by tsimionescu »

systoll wrote: post #362
tsimionescu wrote: post #352

Earlier quoted context omitted.

It's not a huge leap, but it still doesn't mean that UB by definition means that the compiler is allowed to assume UB doesn't happen. Allowing the compiler to assume this is one reasonable result of this definition (I give an example of how this reasoning works somewhere else), but it is not equivalent to the definition of UB, in principle.

The definition logically implies that compilers are allowed to assume UB doesn't happen. The definition is: > undefined behavior: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements. With these optimisations, either: 1. The program contains no UB, the transformed code acts as expected, and the compilation is valid. 2. T…

It implies it, but they are not equivalent. Basically the common interpretation of UB is sufficient, but not necessary, given the standard.
Post reply on HN