linux-kernel - Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 6 Dec 2017 12:07:39 +0100
From:   Marcus Wolf <Marcus.Wolf@...rthome-Wolf.de>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Simon Sandström <simon@...anor.nu>,
        gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
        linux@...f-Entwicklungen.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69_enum.h

Sorry, for sending HTML as well - I am writing from my phone...

Yes, you will break something, when renaming.

Since order isn't changed, most probably old programs will still compile with old enum.h.

If we want to move from optionOnOff to bool, we will also break old progs.

Since driver is new (mainline for just something like 2 monthes) and stil under devel, I think we should "risk" it.

Gruß,

Marcus 

> Am 06.12.2017 um 11:44 schrieb Dan Carpenter <dan.carpenter@...cle.com>:
> 
>> On Wed, Dec 06, 2017 at 12:31:31PM +0200, Marcus Wolf wrote:
>> 
>> 
>>> Am 06.12.2017 um 12:23 schrieb Dan Carpenter:
>>> On Wed, Dec 06, 2017 at 11:46:41AM +0200, Marcus Wolf wrote:
>>>>> diff --git a/drivers/staging/pi433/rf69_enum.h b/drivers/staging/pi433/rf69_enum.h
>>>>> index babe597e2ec6..5247e9269de9 100644
>>>>> --- a/drivers/staging/pi433/rf69_enum.h
>>>>> +++ b/drivers/staging/pi433/rf69_enum.h
>>>>> @@ -18,9 +18,9 @@
>>>>>   #ifndef RF69_ENUM_H
>>>>>   #define RF69_ENUM_H
>>>>> -enum optionOnOff {
>>>>> -    optionOff,
>>>>> -    optionOn
>>>>> +enum option_on_off {
>>>>> +    OPTION_OFF,
>>>>> +    OPTION_ON
>>>>>   };
>>>>>   enum mode {
>>>>> 
>>>> 
>>>> Hi Simon,
>>>> 
>>>> nice work.
>>>> 
>>>> Thank you very much for all the style fixes :-)
>>>> 
>>> 
>>> 
>>> Wow...  This was the one patch I thought was going to sink this
>>> patchset...
>> 
>> I don't get that. What do you mean?
>> 
>>> Isn't enum optionOnOff part of the userspace headers?
>>> 
>>> I thought we weren't allowed to change that.
>> 
>> All enums are for user space (or inteded to be used in userspace in future).
>> Didn't introduce enums for internal use.
> 
> So what I'm asking is if we do this change, does it break any userspace
> programs which are used *right now*.  In other words will programs stop
> compiling because we've renamed an enum?
> 
> regards,
> dan carpenter