From owner-svn-src-head@freebsd.org Fri Aug 25 18:59:06 2017 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 42C0FDDF26F for ; Fri, 25 Aug 2017 18:59:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BAC36CAB4 for ; Fri, 25 Aug 2017 18:59:05 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 525eebba-89c7-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 525eebba-89c7-11e7-950d-03a3531dacf2; Fri, 25 Aug 2017 18:58:03 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v7PIvtqV004074; Fri, 25 Aug 2017 12:57:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1503687475.56799.16.camel@freebsd.org> Subject: Re: svn commit: r322893 - head/bin/dd From: Ian Lepore To: Warner Losh , Matt Joras Cc: "Conrad E. Meyer" , Alan Somers , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Date: Fri, 25 Aug 2017 12:57:55 -0600 In-Reply-To: References: <201708251531.v7PFVtoZ038242@repo.freebsd.org> <4b016f89-61c5-fc8a-a36a-aca8166c369e@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Fri, 25 Aug 2017 18:59:06 -0000 On Fri, 2017-08-25 at 12:09 -0600, Warner Losh wrote: > On Fri, Aug 25, 2017 at 12:02 PM, Matt Joras > wrote: > > > > > On 08/25/2017 10:17, Conrad Meyer wrote: > > > > > > This change seems to break buildworld on MIPS: > > > > > > /home/cem/head.svn/bin/dd/args.c: In function 'f_bs': > > > /home/cem/head.svn/bin/dd/args.c:188: warning: format '%zd' > > > expects > > > type 'signed size_t', but argument 3 has type 'long int' > > > /home/cem/head.svn/bin/dd/args.c: In function 'f_cbs': > > > /home/cem/head.svn/bin/dd/args.c:199: warning: format '%zd' > > > expects > > > type 'signed size_t', but argument 3 has type 'long int' > > > /home/cem/head.svn/bin/dd/args.c: In function 'f_ibs': > > > /home/cem/head.svn/bin/dd/args.c:245: warning: format '%zd' > > > expects > > > type 'signed size_t', but argument 3 has type 'long int' > > > /home/cem/head.svn/bin/dd/args.c: In function 'f_obs': > > > /home/cem/head.svn/bin/dd/args.c:266: warning: format '%zd' > > > expects > > > type 'signed size_t', but argument 3 has type 'long int' > > > > > > (Yes, it's odd that the SSIZE_MAX constant has 'long' type.) > > > > > SSIZE_MAX should have type long, since ssize_t is a long on mips > > (and > > other arches besides i386 and arm). > > > > Re: the build failure, that's in the GCC C format string checking, > > so > > perhaps it's more accurate to say this breaks the (in-tree) GCC > > build. > > %zd is the right format specifier for ssize_t. I guess GCC's format > > string checking is getting confused because SSIZE_MAX is a constant > > that > > expands to type long. Perhaps casting to ssize_t would GCC happier, > > but > > that looks rather wrong. > > > This is why it was cast in the first place due to issues with exact > type. > Maybe we should put the casts back for the printfs. > > Warner I think the right fix is to define SSIZE_MAX correctly based on the type of ssize_t.  The x86 and powerpc _limits.h files get this right, it looks like mips is the only one with both 32 and 64-bit support that doesn't define SSIZE_MAX based on ssize_t type. -- Ian