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:
> 
>     On 09/13/2015 06:04 AM, Philipp Stephani wrote:
>     > Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>
>     <mailto:dancol@dancol.org <mailto:dancol@dancol.org>>> 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.