On 04/22/2013 12:56 PM, Warlich, Christof wrote: > Andrew Haley [aph@xxxxxxxxxx] wrote: >> What do you think the conversion should do in this case? I find >> the current behaviour to be the least surprising. > > Well, it should at least give consistent values regardless of > the level of optimization being used. Why? It's undefined behaviour. As the saying goes, "Daemons might fly out of your nose." > I'm even having a (more complex) > C++ program that gives different values for each of the optimization > levels -O0, -O1 and -O2! I'd be really surprised if this doesn't > come to a surprise to anyone ;-). It certainly isn't a surprise to me. > To me (and the colleagues I've talked to), the "most expected" behaviour > would be: > > any flaot equal to or bigger than the biggest integer -> biggest integer > any flaot equal to or smaller than the smallest integer -> smallest integer Hmm, so float to int conversions "should" use saturation arithmetic. > This could even be driven further: > > INF+ -> biggest integer > INF- -> smallest integer > > and just to have one consistent definition for that: > > QNAN -> 0 > SNAN -> floating point exception > > But imho, anything, even "undefined (but fixed)", would be better than > "varying depending on the level of optimization". Well, UB is just UB: the user has no reasonable expectation of anything. Andrew.
