From owner-freebsd-current@freebsd.org Sun Dec 31 23:53:34 2017 Return-Path: Delivered-To: freebsd-current@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 4B3F0EADBB2 for ; Sun, 31 Dec 2017 23:53:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 3030969A0B; Sun, 31 Dec 2017 23:53:33 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eVnQ2-000GUZ-O8; Sun, 31 Dec 2017 15:53:32 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id vBVNrURa063398; Sun, 31 Dec 2017 15:53:30 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 31 Dec 2017 15:53:30 -0800 From: Oleksandr Tymoshenko To: Nathan Whitehorn Cc: freebsd-current@freebsd.org Subject: Re: SVN r327444 breaks current build Message-ID: <20171231235330.GA63368@bluezbox.com> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> <20171231222235.GA62313@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > Michael Butler (imb@protected-networks.net) wrote: > >> Building /usr/obj/usr/src/amd64.amd64/ [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Sun, 31 Dec 2017 23:53:34 -0000 Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > Michael Butler (imb@protected-networks.net) wrote: > >> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > >> --- vt_termcolors.o --- > >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > >> arguments to function call, expected 4, have 5 > >> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > >> &g, &b) == 0) { > >> ~~~~~~~~~~~~~~~~~~~~ > >> ^~ > >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > >> 'vt_parse_rgb_triplet' declared here > >> static int > >> ^ > >> 1 error generated. > >> *** [vt_termcolors.o] Error code 1 > >> > >> .. second time today a commit wasn't tested before commit :-( > >> > >> imb > > Should be fixed in r327449. It was a sloppy job, I was making iterative > > improvements to the original patch following review feedback and used > > out-of-tree testcases for actual testing. I appologize for the breakage. > > > Still broken with GCC. > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function > declaration isn't a prototype [-Wstrict-prototypes] > *** [vt_termcolors.o] Error code 1 *sigh* Should be fixed in r327454. Thanks for reporting I wonder if we can get clang to be more strict about declarations/prototypes/etc to match gcc's expectations. I understand that it's developers' responsibility to make sure that kernel is GCC-buildable but if raising red flag for some of the cases when compiling with clang reduced number of these breakages that it'd be an improvement. -- gonzo