This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [PATCH] Avoid signed/unsigned comparison
- From: Josh Stone <jistone at redhat dot com>
- To: elfutils-devel at sourceware dot org
- Date: Thu, 27 Apr 2017 17:35:36 -0700
- Subject: Re: [PATCH] Avoid signed/unsigned comparison
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jistone at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 57136248525
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 57136248525
- References: <1544575c-bba2-f196-3485-eb56b206b3d0@qt.io> <20170427182446.GD2061@stream>
On 04/27/2017 11:24 AM, Mark Wielaard wrote:
> On Thu, Apr 20, 2017 at 04:40:30PM +0200, Ulf Hermann wrote:
>> Some compilers implicitly cast the result of uint_fast16_t *
>> uint_fast16_t to something signed and then complain about the
>> comparison to (unsigned) size_t.
>
> Really? That is allowed? Using a signed type for uint_fast16_t?
I think integer promotion (which happens before the operation) may use a
signed int. It has to preserve the sign of the value itself, but I
think not necessarily the signedness of the resulting type.
Glibc uses "unsigned int"/"unsigned long int" for uint_fast16_t on
32/64-bit platforms, which means you won't get integer promotion.