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.