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: <d93646fa-c844-693c-07a7-7075d0fcf2c9@xilinx.com>
Date:   Wed, 12 Feb 2020 10:42:23 +0100
From:   Michal Simek <michal.simek@...inx.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Michal Simek <michal.simek@...inx.com>
Cc:     Max Filippov <jcmvbkbc@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Michal Simek <monstr@...str.eu>, git@...inx.com,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stefan Asserhall <stefan.asserhall@...inx.com>,
        Chris Zankel <chris@...kel.net>,
        "David S. Miller" <davem@...emloft.net>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Helge Deller <deller@....de>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Matt Turner <mattst88@...il.com>,
        Rich Felker <dalias@...c.org>,
        Richard Henderson <rth@...ddle.net>,
        Tony Luck <tony.luck@...el.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        "open list:ALPHA PORT" <linux-alpha@...r.kernel.org>,
        "open list:IA64 (Itanium) PL..." <linux-ia64@...r.kernel.org>,
        "open list:M68K ARCHITECTURE" <linux-m68k@...ts.linux-m68k.org>,
        "open list:PARISC ARCHITECTURE" <linux-parisc@...r.kernel.org>,
        "open list:SUPERH" <linux-sh@...r.kernel.org>,
        "open list:TENSILICA XTENSA PORT (xtensa)" 
        <linux-xtensa@...ux-xtensa.org>,
        "open list:SPARC + UltraSPAR..." <sparclinux@...r.kernel.org>
Subject: Re: [PATCH v2] asm-generic: Fix unistd_32.h generation format

On 12. 02. 20 10:40, Geert Uytterhoeven wrote:
> Hi Michal,
> 
> On Wed, Feb 12, 2020 at 10:38 AM Michal Simek <michal.simek@...inx.com> wrote:
>> On 12. 02. 20 10:32, Geert Uytterhoeven wrote:
>>> On Wed, Feb 12, 2020 at 10:27 AM Michal Simek <michal.simek@...inx.com> wrote:
>>>> On 12. 02. 20 10:25, Geert Uytterhoeven wrote:
>>>>> On Wed, Feb 12, 2020 at 10:23 AM Max Filippov <jcmvbkbc@...il.com> wrote:
>>>>>> On Wed, Feb 12, 2020 at 1:16 AM Michal Simek <michal.simek@...inx.com> wrote:
>>>>>>>
>>>>>>> Generated files are also checked by sparse that's why add newline
>>>>>>> to remove sparse (C=1) warning.
>>>>>>>
>>>>>>> The issue was found on Microblaze and reported like this:
>>>>>>> ./arch/microblaze/include/generated/uapi/asm/unistd_32.h:438:45:
>>>>>>> warning: no newline at end of file
>>>>>>>
>>>>>>> Signed-off-by: Michal Simek <michal.simek@...inx.com>
>>>>>>> Reviewed-by: Stefan Asserhall <stefan.asserhall@...inx.com>
>>>>>
>>>>>>> --- a/arch/m68k/kernel/syscalls/syscallhdr.sh
>>>>>>> +++ b/arch/m68k/kernel/syscalls/syscallhdr.sh
>>>>>>> @@ -33,4 +33,5 @@ grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
>>>>>>>         printf "#endif\n"
>>>>>>>         printf "\n"
>>>>>>>         printf "#endif /* %s */\n" "${fileguard}"
>>>>>>
>>>>>> Here there's already \n at the end, so no need for another one?
>>>>>
>>>>> Thanks! I completely missed that.
>>>>> So I did fix the original while applying ;-)
>>>>
>>>> I can drop m68k or align with with others. I would prefer to have the
>>>> same solution in all these scripts.
>>>
>>> Yeah, it makes sense to align as much as possible.
>>> IIRC, the original plan was to consolidate more later.
>>>
>>> Note that all other lines are terminated with a "\n" at the end.
>>> The separate 'printf "\n"' is an extra blank line, not the terminator for the
>>> previous line.
>>
>> Should we also get rid of 'printf "\n"' lines or just keep them as they
>> are today?
> 
> Usually there is a blank line above the include guard terminator, so IMHO
> it makes sense to have that in generated files, too.

I meant more not to get rid of \n just include them in current prints.
It means like this 'printf "\n#endif /* %s */\n" "${fileguard}"'

M

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ