From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: Is it time to remove INTERNAL_FIELD? Date: Thu, 23 Apr 2015 15:30:26 +0200 Message-ID: <87fv7r3rbh.fsf@gmail.com> References: <87lhhjuq26.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429796195 23578 80.91.229.3 (23 Apr 2015 13:36:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 13:36:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 23 15:36:31 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 1YlHIk-00078w-VW for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 15:36:23 +0200 Original-Received: from localhost ([::1]:40260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHIf-0001Cn-63 for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 09:36:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHIa-0001AK-MS for emacs-devel@gnu.org; Thu, 23 Apr 2015 09:36:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlHIX-0006ZJ-F6 for emacs-devel@gnu.org; Thu, 23 Apr 2015 09:36:12 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:34673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHIX-0006ZF-9G for emacs-devel@gnu.org; Thu, 23 Apr 2015 09:36:09 -0400 Original-Received: by wicmx19 with SMTP id mx19so12746534wic.1 for ; Thu, 23 Apr 2015 06:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=NZi/fwlRnhNc8o4WEDXBST6oB3jQ39+41A8tJiKT3W8=; b=n6Y6/3Eqq06ZDxwSDjVYXu+bGhgxxXk2g+n/BYksRPPbmdCBxzeofs4njrdCJuufbE Rz8YkbX29IcSbFV6zA5XV7pH9NNH25wsNm9C6KWhMXDSO0M+bDYQ206UAfJ9OzvSVLPZ 2SNvyhb97doXPKWWW/SniA8CWs5EcQ0BBLblsWyXLqJCloUbTYHJH4zRlplzvzSoTsQf aN6SI4VRzjdL22JFA9fLHQIS7PZujWaYxRUCCIMcvSPz+Awb2HSApm5wjSu/gBh+up6w GcxBJROUby3U6A8NrsXhj22EizitsqHiu3dkJYQjxz5r1kLJL1/Punyk3dhL1VbB+5e3 0vyQ== X-Received: by 10.194.223.5 with SMTP id qq5mr5703337wjc.152.1429796168644; Thu, 23 Apr 2015 06:36:08 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id ln8sm12181462wjc.18.2015.04.23.06.36.08 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Apr 2015 06:36:08 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Thu, 23 Apr 2015 09:24:03 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::235 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:185812 Archived-At: Stefan Monnier writes: >> This macro looks to me as more confusing than useful: > > It's there to make sure people don't write code which accesses the > field directly by accident. It seems harmless and occasionally > marginally useful. > Why does it bother you, exactly? I'm not very experienced in C, more in C++. I really like to know the types of the data structures that I'm accessing. It's hard to see the structure past the macros, so I think if a macro doesn't provide a clear advantage it should be removed. >> Can I remove it? > > I guess it's OK to remove it, tho I fail to see the harm in keeping it. As I'm new to the Emacs C code base, it's easier for me to look at it without this macro. If you want to make C sources easier to read for new people, we should remove the macros that don't do anything. As for accidental access, I'm sure these rare errors will be caught by the code review / test suite. Oleh