Groups > comp.lang.c > #14217 > unrolled thread

casting constant value from float to unsigned short - compiler bugs?

Started by	"news.aon.at" <mario_semo@hotmail.com>
First post	2011-12-02 10:06 +0100
Last post	2011-12-02 16:26 +0100
Articles	6 on this page of 46 — 18 participants

Back to article view | Back to comp.lang.c

Page 3 of 3 — ← Prev page 1 2 [3]

#15488

From	lawrence.jones@siemens.com
Date	2012-01-06 12:04 -0500
Message-ID	<06mjt8-jgb.ln1@jones.homeip.net>
In reply to	#15478

Michael Press <rubrum@pacbell.net> wrote:
> 
> Presumably truncating toward zero in the C standard 
> is to reduce the number of cases where conversion leads to overflow.

Actually, it was to simplify programmers' lives by acknowledging nearly
universal existing practice (and to agree with FORTRAN's requirements).
-- 
Larry Jones

If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin

[toc] | [prev] | [next] | [standalone]

#16261

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-01-26 09:08 -0800
Message-ID	<kfnr4ym2xze.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#15462

James Kuyper <jameskuyper@verizon.net> writes:

> On 01/05/2012 06:15 AM, Ben Bacarisse wrote:
> ...
>> While I like nothing better that good barney about definitions, lets not
>> lose sight of the fact that the C standard is not at all ambiguous about
>> the conversion that sparked this thread.  Talk of "readings" suggests
>> that there might be some doubt, but there isn't -- C's conversion from
>> floating to integer types "truncates towards zero".
>
> Michael has absolute certainty (justified or not) about the mathematical
> definition of "fractional part". Since the C standard provides no
> definition of it's own, if there were a single definition of the term
> that is universally used in the mathematical community, then that one is
> the one that should apply.  [snip]

I disagree with this thesis.  The Standard is not a math book;
what it is is a standards document.  Any term not defined in the
Standard itself, nor appearing in one of the listed references,
should be understood as used in "the general population", not by
defaulting to any more restricted subgroup, including mathematics.

[toc] | [prev] | [next] | [standalone]

#15477

From	Michael Press <rubrum@pacbell.net>
Date	2012-01-05 16:17 -0800
Message-ID	<rubrum-817E06.16175505012012@news.albasani.net>
In reply to	#15458

In article 
<0.8f2bb956cd2606be95b2.20120105111551GMT.87ipkq5riw.fsf@bsb.me.uk>,
 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article <pan.2012.01.04.09.11.01.416000@nowhere.com>,
> >  Nobody <nobody@nowhere.com> wrote:
> >
> >> On Tue, 03 Jan 2012 12:31:57 -0800, Michael Press wrote:
> >> 
> >> > By the C standard's implied definition the fractional
> >> > part of x is less than or equal to zero for x <= 0.
> >> 
> >> I read it as treating a floating-point value as:
> >> 
> >>         sign * (integer_part + fractional_part)
> >> 
> >> where both integer_part and fractional_part are non-negative. Converting
> >> to an integer discards fractional_part.
> >
> > What is your point here? 
> > What definition of fractional part does your reading imply?
> 
> While I like nothing better that good barney about definitions, lets not
> lose sight of the fact that the C standard is not at all ambiguous about
> the conversion that sparked this thread.  Talk of "readings" suggests
> that there might be some doubt, but there isn't -- C's conversion from
> floating to integer types "truncates towards zero".

I never said the C standard is ambiguous.
I note that it is at variance with the definition used in mathematics.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#14257

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2011-12-03 01:50 +0000
Message-ID	<0.c8393211569c1056f7dd.20111203015039GMT.87ty5is9sg.fsf@bsb.me.uk>
In reply to	#14247

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> On Fri, 02 Dec 2011 10:34:22 +0100, jacob navia wrote:
>> Yes. The first one is that the range for unsigned short is zero to
>> USHORT_MAX. Your program has undefined behavior since a negative value
>> will not go into an unsigned short, it is OUTSIDE its domain.
>
> Sorry, but this is nonsense. Negative numbers stored in unsigned integer 
> types "wrap around" - there is NO overflow for unsigned types, but all 
> arithmetic is done modulo USHORT_MAX+1. It is amazing that you are not 
> aware of this as a compiler writer!

It most certainly is not nonsense.  I would have put it differently, but
it is a more accurate summary /of the code in question/ than your
remarks.  You cut that context, which was of a conversion from float to
unsigned short.  This conversion in *not* done modulo USHRT_MAX+1.  To
be more accurate, it need not be done that way -- some implementations
may choose to do so since the result is undefined when the modulo
operation would kick in.

Jacob's "Your program has undefined behavior since a negative value will
not go into an unsigned short" is quite correct (assuming a 16-bit
unsigned short as everyone has been doing so far).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14222

From	James Kuyper <jameskuyper@verizon.net>
Date	2011-12-02 06:41 -0500
Message-ID	<jbadgv$fb7$1@dont-email.me>
In reply to	#14217

On 12/02/2011 04:06 AM, news.aon.at wrote:
> Hello,
> 
> I try to cast a constant value (-32766.5) to float and then to an unsigned 
> short.
> Once directly and once with an intermediate variable.
> 
>  unsigned short s=(unsigned short)((float)(-32766.5));
> 
> vs.
> 
>  float f=((float)(-32766.5));
>  unsigned short s=(unsigned short)f;
> 
> I use different compilers for this:
> 
> a) IBM Visual Age 3.5 (very old, 1995)
> b) Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 
> 80x86  (MS-C6)
> c) Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 
> 80x86 (VS2010)
> d) gcc version 2.95.2-6 19991024 (cygwin experimental)
> e) mingw32-gcc (GCC) 3.4.5 (mingw special) [Copyright (C) 2004 Free Software 
> Foundation, Inc.]
> f) WindRiver Vxw6.7 CrossCompiler: ccpentium (Wind River VxWorks G++ 
> DWARF-EH 4.1-131) 4.1.2 [Copyright (C) 2006 Free Software Foundation, Inc.]
> 
> a,b,c,d : give 0x8002 in both cases.
> 
> e,f give 0 (!) in the first case and 0x8002 in the 2nd cases
> 
> ??

"When a finite value of real floating type is converted to an integer
type other than _Bool, the fractional part is discarded (i.e., the value
is truncated toward zero)" (6.3.1.4p1), so -32766.5 is converted to
-32766. That section goes on to say that "If the value of
the integral part cannot be represented by the integer type, the
behavior is undefined." Since -32766 cannot be represented in any
unsigned type, all of the results you've gotten are equally conforming.
A conforming implementation could also have formatted your hard disk or
sent pornographic e-mail to your boss, though those are far less likely
to occur.

> Note : when i cast to a SHORT instead of an unsigned short in the first 
> case, ALL compilers give 0x8002

That's because short can can represent -32766. There is still a
conversion to unsigned short, which can't represent that value; but for
conversions from signed integer types to unsigned integer types, the
rules are different than for floating point types. If a value cannot be
represented in the new type, "the value is converted by repeatedly
adding or subtracting one more than the maximum value that can be
represented in the new type until the value is in the range of the new
type." (6.3.1.3p2). In this case, that means adding or subtracting one
more than USHORT_MAX, which is commonly 65536 (though it could be
larger). 65536-32766 == 0x8002.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#14231

From	Vincenzo Mercuri <vincenzo.mercuri@hotmail.it>
Date	2011-12-02 16:26 +0100
Message-ID	<h5mdncFVCuKJc0XTnZ2dnUVZ8hednZ2d@giganews.com>
In reply to	#14222

Il 02/12/2011 12:41, James Kuyper ha scritto:
...
> type." (6.3.1.3p2). In this case, that means adding or subtracting one
> more than USHORT_MAX, which is commonly 65536 (though it could be
> larger). 65536-32766 == 0x8002.

I just want to point out that there is no "USHORT_MAX".
It's USHRT_MAX (I would have preferred the one you wrote).

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

csiph-web

casting constant value from float to unsigned short - compiler bugs?

Contents

#15488

#16261

#15477

#14257

#14222

#14231