I suppose I should do this to avoid fighting with <linux/types.h>
#ifdef DRM_FOURCC_STANDALONE
#if defined(__linux__)
#if defined(__linux__)
#include <linux/types.h>
#else
#include <stdint.h>
typedef uint32_t __u32;
typedef uint64_t __u64;
#include <stdint.h>
typedef uint32_t __u32;
typedef uint64_t __u64;
#endif
#else
#include "drm.h"
#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.park@xxxxxxxxxxxxxxxx> 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 <contact@xxxxxxxxxxx> wrote:On Friday, December 4, 2020 5:53 AM, James Park <jpark37@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel