From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50263)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1Vy0Pk-0002hg-Pn
	for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:35:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1Vy0Pb-0007k6-OE
	for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:35:24 -0500
Received: from mail-pb0-x235.google.com ([2607:f8b0:400e:c01::235]:46333)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1Vy0Pb-0007k2-HP
	for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:35:15 -0500
Received: by mail-pb0-f53.google.com with SMTP id ma3so12586361pbc.26
	for <qemu-devel@nongnu.org>; Tue, 31 Dec 2013 06:35:14 -0800 (PST)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <52C2D61E.4000804@twiddle.net>
Date: Tue, 31 Dec 2013 06:35:10 -0800
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
References: <1388496958-3542-1-git-send-email-peter.maydell@linaro.org>
	<1388496958-3542-4-git-send-email-peter.maydell@linaro.org>
	<52C2D2E2.7070203@twiddle.net>
	<CAFEAcA-Y_n=-U+_-MhN2o0wqYjpBr+b_6=zezEkcQs0HOryuBg@mail.gmail.com>
In-Reply-To: <CAFEAcA-Y_n=-U+_-MhN2o0wqYjpBr+b_6=zezEkcQs0HOryuBg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 03/22] softfloat: Add 16 bit integer to
	float conversions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Tom Musta <tommusta@gmail.com>, Peter Crosthwaite <peter.crosthwaite@xilinx.com>, Patch Tracking <patches@linaro.org>, Aurelien Jarno <aurelien@aurel32.net>, Michael Matz <matz@suse.de>, Alexander Graf <agraf@suse.de>, QEMU Developers <qemu-devel@nongnu.org>, Claudio Fontana <claudio.fontana@linaro.org>, Dirk Mueller <dmueller@suse.de>, Will Newton <will.newton@linaro.org>, Laurent Desnogues <laurent.desnogues@gmail.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>, "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>, Christoffer Dall <christoffer.dall@linaro.org>

On 12/31/2013 06:27 AM, Peter Maydell wrote:
> I was going for consistency with the convert-to-int16, which return
> int_fast16_t.

Perhaps, but in that case we've properly bounded the result; it's guaranteed to
be in range of int16_t.

> The existing int32_to_float* functions take int32, not int32_t,
> so this is the same semantics. You could argue that it would
> be better for all of them to take the exact type rather than
> the at-least-this-big type (it would let me drop a cast in the
> ARM code that calls these), I suppose.

Yes, that's what I'm arguing.  Of course, I'd forgotten that we already have
that problem, since my eyes refuse to see the lack of "_t" there.  But is that
existing bug any reason to extend the problem?

One of these days we should just clean up all the crap formatting, bogus types,
and stupid STATUS_* macros...


r~