[PATCH] erofs-utils: add missing errors and normalize errors to lower-case

[Igor Eisberg]

On Sat, 29 Jan 2022, 08:13 Gao Xiang, <hsiangkao at linux.alibaba.com> wrote:

> On Sat, Jan 29, 2022 at 01:56:30PM +0800, Gao Xiang wrote:
> > On Sat, Jan 29, 2022 at 07:47:31AM +0200, Igor Eisberg wrote:
> > > Point regarding conclusive messages taken, will revert the relevant
> lines.
> >
> > Thank.
> >
> > > As for the time variable, all I did was to match it to the format as
> in the
> > > case of HAVE_UTIMENSAT, just above it.
> > > Although the variable isn't used further, inlining it is unreadable.
> > >
> >
> > Please don't. Otherwise, complier will complain
> > "mixed declarations and code"
>

Why would it? Declaration of const struct timespec times is inside
#ifdef...#else, while the declaration for const struct utimebuf time is
inside #else...#endif.
The compiler won't complain because after the preprocessor is done, the
compiler only gets one of them, never both. There is no "mixed declarations
and code" thanks to the preprocessor...

>
> > and I don't want to initialize such structures at the beginning of any
> > block.
>

What exactly is "such structures"? I pointed you to an example where you
did just that with struct z_erofs_decompress_req rq variable, I'm just
following your code style, and this one stood out as unusual for your code
style. Please count how many anonymous struct initializations you have
across the whole erofs-utils project. I count only this one, and another in
lib/data.c. Everything else is initialized as named variables.


> Add some word.


I didn't understand that...

Actually, I'd like to add:
> if (!fsckcfg.extract_path)
>         return;
>
> at the beginning of erofsfsck_set_attributes() instead of
> using "if (!ret && fsckcfg.extract_path)" in the caller.
>

OK, but then we will have mixed declarations and code, because then we
won't be at the beginning of the block...


> So the HAVE_UTIMENSAT case needs to be resolved as well.
>
> Btw, I have no idea why it could become unreadable to you, first,
> it would avoid "mixed declarations and code" unless defining them at the
> beginning of blocks,


Again, there is nothing mixed here, because preprocessor.

and I don't like memset(.., 0, ) and set
> independently since memset generally is a library function (unless
> compliers do some built-in tricks) rather than a language feature.
>

Forgive me but I don't remember seeing any mention of memset in the whole
fsck.c file, so I have no idea why you're telling me this.


> Thanks,
> Gao Xiang


> >
> > Thanks,
> > Gao Xiang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20220129/dce05f86/attachment.htm>