Re: [PATCH v2] asm-generic: Fix unistd_32.h generation format

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Michal,

On Wed, Feb 12, 2020 at 10:42 AM Michal Simek <michal.simek@xilinx.com> wrote:
> On 12. 02. 20 10:40, Geert Uytterhoeven wrote:
> > On Wed, Feb 12, 2020 at 10:38 AM Michal Simek <michal.simek@xilinx.com> wrote:
> >> On 12. 02. 20 10:32, Geert Uytterhoeven wrote:
> >>> On Wed, Feb 12, 2020 at 10:27 AM Michal Simek <michal.simek@xilinx.com> wrote:
> >>>> On 12. 02. 20 10:25, Geert Uytterhoeven wrote:
> >>>>> On Wed, Feb 12, 2020 at 10:23 AM Max Filippov <jcmvbkbc@gmail.com> wrote:
> >>>>>> On Wed, Feb 12, 2020 at 1:16 AM Michal Simek <michal.simek@xilinx.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@xilinx.com>
> >>>>>>> Reviewed-by: Stefan Asserhall <stefan.asserhall@xilinx.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}"'

I think having a "\n" at the start of a string makes the code harder to read.

You could move it to the end of the previous string, but that is not always
possible (e.g. after the loop), so I'd keep the separate prints for blank
lines.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds