emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress


From: Philipp Stephani
Subject: Re: Dynamic loading progress
Date: Mon, 28 Sep 2015 15:05:27 +0000



Daniel Colascione <address@hidden> schrieb am So., 13. Sep. 2015 um 16:31 Uhr:
On 09/13/2015 07:27 AM, Philipp Stephani wrote:
> Daniel Colascione <address@hidden <mailto:address@hidden>> schrieb
> am So., 13. Sep. 2015 um 16:15 Uhr:
>
>     On 09/13/2015 06:04 AM, Philipp Stephani wrote:
>     > Daniel Colascione <address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>> 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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]