On Tue, 28 Aug 2018, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
