[PATCH] clients/stacking: Silence a compiler warning

[Armin Krezović]

On 15.09.2016 13:14, Eric Engestrom wrote:
> On Sat, Sep 10, 2016 at 10:55:21PM +0200, Armin Krezović wrote:
>> clang doesn't support gnu_print attribute, so just
>> leave it out when clang is used.
>>
>> Signed-off-by: Armin Krezović <krezovic.armin at gmail.com>
>> ---
>>  clients/stacking.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/clients/stacking.c b/clients/stacking.c
>> index 4285a17..dd3d338 100644
>> --- a/clients/stacking.c
>> +++ b/clients/stacking.c
>> @@ -184,7 +184,11 @@ fullscreen_handler(struct window *window, void *data)
>>  
>>  static void
>>  draw_string(cairo_t *cr,
>> +#ifndef __clang__
>>              const char *fmt, ...) __attribute__((format (gnu_printf, 2, 3)));
>> +#else
>> +            const char *fmt, ...);
>> +#endif
> 
> I would recommend avoiding structure elements (like `)` and `;`) in
> #ifdef blocks, as some editors get confused by this.
> 
> I would also recommend avoiding code duplication, by moving the
> __attribute__ to its own line and only #ifdef'ing that line.
> (As a reminder, function attributes can also be added before the
> function or between the return type and the function name, avoiding the
> need for `;` to also be on its own line after the #ifdef).
> 

Thanks for the feedback.

> But in this case, I think replacing `gnu_printf` with `printf` is
> probably the best solution.
> I was unable to find the difference between the two, though. Does anyone
> know why one would want to use the gnu-prefixed version?
> 

Pekka asked the same. I have no idea though ...

> I also don't know which project this patch is for (you might want to run
> `git config format.subjectprefix "PATCH $(basename "$PWD")"` in the root
> of each of your local clones), but it might already have a __printf()-style
> macro [1][2][3][4] to avoid using #ifdef everywhere.
> 
Hmm, I used to do this in the X11 backend first (create an output, then
register the API), but was running into some crashes.

With the coldplug introduced, there isn't any listener at backend loading
time, so no harm is done.

For this backend we could move output creation after api registration, but
note that same thing applies to other backends (drm and wayland hotplug).

I also want to note that I couldn't move drm output creation after api
registration (which needs to be registered after compositor->backend has
been inited), as something was expecting initial output create function
to be ran (I didn't investigate much at that point).

Thanks for the hint about subjectprefix. I'll see about using wayland-util.h
provided macro.

> Cheers,
>   Eric
> 
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler-gcc.h#n119
> [2] https://cgit.freedesktop.org/mesa/mesa/tree/src/util/macros.h#n128
> [3] https://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-util.h#n59
> [4] https://cgit.freedesktop.org/wayland/libinput/tree/src/libinput.h#n36
> 
>>  
>>  static void
>>  draw_string(cairo_t *cr,
>> -- 
>> 2.10.0


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 837 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160917/cc4edc0c/attachment.sig>