Re: Clean up and fix glyph contour generation nits. (issue 566080043 by address@hidden)

[jonas . hahnfeld]

On 2020/05/10 09:29:48, hanwenn wrote:
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
> File lily/freetype.cc (right):
> 
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
> lily/freetype.cc:143: };
> On 2020/05/10 09:16:58, hahnjo wrote:
> > Not sure if FT developers plan to change this interface at some
point. In
> other
> > projects, I have seen something akin to
> > FT_Outline_Funcs funcs;
> > memset(&funcs, 0, sizeof(funcs));
> > for external structs from dependencies to make sure no field goes
> uninitialized.
> 
> the C99 standard actually says that omitted fields are
zero-initialized
> 
> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
> 
> I added the field because GCC warns about it (I don't understand why)

It could be that this is because of C++ officially inheriting from C89
IIRC?
https://en.cppreference.com/w/cpp/language/aggregate_initialization
says:
"If the number of initializer clauses is less than the number of members
[...] the remaining members [...] are [...] copy-initialized from empty
lists, in accordance with the usual list-initialization rules (which
performs value-initialization for non-class types [...])"
which I would read as "uninitialized".

>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode149
> lily/freetype.cc:149: return ((Path_interpreter *) user)->moveto
(*to);
> On 2020/05/10 09:16:59, hahnjo wrote:
> > Do you want to create copies of the arguments? (here and for the
other
> > functions)
> 
> yes. I find it easier to reason about and read. It's all inlined
anyway.

const refs should work the same AFAICS

https://codereview.appspot.com/566080043/