Re: [PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.

[Sebastian Lackner]

On 30.08.2016 21:30, Jacek Caban wrote:
> Signed-off-by: Jacek Caban
>
> dlls/ntoskrnl.exe/ntoskrnl.c | 40 ++++++++--------------------------------
>  1 file changed, 8 insertions(+), 32 deletions(-)

Wouldn't it be better to use a macro similar to LIST_INIT() for that (to allow
later changes of the internal structure)?

[PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.

[Jacek Caban]

On 30.08.2016 22:00, Sebastian Lackner wrote:
> On 30.08.2016 21:30, Jacek Caban wrote:
> > Signed-off-by: Jacek Caban
> >
> > dlls/ntoskrnl.exe/ntoskrnl.c | 40 ++++++++--------------------------------
> >  1 file changed, 8 insertions(+), 32 deletions(-)
>
> Wouldn't it be better to use a macro similar to LIST_INIT() for that (to allow
> later changes of the internal structure)?

I considered that. In case of list, I believe that motivation for the
macro was not about hiding internal structure, but due to non-obvious
initialization (it sets two pointer to point to the same struct). I
believe that this logic does not apply to wine_rb_tree. However, I'm
fine with having the macro.

Thanks,
Jacek

[PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.

[Sebastian Lackner]

On 31.08.2016 14:10, Jacek Caban wrote:
> On 30.08.2016 22:00, Sebastian Lackner wrote:
> > On 30.08.2016 21:30, Jacek Caban wrote:
> > > Signed-off-by: Jacek Caban
> > >
> > > dlls/ntoskrnl.exe/ntoskrnl.c | 40 ++++++++--------------------------------
> > >  1 file changed, 8 insertions(+), 32 deletions(-)
> >
> > Wouldn't it be better to use a macro similar to LIST_INIT() for that (to allow
> > later changes of the internal structure)?
>
> I considered that. In case of list, I believe that motivation for the
> macro was not about hiding internal structure, but due to non-obvious
> initialization (it sets two pointer to point to the same struct). I
> believe that this logic does not apply to wine_rb_tree. However, I'm
> fine with having the macro.
>
> Thanks,
> Jacek

So far both solutions are fine, and currently I also do not see any need
to have non-null struct initializations. I'll leave the final decision up
to Alexandre.

Best regards,
Sebastian