From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: daniel sutton Newsgroups: gmane.emacs.devel Subject: Re: Fixing compilation and byte-compilation warnings before 25.1 Date: Fri, 13 Nov 2015 23:54:21 -0600 Message-ID: References: <5645F670.9040601@online.de> <56460E2B.10603@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1142a30ebb8c3f052479ced0 X-Trace: ger.gmane.org 1447480481 25849 80.91.229.3 (14 Nov 2015 05:54:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2015 05:54:41 +0000 (UTC) To: Paul Eggert , =?UTF-8?Q?Andreas_R=C3=B6hler?= , emacs-devel@gnu.org, Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 06:54:40 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZxTnJ-0000ke-Fb for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 06:54:37 +0100 Original-Received: from localhost ([::1]:58699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxTnI-000596-J5 for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 00:54:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxTn5-00058w-V0 for emacs-devel@gnu.org; Sat, 14 Nov 2015 00:54:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxTn4-00029V-QW for emacs-devel@gnu.org; Sat, 14 Nov 2015 00:54:23 -0500 Original-Received: from mail-io0-x22f.google.com ([2607:f8b0:4001:c06::22f]:33279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxTn4-00029R-Lv for emacs-devel@gnu.org; Sat, 14 Nov 2015 00:54:22 -0500 Original-Received: by iouu10 with SMTP id u10so110347538iou.0 for ; Fri, 13 Nov 2015 21:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+c+E5DkUOvocgxuVAKS+3TFtLkc6yqiaNNxQ0X8H0sc=; b=Z95kX8O27Lu+ZQJwyDA2xZhzJZJYE81U43hgh+jOReYOa4veAuXJ9EGMPNtN7nLVsb t4oBrm/xwmohjTFc/FYt7WvQC6FFJ3EDj+W92HxKLQxAtBUx2PuPOZHNU7XoV7mcvH4g 2COR/ZAyjL3IZQWgKCMX3QBh28fWmGcs+xM9FgxMdjbGw1TCdv3sInaWXM+nnAAV3kq3 dS1bvLg5AcKlTohMwo5udjuUk7Y2xbEokG0LaOGcqiDE/TSnXu6II9Z/rCP9t7RaHBd8 ia5pQldN5zWhSu0KXkAddDRlZDvRM/rxvXylxBr1oriLCxQKT3sNdC5Ke5SkK1cVSZdF enWQ== X-Received: by 10.107.167.9 with SMTP id q9mr15538551ioe.84.1447480461591; Fri, 13 Nov 2015 21:54:21 -0800 (PST) Original-Received: by 10.107.15.229 with HTTP; Fri, 13 Nov 2015 21:54:21 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c06::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194431 Archived-At: --001a1142a30ebb8c3f052479ced0 Content-Type: text/plain; charset=UTF-8 Hello everyone. I'm a bit new to mucking about in the internals of emacs but wanted to help out with cleaning up some compiler and byte compiler warnings. I'm building and noticing the error minibuffer.el:1697:12 display-completion-list called with 2 arguments but accepts only 1. I'm a little confused as the this function has this signature: (defun display-completion-list (completions &optional common-substring) ...) In fact, this is a recursive call inside of the function display-completion-list. Can someone help me understand why we are getting a compiler warning about seemingly valid usage of optional arguments? On Fri, Nov 13, 2015 at 5:00 PM, John Wiegley wrote: > >>>>> Paul Eggert writes: > > > I also occasionally run valgrind on Emacs executables (actually, temacs), > > and try to fix the warnings it generates. This is considerably harder to > do, > > but is a real nice thing to have on our checklist. (Right now, for > example, > > there are a couple of memory-allocation bugs that I really would rather > be > > fixing than writing administrative text like this. :-) > > I'm also working at getting the Coverity scan of Emacs running again. > > Warnings-free may not be practically achievement except in terms of some > "reference machine" (i.e., version of Linux + version of GCC), but having > some > form of such a goal is better than not. > > John > > --001a1142a30ebb8c3f052479ced0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone. I'm a bit new to mucking about in the = internals of emacs but wanted to help out with cleaning up some compiler an= d byte compiler warnings.

I'm building and noticing = the error=C2=A0
minibuffer.el:1697:12 display-completion-list cal= led with 2 arguments but accepts only 1. =C2=A0

I&= #39;m a little confused as the this function has this signature:=C2=A0
(defun display-completion-list (completions &optional common-subs= tring) ...)
In fact, this is a recursive call inside of the funct= ion display-completion-list.=C2=A0

Can someone hel= p me understand why we are getting a compiler warning about seemingly valid= usage of optional arguments?

On Fri, Nov 13, 2015 at 5:00 PM, John Wiegley <jw= iegley@gmail.com> wrote:
>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> I also occasionally run valgrind on Emacs executables (actually, temac= s),
> and try to fix the warnings it generates. This is considerably harder = to do,
> but is a real nice thing to have on our checklist. (Right now, for exa= mple,
> there are a couple of memory-allocation bugs that I really would rathe= r be
> fixing than writing administrative text like this. :-)

I'm also working at getting the Coverity scan of Emacs running a= gain.

Warnings-free may not be practically achievement except in terms of some "reference machine" (i.e., version of Linux + version of GCC), bu= t having some
form of such a goal is better than not.

John


--001a1142a30ebb8c3f052479ced0--