linux-kernel - Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 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]

Message-ID: <BLUPR02MB16838BBEFFAA2240A879370E81ED0@BLUPR02MB1683.namprd02.prod.outlook.com>
Date:   Thu, 25 Aug 2016 04:24:11 +0000
From:   Bart Van Assche <Bart.VanAssche@...disk.com>
To:     Mikko Rapeli <mikko.rapeli@....fi>
CC:     "dm-devel@...hat.com" <dm-devel@...hat.com>,
        Alasdair Kergon <agk@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mike Snitzer <snitzer@...hat.com>
Subject: Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32
 and __u64 from linux/types.h

On 08/23/16 13:42, Mikko Rapeli wrote:
> On Tue, Aug 23, 2016 at 02:28:19PM +0000, Bart Van Assche wrote:
>> On 08/23/16 06:57, Bart Van Assche wrote:
>>> On 08/22/16 11:32, Mikko Rapeli wrote:
>>>> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
>>>> + * __u32 (*get_region_size)(struct dm_dirty_log *log);
>>>
>>> uint32_t is a type that is defined by ANSI C but __u32 not. So this
>>> change looks wrong to me. Would it have been sufficient to add "#include
>>> <linux/types.h>" and keep the uint32_t etc. type names?
>>
>> Answering my own question: adding "#include <linux/types.h>" wouldn't be
>> sufficient. How about adding the following code that also occurs in a
>> few other uapi header files?
>>
>> #ifndef __KERNEL__
>> #include <stdint.h>
>> #endif
>> #include <linux/types.h>
>
> I have tried that before but I was instructed to use the linux/types.h
> versions. For example https://lkml.org/lkml/2015/6/1/160
>
> But lately drm and fuse and some others have questioned this approach and
> would like to use/continue using C99 stdint.h types.

Hello Mikko,

Thanks for the feedback. I have a minor comment though about your patch: 
are you aware that you have changed uint64_t into __u64 in source code 
comments but that int64_t has not been changed into __s64?

Bart.