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:   Tue, 1 May 2018 21:47:23 +0200
From:   Ulf Magnusson <ulfalizer@...il.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson <ulfalizer@...il.com> wrote:
> On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap <rdunlap@...radead.org> wrote:
>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a
>>> terminal menuconfig implementation, implemented in plain curses
>>> (which is in the Python standard library).
>>>
>>> The interface should feel familiar to people used to mconf. It has
>>> some features that mconf lacks:
>>>
>>>   - Seamless resizing
>>>
>>>   - Unicode support
>>>
>>>   - Runs on Windows (via 'pip install windows-curses', which uses
>>>     PDCurses)
>>>
>>>   - Improved information displays:
>>>
>>>     * All expressions are split into readable chunks
>>>
>>>     * Menus and comments have information displays
>>>
>>>   - Relatively easy-to-read and easy-to-tweak code.
>>>
>>>     Kconfiglib automatically invalidates symbols as needed, and
>>>     values can never get stale, which helps.
>>>
>>> Some upcoming features are mouse support and a search feature that
>>> can jump directly to the definition of a symbol. The jump-to feature
>>> will use a "show-all" mode in case the symbol isn't visible.
>>>
>>> See the Kconfiglib GitHub page for screenshots. The menuconfig
>>> implementation is at
>>> https://github.com/ulfalizer/Kconfiglib/blob/master/menuconfig.py.
>>> The docstring at the top has some more information.
>>
>> Hi,
>>
>> I'm probably missing some python additive (I hope it's that easy), but
>> menuconfig.py is not liking the "degree" symbol in drivers/net/can/peak_canfd/Kconfig:
>>
>> config CAN_PEAK_PCIEFD
>>         depends on PCI
>>         tristate "PEAK-System PCAN-PCIe FD cards"
>>         ---help---
>>           This driver adds support for the PEAK-System PCI Express FD
>>           CAN-FD cards family.
>>           These 1x or 2x CAN-FD channels cards offer CAN 2.0 a/b as well as
>>           CAN-FD access to the CAN bus. Besides the nominal bitrate of up to
>>           1 Mbit/s, the data bytes of CAN-FD frames can be transmitted with
>>           up to 12 Mbit/s. A galvanic isolation of the CAN ports protects the
>>           electronics of the card and the respective computer against
>>           disturbances of up to 500 Volts. The PCAN-PCI Express FD can be
>>           operated with ambient temperatures in a range of -40 to +85 °C.
>>
>>
>> kconfiglib.KconfigSyntaxError:
>> Malformed ascii in drivers/net/can/peak_canfd/Kconfig
>> Context: b't temperatures in a range of -40 to +85 \xc2\xb0C.\n'
>> Problematic data: b'\xc2'
>> Reason: ordinal not in range(128)
>>
>>
>> thanks,
>> --
>> ~Randy
>
> Thanks for trying it out!
>
> You're probably running in the C locale, which implies an ASCII
> encoding. That has caused enough trouble that the Python devs decided
> to automatically convert it to UTF-8 in Python 3.7:
> https://www.python.org/dev/peps/pep-0538/. LC_CTYPE=C.UTF-8 should fix
> it.
>
> It's a bit silly to have it crash for something like that though. I
> could force UTF-8 instead of respecting the locale (though it feels
> neater to respect settings), or tell Python to ignore decoding errors.
> Should probably do something at least...
>
> Cheers,
> Ulf

Leaning towards just forcing UTF-8. It's what you want in 99% of
cases, and ignoring decoding errors would be unsafe for Unicode string
values.

Could make the forcing optional, and default to on...

Cheers,
Ulf

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ