On Fri, Aug 19, 2016 at 6:32 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
I believe that this patch is to simplify porting requirements by reducing system
specific data types whenever possible. The C99 capable data types defined in
stdbool.h, stdint.h and inttypes.h are supported by modern compilers. This
means that anyone who uses gcc, clang, and Visual Studio 2013 ( or newer )
can compile these include files without any major hassles.
tbh, I'm all in favor of making it easier to sync kernel headers to libdrm, etc.
But kernel *does* have stdint types. Just (for some reason that
completely baffles me) not in stdint.h so we can't include that from
the uapi headers themselves. I'm not a huge fan of the uX/sX types
when the rest of the world has moved on to stdint. I can *kinda*
(barely) understand the argument for kernel using uX/sX in uapi (to
avoid other userspace src files from needing to #include stdint.h
first). But I think that is a bad argument (kernel should fix it's
shit to be compatible with stdint.h, not other way around), and it
doesn't even apply for drm uapi (where the consumer of the uapi is
just libdrm_$drivername, not random other consumers) so we can take
care to #include stdint.h first..
tl;dr: I wasn't a big fan of the conversion to uX/sX types.. I kinda
see the argument in the general case (but I think it is bogus, and
even if it was legit it doesn't apply to drm uapi)
</rant>
BR,
-R
specific data types whenever possible. The C99 capable data types defined in
stdbool.h, stdint.h and inttypes.h are supported by modern compilers. This
means that anyone who uses gcc, clang, and Visual Studio 2013 ( or newer )
can compile these include files without any major hassles.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel