From owner-freebsd-current@FreeBSD.ORG Tue Jul 2 23:21:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF3A5D08; Tue, 2 Jul 2013 23:21:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id A35AA1B83; Tue, 2 Jul 2013 23:21:03 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r62NKxpr069314; Tue, 2 Jul 2013 16:20:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r62NKxLH069313; Tue, 2 Jul 2013 16:20:59 -0700 (PDT) (envelope-from sgk) Date: Tue, 2 Jul 2013 16:20:59 -0700 From: Steve Kargl To: Dimitry Andric Subject: Re: [PATCH] nvmecontrol breaks world Message-ID: <20130702232059.GA69299@troutmask.apl.washington.edu> References: <20130702201728.GA68544@troutmask.apl.washington.edu> <7513EF4A-7808-4DC5-B60E-3AE93ECF85D1@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7513EF4A-7808-4DC5-B60E-3AE93ECF85D1@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ed Schouten , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:21:03 -0000 On Tue, Jul 02, 2013 at 10:37:35PM +0200, Dimitry Andric wrote: > On Jul 2, 2013, at 22:30, Ed Schouten wrote: > > 2013/7/2 Steve Kargl : > >> Could someone (this could even be me, but need approval) please > >> fix nvmecontrol? > > > > off_t doesn't need to be intmax_t, right? Maybe add an explicit cast? > > Yes, that is what Bruce has suggested for off_t many times in the past. :-) > > > > Also, the call of malloc(sb.st_size) is not really safe... > > Sure, but that does not break buildworld (for gcc users, I assume? the tinderboxes are all green). > A gcc-only buildworld is broken on i386 without my patch. See http://lists.freebsd.org/pipermail/svn-src-all/2013-July/070954.html -- Steve