I suppose I should do this to avoid fighting with <linux/types.h> #ifdef DRM_FOURCC_STANDALONE #if defined(__linux__) #include <linux/types.h> #else #include <stdint.h> typedef uint32_t __u32; typedef uint64_t __u64; #endif #else #include "drm.h" #endif
I'll wait for more feedback before updating the patch though. On Fri, Dec 4, 2020 at 1:47 AM James Park <james.p...@lagfreegames.com> wrote: > The typedefs might also conflict on Linux if DRM_FOURCC_STANDALONE is > enabled with whatever LInux declared __u32/__u64 as, but I think the > implication is that once DRM_FOURCC_STANDALONE has been declared, that's > kind of a promise not to include drm.h. > > I'm fine with this, but I'm not married to it if someone has a problem > where they want to define DRM_FOURCC_STANDALONE, but also can't avoid > including drm.h for some reason. > > On Fri, Dec 4, 2020 at 12:53 AM Simon Ser <cont...@emersion.fr> wrote: > >> On Friday, December 4, 2020 5:53 AM, James Park <jpar...@lagfreegames.com> >> wrote: >> >> > +#ifdef DRM_FOURCC_STANDALONE >> > +#include <stdint.h> >> > >> > +typedef uint32_t __u32; >> > +typedef uint64_t __u64; >> > +#else >> > #include "drm.h" >> > +#endif >> >> C11 allows duplicate typedefs, but older versions of the standard >> don't AFAIK. If this is a concern, a solution would be to guard the >> typedefs. >> >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
