From mint-bounce@lists.fishpool.fi  Sun Jan  1 23:02:22 2006
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
From: "Roger Burrows" <anodyne@cyberus.ca>
Organization: Anodyne Software
To: MiNT List <mint@fishpool.com>
Date: Sun, 01 Jan 2006 16:51:10 -0500
MIME-Version: 1.0
Subject: [MiNT] Small bug in fatfs.c?
Message-ID: <43B8087E.26086.E65525@localhost>
Priority: normal
X-mailer: Pegasus Mail for Windows (v4.02a)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: anodyne@cyberus.ca
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=3.9 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_SORBS
X-Spam-Level: ***

Hi!
While I was browsing through the FAT32 handler in order to check my 
understanding of special cluster numbers (end of chain, bad cluster etc), I 
came across what may be a bug.  In fatfs.c, it appears that the MAXCL() macro 
is *supposed* to return the maximum cluster number; for example, the test for 
valid cluster number is:

# define FAT_VALID32(cl, dev)	(((cl) >= MINCL (dev)) && ((cl) <= MAXCL (dev)))

In fact, MAXCL() appears to return maxcl, which has been set to (numcl+2), 
which [I think] is the maximum cluster number + 1.

My apologies if I've missed something obvious in all this ...

Roger Burrows