From owner-cvs-all@FreeBSD.ORG Sat Dec 11 21:33:15 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A67316A4CF; Sat, 11 Dec 2004 21:33:15 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9663443D1F; Sat, 11 Dec 2004 21:33:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])iBBLXCKP002780; Sun, 12 Dec 2004 08:33:12 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) iBBLXA7M013239; Sun, 12 Dec 2004 08:33:11 +1100 Date: Sun, 12 Dec 2004 08:33:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Warner Losh In-Reply-To: <20041211.122854.74737190.imp@harmony.village.org> Message-ID: <20041212082325.T1972@epsplex.bde.org> References: <200412110711.iBB7BgLi030397@repoman.freebsd.org> <20041211.122854.74737190.imp@harmony.village.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: kientzle@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libarchive archive_entry.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 21:33:15 -0000 On Sat, 11 Dec 2004, Warner Losh wrote: > This also pointed out a bug in our mknod() routine in one edge case. > I believe we should return EINVAL when that happens in the syscall. > > Specifically "mknod foo c 255 0xffff00ff" results in a file foo with > major/minor number of 0. This is because VNOVAL is -1 and there > appear to be checks against it in the code later, hence we end up with > 0, 0. I believe that we should either make it work (hard), or we > should return EINVAL from the syscall wrapper or some routine early in > the path. I agree. It should return -1/EINVAL. A dev_t with value 0xffffffff can also be generated by badsect(1) now that daddr_t is 64 bits. badsect checks that the bad block number is representable as a dev_t, but it doesn't know that 0xffffffff is special. Also, it doesn't know that C99 broke long being longest, so its error message for unrepresentable block numbers (ones larger than 0xffffffff) is now broken on machines with < 64-bit longs. Bruce