[PATCH wayland 2/3] server: move include directives before extern "C" wrapper

[Emil Velikov]

On 19 April 2016 at 09:51, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 18 Apr 2016 08:16:37 +0200
> Hardening <rdp.effort at gmail.com> wrote:
>
>> Le 17/04/2016 13:29, Emil Velikov a écrit :
>> > Analogous to previous commit but for the server(-core) header.
>> >
>> > Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>> > ---
>> >  src/wayland-server-core.h | 8 ++++----
>> >  1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
>> > index e8e1e9c..fa7f394 100644
>> > --- a/src/wayland-server-core.h
>> > +++ b/src/wayland-server-core.h
>> > @@ -26,15 +26,15 @@
>> >  #ifndef WAYLAND_SERVER_CORE_H
>> >  #define WAYLAND_SERVER_CORE_H
>> >
>> > -#ifdef  __cplusplus
>> > -extern "C" {
>> > -#endif
>> > -
>> >  #include <sys/types.h>
>> >  #include <stdint.h>
>> >  #include "wayland-util.h"
>> >  #include "wayland-version.h"
>> >
>> > +#ifdef  __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> >  enum {
>> >     WL_EVENT_READABLE = 0x01,
>> >     WL_EVENT_WRITABLE = 0x02,
>> >
>>
>> Shouldn't the extern declaration be moved to surround only the functions
>> declarations (and so not including type defines) ?
>> That's just a question, if a C++ specialist have an answer...
>
I'm fairly sure that structs and enums differ between C and C++.
Whereas for forward ("dummy") typedefs and macros - they could be the
same... not sure.

In general it's always better to throw the extern "C" guard/wrapper
just after your includes, as otherwise someone can 'miss it' and add a
few function declarations/others before it.

> That I am not quite sure if it has any effect. If it does have an
> effect, then the C interpretation would be the correct one.
>
> The important thing is to never include system headers from under
> extern "C", which is what I inferred from
> http://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/
> too (thanks, jadahl).
>
Precisely. And as we cannot guarantee that other headers (in general
of course) won't include system headers themselves, one could/should
treat them all the same. To be on the safe side ;-)

> All three pushed:
>    ae78dcb..2c8da32  master -> master
>

Thanks !
Emil