Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

[Juergen Gross <jgross@xxxxxxxx>]

On 02.08.19 10:38, Viktor Mitin wrote:
> On Thu, Aug 1, 2019 at 3:50 PM Juergen Gross <jgross@xxxxxxxx> wrote:
> > On 01.08.19 14:16, Viktor Mitin wrote:
> > > On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > > > On 31.07.2019 18:20, Viktor Mitin wrote:
> > > > > How all those projects live without this issue?
> > > > Perhaps they don't care? I do.
> > > >
> > > > > What is the reason not to fix 'diff -p'? Is it not possible at all?
> > > > I have no idea, but I guess there's a reason for its current
> > > > behavior.
> > > Jan, it seems it is not a good idea to modify the Xen coding style
> > > without investigation of the issue first. It takes some effort to
> > > automate every such (or similar) exceptional code formatting case. So
> > > it looks we could find a better option, than just adding one more
> > > exception to Xen coding style, at least worth to investigate it first.
> > >
> > > > > Could you please share more details about the background of the issue
> > > > > and examples?
> > > > What (further) background and what kind of examples are you after?
> > > I expected you to have some arguments why it cannot be fixed in the
> > > diff or other tools.
> > Changing diff upstream might be possible. Changing today's incarnations
> > in all distros out in the wild is barely doable.
> >
> > Another question is whether we really want diff to be changed. The
> > current behavior is fine for assembly sources for example. A changed
> > diff would no longer present the last label for context.
> >
> > > The examples I meant are any real patches code examples to be used for
> > > this investigation.
> > A snipplet from commit 57f8b13c724023c78fa15a80452d1de3e51a1418:
> >
> > @@ -4096,14 +4097,12 @@ retry_transaction:
> >            goto out;
> >
> >        if (target == NULL) {
> > -        libxl__xs_printf(gc, t, target_path, "%"PRIu32,
> > -                         (uint32_t) info.current_memkb);
> > -        *target_memkb = (uint32_t) info.current_memkb;
> > +        libxl__xs_printf(gc, t, target_path, "%"PRIu64,
> > info.current_memkb);
> > +        *target_memkb = info.current_memkb;
> >        }
> >        if (staticmax == NULL) {
> > -        libxl__xs_printf(gc, t, max_path, "%"PRIu32,
> > -                         (uint32_t) info.max_memkb);
> > -        *max_memkb = (uint32_t) info.max_memkb;
> > +        libxl__xs_printf(gc, t, max_path, "%"PRIu64, info.max_memkb);
> > +        *max_memkb = info.max_memkb;
> >        }
> >
> >        rc = 0;
> I've build gnu diffutils latest release 3.7 and checked the code and
> the issue. It seems this feature (-p) doesn't work properly and has
> many more bugs than just the issue with labels. See the example below,
> the change has been made in the function a1(), however, in the diff
> another function is shown a().
This case is completely fine, as the context of the diff is starting
before the definition of a() (and just after a1()). This is important in
case you only add a new function for example.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel