From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 28 Sep 2015 15:05:27 +0000 Message-ID: References: <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <55F584E7.7090406@dancol.org> <55F588AE.2010301@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bfcec4aad68170520d0077d X-Trace: ger.gmane.org 1443475669 8328 80.91.229.3 (28 Sep 2015 21:27:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 21:27:49 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 23:27:48 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 1Zgfxc-0008IX-2D for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 23:27:48 +0200 Original-Received: from localhost ([::1]:40975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgfxb-0002Cs-DR for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 17:27:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgZzw-0003nb-18 for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:05:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgZzu-0002VV-Gt for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:05:47 -0400 Original-Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e]:35091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgZzm-0002Fm-Sn; Mon, 28 Sep 2015 11:05:39 -0400 Original-Received: by laer8 with SMTP id r8so34531749lae.2; Mon, 28 Sep 2015 08:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=m+U0BVMmiKIG329EyooSe/+IUyv1SVCdS4zzKPw10Xc=; b=TQvkGU/j10vzDwgjyP2TYXtoISgrGQkH6RumgJ93SUkJwSVOhpAd+vHEcUhFuSJEEh HgzvI34wM4VCMhkWaRfSVJhzAdR60AHRNhfAFTP4apqKAg2RwJ4VxHmK8lAkPEBEusno 9N9PGzDPoQhDE8eijTfW8s6UBeKfoXTtVbV7MhwQa4CESnjiNOLwvwIa6Mcc/p33tF6p eoZobm9vnYzzsw2U7XS70tKF8xs7XxU1mYpVFcWCqSmhEYFWbJJ0J+/tmPNwwh4GfFUj vTcYz+QEyuDBZpG9tZE0rscjGcEXX3hWaRiJTQSEEcXBmEn6YicxrxhTR+EfGP99f3sa xzMg== X-Received: by 10.194.77.77 with SMTP id q13mr25716286wjw.79.1443452737642; Mon, 28 Sep 2015 08:05:37 -0700 (PDT) In-Reply-To: <55F588AE.2010301@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22e 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:190439 Archived-At: --047d7bfcec4aad68170520d0077d Content-Type: text/plain; charset=UTF-8 Daniel Colascione schrieb am So., 13. Sep. 2015 um 16:31 Uhr: > On 09/13/2015 07:27 AM, Philipp Stephani wrote: > > Daniel Colascione > schrieb > > am So., 13. Sep. 2015 um 16:15 Uhr: > > > > On 09/13/2015 06:04 AM, Philipp Stephani wrote: > > > Daniel Colascione > > >> schrieb > > > am So., 15. Feb. 2015 um 21:21 Uhr: > > > > > > typedef struct emacs_value_tag* emacs_value; > > > > > > > > > Would it make sense to not use a typedef here? Using a typedef > means > > > that the type including its size is opaque and subject to change, > > which > > > can break ABI compatibility. I'd rather have something like: > > > > > > struct emacs_value { > > > // contains private fields > > > }; > > > > > > and then pass /struct emacs_value*/ around. > > > > You may have missed the "*" in the typedef. The difference is > stylistic. > > There's no difference between foo and bar here. > > > > typedef struct valuex* value; > > void foo(struct valuex* x); > > void bar(value y); > > > > I find the typedef much more readable, however. > > > > > > There's no difference in your design, but using a typedef makes it > > possible to use a non-pointer type without changing the API in obvious > > ways. > > E.g. Linus is strongly against such > > typedefs: http://lkml.iu.edu/hypermail/linux/kernel/0206.1/0402.html > > Linus is also against integer overflow checking. So what? I can't stand > argumentum ad Linus. > > I still find the typedef more readable, because to users, emacs_value is > an opaque type, and the fact that we implement it as a pointer is > irrelevant. > > Fair enough, this is really just a minor nitpick. I was worried a bit to see it typedef'd to void* and cast to Lisp_Object in the implementation, which decreases type safety a bit and assumes that a Lisp object is always the size of a pointer, but probably that's minor and I worry too much. --047d7bfcec4aad68170520d0077d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am So., 13. Sep. 2015 um 16:31=C2=A0Uhr:
On 09/13/2015 07:27 AM, Philipp Stephani wrote:
> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> am So., 13. Sep. 2015 um 16:15 Uhr:
>
>=C2=A0 =C2=A0 =C2=A0On 09/13/2015 06:04 AM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:dancol@dancol.org <mailto:dancol@dancol.org>>> schrieb
>=C2=A0 =C2=A0 =C2=A0> am So., 15. Feb. 2015 um 21:21 Uhr:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0typedef struct emacs= _value_tag* emacs_value;
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Would it make sense to not use a typedef here?= Using a typedef means
>=C2=A0 =C2=A0 =C2=A0> that the type including its size is opaque and= subject to change,
>=C2=A0 =C2=A0 =C2=A0which
>=C2=A0 =C2=A0 =C2=A0> can break ABI compatibility. I'd rather ha= ve something like:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> struct emacs_value {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0// contains private fields
>=C2=A0 =C2=A0 =C2=A0> };
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> and then pass /struct emacs_value*/ around. >
>=C2=A0 =C2=A0 =C2=A0You may have missed the "*" in the typede= f. The difference is stylistic.
>=C2=A0 =C2=A0 =C2=A0There's no difference between foo and bar here.=
>
>=C2=A0 =C2=A0 =C2=A0typedef struct valuex* value;
>=C2=A0 =C2=A0 =C2=A0void foo(struct valuex* x);
>=C2=A0 =C2=A0 =C2=A0void bar(value y);
>
>=C2=A0 =C2=A0 =C2=A0I find the typedef much more readable, however.
>
>
> There's no difference in your design, but using a typedef makes it=
> possible to use a non-pointer type without changing the API in obvious=
> ways.
> E.g. Linus is strongly against such
> typedefs: http://lkml.iu.edu/hypermai= l/linux/kernel/0206.1/0402.html

Linus is also against integer overflow checking. So what? I can't stand=
argumentum ad Linus.

I still find the typedef more readable, because to users, emacs_value is an opaque type, and the fact that we implement it as a pointer is
irrelevant.


Fair enough, this is really just a min= or nitpick. I was worried a bit to see it typedef'd to void* and cast t= o Lisp_Object in the implementation, which decreases type safety a bit and = assumes that a Lisp object is always the size of a pointer, but probably th= at's minor and I worry too much.=C2=A0
--047d7bfcec4aad68170520d0077d--