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

Powered by blists - more mailing lists