From owner-cvs-all Thu Jun 6 17:34:19 2002 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9B45837B403; Thu, 6 Jun 2002 17:33:56 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA15856; Fri, 7 Jun 2002 10:33:53 +1000 Date: Fri, 7 Jun 2002 10:34:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "J. Mallett" Cc: cvs-committers@FreeBSD.org, Subject: Re: cvs commit: src/bin/ps fmt.c In-Reply-To: <200206062029.g56KTej24391@freefall.freebsd.org> Message-ID: <20020607101000.R13287-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 6 Jun 2002, J. Mallett wrote: > jmallett 2002/06/06 13:29:40 PDT > > Modified files: > bin/ps fmt.c > Log: > Cast arg_max to size_t when comparing it (times 4, plus 1) against SIZE_MAX. I > was worried about truncation of arg_max by this cast, but if it gets truncated, > we know it'll obviously be greater than SIZE_MAX anyway. This turns a correct bounds check into a broken one just to fix a warning. arg_max (times 4, plus 1) has already been checked to be a postitive long. Converting it to a size_t may truncate it to a very small value that is less than SIZE_MAX, resulting in the bounds check bogusly succeeding. Example of sizes where this may happen: ARG_MAX = 4096 /* minimum permitted by POSIX, type obscure */ arg_max = 4096L /* type long, so that it can hold sysconf() */ 4 * arg_max + 1 = 16385L size_t = uint8_t /* impractical but easy to see problems with */ size_t(arg_max) = (size_t)1 4 * (size_t)arg_max + 1 = (int)5 SIZE_MAX = 255 /* type promoteof(size_t) (?) */ The 4 * arg_max + 1 > SIZE_MAX but 4 * (size_t)arg_max + 1 < SIZE_MAX. Note that in this example, it's not completely clear that casting to size_t even fixes the warning, since the cast is in the wrong place so it doesn't have its intended effect of promoting the left operand to a size_t. The left operand has type int after the default promotions, so we might get a warning anyway if the right operand has type size_t. However, I think SIZE_T can't have type size_t in this case, since I think it is specified to be a preprocessor constants and preprocessor constants can't have type uint8_t. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message