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

C++ float-to-int conversion can be undefined behavior

kttnr.net

Post reply on HN
Print view View original

11–20 of 22 posts

Re: C++ float-to-int conversion can be undefined behavior

#11

Post by inigyou »

atiedebee wrote: post #6
Frieren wrote: post #5

Earlier quoted context omitted.

C++ was designed as an universal way of writing low level system code. It has some abstractions above C, but still allowing for all kinds of optimizations. (Think using a class vs a template, similar abstraction different impact). To use C++ to code user programs is the actual mistake. Think about assembly. Should assembly also be safe in all calls? That will make everything slower, and consume way more energy. Will…

I thought C++ was designed to fit all sorts of applications. There is many GUI libraries for C++ for example, and the language has all the capabilities to add abstractions for making these sorts of libraries easy to work with. I think you could argue that C was made for low level code, since the working group seems to be focussing on making the core of the language more usable instead of allowing for abstractions tha…

C was made as more portable assembly, and C++ was made to add lots of features to C.

Re: C++ float-to-int conversion can be undefined behavior

#12

Post by inigyou »

imtringued wrote: post #7
Frieren wrote: post #3

Earlier quoted context omitted.

> bizarre design decisions They are not bizarre but a good compromise between consistency and optimization for any possible existing and future CPU architecture. What the author correctly points out to is that GSL implementation does not remove that undefined behaviour as it lacks the proper checks. And that is the problem as it does not fulfill its own documented guarantees. tldr; C++ is just fine. The implementatio…

They are bizarre, because C developer culture isn't known for doing what is necessary to prove the absence of UB and memory safety problems. It's all up to the programmer who obviously won't invest the time because that would ruin the development velocity.

If UB was limited to dereferencing freed memory and so on, it would be better.

Re: C++ float-to-int conversion can be undefined behavior

#13

Post by aw1621107 »

inigyou wrote: post #10

Undefined behavior was, in most cases, intended to encompass a point where different implementations behaved in reasonable ways. In case of overflow, some implementations wrapped, some saturated, some threw an exception, some jumped to an interrupt handler, and some returned 0. They made it undefined intending to encompass all of these. Notice they are all fairly reasonable (except for returning 0). Later, stupid com…

> They made it undefined intending to encompass all of these.

Why wouldn't implementation-defined behavior suffice in this case?

Re: C++ float-to-int conversion can be undefined behavior

#14

Post by inigyou »

aw1621107 wrote: post #13
inigyou wrote: post #10

Undefined behavior was, in most cases, intended to encompass a point where different implementations behaved in reasonable ways. In case of overflow, some implementations wrapped, some saturated, some threw an exception, some jumped to an interrupt handler, and some returned 0. They made it undefined intending to encompass all of these. Notice they are all fairly reasonable (except for returning 0). Later, stupid com…

> They made it undefined intending to encompass all of these. Why wouldn't implementation-defined behavior suffice in this case?

IB means the implementation has to fully document what it does. Evidently they didn't want to impose that requirement.

Re: C++ float-to-int conversion can be undefined behavior

#15

Post by aw1621107 »

inigyou wrote: post #14
aw1621107 wrote: post #13

Earlier quoted context omitted.

> They made it undefined intending to encompass all of these. Why wouldn't implementation-defined behavior suffice in this case?

IB means the implementation has to fully document what it does. Evidently they didn't want to impose that requirement.

There's always unspecified behavior if documentation is considered to be too onerous.

Re: C++ float-to-int conversion can be undefined behavior

#16

Post by UncleMeat »

inigyou wrote: post #14
aw1621107 wrote: post #13

Earlier quoted context omitted.

> They made it undefined intending to encompass all of these. Why wouldn't implementation-defined behavior suffice in this case?

IB means the implementation has to fully document what it does. Evidently they didn't want to impose that requirement.

It also means that the behavior needs to be stable across time and that tools cannot report this behavior as a bug.

Re: C++ float-to-int conversion can be undefined behavior

#17

Post by UncleMeat »

Panzerschrek wrote: post #4
Frieren wrote: post #3

Earlier quoted context omitted.

> bizarre design decisions They are not bizarre but a good compromise between consistency and optimization for any possible existing and future CPU architecture. What the author correctly points out to is that GSL implementation does not remove that undefined behaviour as it lacks the proper checks. And that is the problem as it does not fulfill its own documented guarantees. tldr; C++ is just fine. The implementatio…

> C++ is just fine No it isn't. Using undefined behavior for things which can be implementation-defined behavior instead is harmful. It creates more space for bugs and security vulnerabilities.

What is an appropriate behavior for casting inf or nan to an integer?

Re: C++ float-to-int conversion can be undefined behavior

#18

Post by aw1621107 »

UncleMeat wrote: post #16
inigyou wrote: post #14

Earlier quoted context omitted.

IB means the implementation has to fully document what it does. Evidently they didn't want to impose that requirement.

It also means that the behavior needs to be stable across time and that tools cannot report this behavior as a bug.

> It also means that the behavior needs to be stable across time

I don't think IB has to be stable over time? For instance, whether and which extended integer types exist is IB and that has definitely changed over time.

> and that tools cannot report this behavior as a bug.

It's absolutely possible to report IB as a bug (or even fully-specified behavior, as demonstrated by -fsanitize=unsigned-integer-overflow or -fsanitize=implicit-integer-conversion).

Re: C++ float-to-int conversion can be undefined behavior

#19

Post by UncleMeat »

aw1621107 wrote: post #18
UncleMeat wrote: post #16

Earlier quoted context omitted.

It also means that the behavior needs to be stable across time and that tools cannot report this behavior as a bug.

> It also means that the behavior needs to be stable across time I don't think IB has to be stable over time? For instance, whether and which extended integer types exist is IB and that has definitely changed over time. > and that tools cannot report this behavior as a bug. It's absolutely possible to report IB as a bug (or even fully-specified behavior, as demonstrated by -fsanitize=unsigned-integer-overflow or -fsa…

IB is something that developers can rely on. If it changes out from under you thats a bug.

Re: C++ float-to-int conversion can be undefined behavior

#20

Post by [deleted] »

UncleMeat wrote: post #17
Panzerschrek wrote: post #4

Earlier quoted context omitted.

> C++ is just fine No it isn't. Using undefined behavior for things which can be implementation-defined behavior instead is harmful. It creates more space for bugs and security vulnerabilities.

What is an appropriate behavior for casting inf or nan to an integer?

[deleted]
Post reply on HN