[Intel-gfx] [PATCH 2/2] drm/i915: reword documentation of possible pci_device_id struct
Jani Nikula
jani.nikula at linux.intel.com
Tue Sep 4 13:24:02 UTC 2018
On Tue, 28 Aug 2018, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
> On Tue, Aug 28, 2018 at 07:05:46PM +0100, Chris Wilson wrote:
>> Quoting Lucas De Marchi (2018-08-28 18:41:46)
>> > Document it like a real struct for ease of copy and paste, remove
>> > comment of C99 compatibility and document that in some cases the first 2
>>
>> I do recall that we couldn't use either C99 or class due to userspace
>
> you can't actually use a c++ compiler.
>
> For C it works with any of -std=c99, gnu99, c11, gnu11, c17, gnu17.
> Tested with both gcc and clang. I've never heard of class being a
> reserved keyword and section 6.4.5 of said standard doesn't list it
> neither.
>
> Here the struct definition is in a *comment*... i.e. the user will copy
> and paste somewhere else and probably change __u16 to uint16_t in
> userspace. If he's building with g++, he can name the field to something
> else.
>
> If it was something we were defining in this header than I would agree
> with you... to retain compatibility with c++, not c99.
I always thought the comment told you not to use designated initializers
(introduced in C99), which would both impose a minimum C version
requirement as well as bring .class = foo in the code, which requires
more than just renaming the field with C++.
BR,
Jani.
>
> Lucas De Marchi
>
>> compatibility... The essence is that we need a reminder that we can't
>> assume the relaxed nature of kcc here.
>> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
More information about the Intel-gfx
mailing list