From owner-svn-src-head@freebsd.org Tue Nov 10 15:42:18 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48BF6A2B1EF; Tue, 10 Nov 2015 15:42:18 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B5BF1E6B; Tue, 10 Nov 2015 15:42:17 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by ykdv3 with SMTP id v3so819900ykd.0; Tue, 10 Nov 2015 07:42:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=JZe8XkkpSJUGsarenOS0qzfoilPyYsNKG+6/0iNqJbM=; b=QgIva4F1QUZ+WNlrNEq7+yqc2te/7K1QWSX1KdYyiS+Q//hR1Xj23/1wfs5VIRt6/F s9fKtkkm+yqZ/MgNgHubu5XVdovLJJYa1CZGHS7jhBq3ORzevoWMJm0JpvWv8a640+3P 66mxZh0bkE8RSy0lO6k9IXIdgHE5zIGq/UPi3QNGb7KPlh7gQHJL16qT8cwlRsDVyn1C rKteHP9E24AEdBxndP9jNdNYskeVT4qja/T56YBTVFlKwFvx3KEc7BssSrfLq6FN+T+E vE3KzHOtOvdmgD1rTQg+A9c1rLdnEIA3bBqm+pw8GcSqx9b9mYf+2dZvapi9Uv7vzGBg Sduw== X-Received: by 10.129.33.198 with SMTP id h189mr3465881ywh.287.1447170131171; Tue, 10 Nov 2015 07:42:11 -0800 (PST) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com. [209.85.160.175]) by smtp.gmail.com with ESMTPSA id n186sm4797519ywb.7.2015.11.10.07.42.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2015 07:42:11 -0800 (PST) Received: by ykfs79 with SMTP id s79so752122ykf.1; Tue, 10 Nov 2015 07:42:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.102.5 with SMTP id a5mr3928637ywc.9.1447170130673; Tue, 10 Nov 2015 07:42:10 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.17.2 with HTTP; Tue, 10 Nov 2015 07:42:10 -0800 (PST) In-Reply-To: <1447168083.91061.2.camel@freebsd.org> References: <201511091650.tA9Gog7d061645@repo.freebsd.org> <20151110080516.M4088@besplex.bde.org> <5641A056.2040805@selasky.org> <1447168083.91061.2.camel@freebsd.org> Date: Tue, 10 Nov 2015 07:42:10 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r290613 - head/sys/compat/linuxkpi/common/include/linux From: Conrad Meyer To: Hans Petter Selasky , Ian Lepore Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 15:42:18 -0000 On Tue, Nov 10, 2015 at 7:08 AM, Ian Lepore wrote: > On Tue, 2015-11-10 at 08:44 +0100, Hans Petter Selasky wrote: >> > -sysctl_root_handler_locked(struct sysctl_oid *oid, void *arg1, >> > intptr_t arg2, >> > +sysctl_root_handler_locked(struct sysctl_oid *oid, void *arg1, >> > intmax_t arg2, >> > struct sysctl_req *req, struct rm_priotracker *tracker) >> >> Given that the second argument is sometimes used for pointers, maybe >> we >> should keep it intptr_t. Or add a compile time assert that >> sizeof(intmax) >=3D sizeof(intptr_t) which I think doesn't hold? > > If intmax_t is the "maximum width integer type" and intptr_t is > "integer type capable of holding a pointer", I think by definition > sizeof(intmax_t) must be >=3D sizeof(intptr_t). On the other hand, given > the perverse way standards-writers think, I'm not sure "big enough" is > all it takes to qualify as "capable of holding a pointer". But I think > in reality it'll work out right anyway. +1 to what Ian said. In any C99 implementation where intptr_t is defined, I believe intmax_t must be at least as big. See =C2=A7 7.18.1.5, "Greatest-width integer types," and =C2=A7 7.18.1.4, "Integer types capable of holding object pointers." > The following type designates a signed integer type with the property tha= t any valid pointer to void can be converted to this type, then converted b= ack to pointer to void, and the result will compare equal to the original p= ointer: intptr_t > > The following type designates a signed integer type capable of representi= ng any value of any signed integer type: intmax_t Given that intptr_t exists in our implementation and is a signed integer type, I see no reason why intmax_t could possibly not represent any such value. Same argument for the unsigned variants. Best, Conrad