Date: Sun, 12 Dec 2004 08:33:10 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@rover.village.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libarchive archive_entry.c Message-ID: <20041212082325.T1972@epsplex.bde.org> In-Reply-To: <20041211.122854.74737190.imp@harmony.village.org> References: <200412110711.iBB7BgLi030397@repoman.freebsd.org> <20041211.122854.74737190.imp@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041212082325.T1972>