Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268900AbUIXQkj (ORCPT ); Fri, 24 Sep 2004 12:40:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268968AbUIXQkS (ORCPT ); Fri, 24 Sep 2004 12:40:18 -0400 Received: from fw.osdl.org ([65.172.181.6]:14743 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S268957AbUIXQbH (ORCPT ); Fri, 24 Sep 2004 12:31:07 -0400 Date: Fri, 24 Sep 2004 09:30:34 -0700 (PDT) From: Linus Torvalds To: Anton Altaparmakov cc: viro@parcelfarce.linux.theplanet.co.uk, Andrew Morton , linux-kernel@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net Subject: Re: [PATCH 8/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a bugfix In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1180 Lines: 27 On Fri, 24 Sep 2004, Anton Altaparmakov wrote: > > - Fix all the sparse bitwise warnings. Had to change all the enums > storing little endian values to #defines because we cannot set enums > to be little endian so we had lots of bitwise warnings from sparse. Btw, Al is fixing this. We'll make enum's properly typed, rather than just plain integers. It's not traditional C behaviour, but it gives you better type safety, and Al points out that other C compilers (the Plan 9 one, to be specific) have done the same thing for similar reasons. So we'll eventually be able to use enum's instead of #defines without losing any sparse information. Of course, the only case where it matters is exactly cases like this, where the difference between using an enum and a #define is basically a matter of taste. But since I agree that enum's can look a lot nicer, it's good to know that it's being worked on. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/