linux-kernel - Re: [RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2016 16:05:21 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Rob Clark <robdclark@...il.com>,
        Mikko Rapeli <mikko.rapeli@....fi>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI
 (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and
 __u64 from <linux/types.h>")

On 22 August 2016 at 15:38, Daniel Vetter <daniel@...ll.ch> wrote:
> On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark <robdclark@...il.com> wrote:
>>> That said, _note_ that some applications are built with -C89 -pedantic
>>> [1] which means that using stdint.h may or may not work as expected.
>>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
>>> If the affected programs are proprietary ones we should be safe,
>>> otherwise we want to update them ~alongside the transition.
>>
>> naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
>> -C89.. problem solved!
>
> Yeah, I think sprinkling an
>
> #ifdef __kernel___
> #include <linux/types.h>
> #else
> #include <stdtypes.h>
> #endif
>
Guess i was too vague :-]

I was thinking about the following cases:
 - using old/incomplete stdint.h - thus the __STDC_VESION__ check.
 - building non-libdrm software - for libdrm we've (implicitly and
explicitly) required C99 for a long time.

> at the opt of all drm uapi headers should be good enough. Or at least
> those which opt to choose stdints. Since our userspace is very
> limited, and our headers will never leak to general applications we
> can just require c99, at least for driver headers. For kms/general drm
> uapi that might not be the best idea.
Won't doing so bring more confusion to an already convoluted topic ?
If we opt for it, let's have a juicy comment that clarifies things.

-Emil