From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ./configure --enable-check-lisp-object-type Date: Tue, 12 Apr 2022 21:34:50 +0300 Message-ID: <83mtgq40c5.fsf@gnu.org> References: <878rsack6p.fsf@gnus.org> <83o81642pq.fsf@gnu.org> <874k2ycg2p.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8962"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 12 20:36:52 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neLNj-00026a-7u for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 20:36:51 +0200 Original-Received: from localhost ([::1]:54078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neLNh-0007kg-Sd for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 14:36:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neLLj-0006ds-Kl for emacs-devel@gnu.org; Tue, 12 Apr 2022 14:34:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neLLi-0002tu-GL; Tue, 12 Apr 2022 14:34:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Hfik1+htRZCMgvnrDZLs/C7dLiGihzu4Pj7F48kQKo8=; b=G2HBvOjhAldX VQi0KWTDZHVfhLExJw4r6rfjuy8PxuE953FhHoOw7N0Z6LSR6L36e7ZBSTBzLSC1noNlB+oqe42Sj PLvk00a+1D6jxvMmXw+vYQ7jTG4ASWK0k5uKicXQLsCaj+zTbRPZFpbG5DcG5bewqg4c7/cuzIBV4 x8gvcOc/sdc71vRp4IPb7AnPWi/xkO9TkoMtvHN/RdWGidvRsKQX4KHLITTDVK530RdGNQ5hw7Q00 PWEAf6QTMs85SKNfwBTevdI5dGQTuRglodaraUFkNHJVoMr4A2k+GxkwrF+Ka4XvBmY91enWQ8yza aaR8t72jvhUOA4GZk0daQw==; Original-Received: from [87.69.77.57] (port=2984 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neLLi-0008Py-05; Tue, 12 Apr 2022 14:34:46 -0400 In-Reply-To: <874k2ycg2p.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 12 Apr 2022 20:27:42 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288332 Archived-At: > From: Lars Ingebrigtsen > Cc: Stefan Monnier , Andrea Corallo > , emacs-devel@gnu.org > Date: Tue, 12 Apr 2022 20:27:42 +0200 > > Eli Zaretskii writes: > > > That zero corresponds to the 'Lisp_Object command_modes' member of > > Aligned_Lisp_Subr, and in a build with --enable-check-lisp-object-type > > a Lisp_Object is a struct, so it must be initialized with {0}, not > > just a scalar zero. > > I can confirm that adding braces around the zero makes these warnings go > away. > > There's similar warnings in alloc: > > alloc.c: In function 'syms_of_alloc': > alloc.c:7838:6: warning: missing braces around initializer [-Wmissing-braces] > 7838 | {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) }, > | ^ > 7839 | { .a4 = watch_gc_cons_threshold }, > 7840 | 4, 4, "watch_gc_cons_threshold", {0}, 0}}; > | {} > > And adding braces around the zero does the trick there, too. And if you build without --enable-check-lisp-object-type, does it compile cleanly with the additional braces? > There's still a number of other warnings which may or may not be valid > (I haven't actually looked at them): > > In file included from dbusbind.c:26: > dbusbind.c: In function 'xd_signature': > lisp.h:409:38: warning: potential null pointer dereference [-Wnull-dereference] > 409 | #define lisp_h_XCAR(c) XCONS (c)->u.s.car > | ~~~~~~~~~~~~~~^~~~ > lisp.h:1498:10: note: in expansion of macro 'lisp_h_XCAR' > 1498 | return lisp_h_XCAR (c); > | ^~~~~~~~~~~ > lisp.h:409:38: warning: potential null pointer dereference [-Wnull-dereference] > 409 | #define lisp_h_XCAR(c) XCONS (c)->u.s.car > | ~~~~~~~~~~~~~~^~~~ I don't think this is related, it might be that defining Lisp_Object as a struct makes it easier (or harder) for the compiler to reason about the control flow. > Is the --enable-check-lisp-object-type build supposed to be without > warnings, or has that never been the ambition? It's supposed to be as clean as without that option, yes. It just seems that this option is rarely used, so it has bitrotted to some extent.