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.