Date: Wed, 19 Jan 2011 04:54:34 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Roman Divacky <rdivacky@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r217538 - in head/sys/dev: buslogic cs Message-ID: <20110119044805.Y2631@besplex.bde.org> In-Reply-To: <201101181215.46266.jhb@freebsd.org> References: <201101181523.p0IFNGeB042079@svn.freebsd.org> <20110119035030.W2099@besplex.bde.org> <201101181215.46266.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Jan 2011, John Baldwin wrote:
> On Tuesday, January 18, 2011 12:00:44 pm Bruce Evans wrote:
>> On Tue, 18 Jan 2011, John Baldwin wrote:
>>
>>> Log:
>>> Remove some always-true comparisons.
>>>
>>> Submitted by: clang via rdivacky
>>>
>>> Modified: head/sys/dev/buslogic/bt.c
>>>
> ==============================================================================
>>> --- head/sys/dev/buslogic/bt.c Tue Jan 18 14:58:44 2011 (r217537)
>>> +++ head/sys/dev/buslogic/bt.c Tue Jan 18 15:23:16 2011 (r217538)
>>> @@ -975,7 +975,7 @@ bt_find_probe_range(int ioport, int *por
>>> int
>>> bt_iop_from_bio(isa_compat_io_t bio_index)
>>> {
>>> - if (bio_index >= 0 && bio_index < BT_NUM_ISAPORTS)
>>> + if (bio_index < BT_NUM_ISAPORTS)
>>> return (bt_board_ports[bio_index]);
>>> return (-1);
>>> }
>>
>> So, what guarantees that isa_compat_io_t is unsigned and will remain so?
>> Indexes should be ints, unless you want a sign morass.
>
> Gah, I trusted the clang warning too much. enum's are ints in C yes? So
> clang has a bug if it thinks an enum value cannot be negative. In practice
> all the callers of this routine do not pass in negative values, but the
> compiler shouldn't warn about enum's bogusly.
I didn't know it was a problem already when I asked. I thought
isa_compat_io_t was global, but it is private to bt.
> Is clang assuming that only defined values for an enum are ever passed in? If
> so we probably don't want to turn that checking on for the kernel as we
> violate that in lots of places.
enum values are int, but an enum type may be implemented as unsigned if
that makes no difference for conforming code. I think conforming code can
only used declared enum values. Thus if all declared values are >= 0, as
is the case here, then the enum type may be implemented as unsigned.
Apparently, this happens for clang here, and it checks what it would do
itself. Other compilers might do it differently.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110119044805.Y2631>