Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 18, 2013, 18:52 UTC
Message-ID: <CA+55aFzTy0x6X_dK54RO13s+zG9ynWG_8Ei=ZwT8a5B4=LQ94A@mail.gmail.com>
In-Reply-To: <CABURp0pj35j7+W_0gYNud2uuEoahugOMBW9ezTgPZ7YvgnBz8w@mail.gmail.com>

On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord <phil.hord@gmail.com> wrote:

Show 5 quoted lines

>
> Yes, I can tell by the wording of the error message that you are right
> and clang has a problem.  But the git code it complained about does
> have a real problem, because the result of "signed int a = ULONG_MAX"
> is implementation-defined.

Only theoretically.

Git won't work on machines that don't have 8-bit bytes anyway, so worrying about the theoretical crazy architectures that aren't two's complement etc isn't something I'd care about.

There's a whole class of "technically implementation-defined" issues in C that simply aren't worth caring for. Yes, the standard is written so that it works on machines that aren't byte-addressable, or EBCDIC or have things like 18-bit words and 36-bit longwords. Or 16-bit "int" for microcontrollers etc.

That doesn't make those "implementation-defined" issues worth worrying about these days. A compiler writer could in theory make up some idiotic rules that are still "valid by the C standard" even on modern machines, but such a compiler should simply not be used, and the compiler writer in question should be called out for being an ass-hat.

Paper standards are only worth so much. And that "so much" really isn't very much.

                Linus