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

[Viktor Mitin <viktor.mitin.19@xxxxxxxxx>]

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(). There are more examples when it doesn't
work properly... I would not recommend relying on this feature since
it seems it is not well tested:

 1 c@cn ~/Downloads/diffutils-3.7$ ./src/diff --version
diff (GNU diffutils) 3.7
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

0 c@cn ~/Downloads/diffutils-3.7$ cat ~/w/t.c
int func a()
{
    int a;
    int b;
}

int func a1(ttt, tttt, tttt)
{
    int a1;
}

0 c@cn ~/Downloads/diffutils-3.7$ cat ~/w/t1.c
afdasdfasdf

int func a()
{
    int a;
    int b;
}

int func a1(ttt, tttt, tttt)
{
    int a0;
}

0 c@cn ~/Downloads/diffutils-3.7$ ./src/diff -p ~/w/t.c ~/w/t1.c
*** /home/c/w/t.c       2019-08-02 11:24:42.044376084 +0300
--- /home/c/w/t1.c      2019-08-02 11:22:39.947610893 +0300
***************
*** 1,3 ****
--- 1,5 ----
+ afdasdfasdf
+
  int func a()
  {
      int a;
*************** int func a()
*** 6,11 ****

  int func a1(ttt, tttt, tttt)
  {
!     int a1;
  }

--- 8,13 ----

  int func a1(ttt, tttt, tttt)
  {
!     int a0;
  }



Thanks

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