From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 89C5C389443E; Mon, 18 May 2020 20:04:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 89C5C389443E From: "maennich at android dot com" To: libabigail@sourceware.org Subject: [Bug default/26012] New: abidiff: do not emit qualified name for data members Date: Mon, 18 May 2020 20:04:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: maennich at android dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 20:04:41 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26012 Bug ID: 26012 Summary: abidiff: do not emit qualified name for data members Product: libabigail Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: default Assignee: dodji at redhat dot com Reporter: maennich at android dot com CC: libabigail at sourceware dot org Target Milestone: --- When reporting differences concerning data members of structs/classes, we do not need to report the fully qualified name as the containing block already states the name and fully qualified members repeat that portion of the name only. E.g. we can reduce=20 'struct task_struct at sched.h:635:1' changed: type size hasn't changed 1 data member insertion: 'unsigned int task_struct::in_ubsan', at offset 16704 (in bits) at sched.h:1006:1 there are data member changes: 'void* task_struct::journal_info' offset changed from 16704 to 16768 (in bits) (by +64 bits) 'bio_list* task_struct::bio_list' offset changed from 16768 to 16832 (in bits) (by +64 bits) 'blk_plug* task_struct::plug' offset changed from 16832 to 16896 (in bi= ts) (by +64 bits) 'reclaim_state* task_struct::reclaim_state' offset changed from 16896 to 16960 (in bits) (by +64 bits) 'backing_dev_info* task_struct::backing_dev_info' offset changed from 1= 6960 to 17024 (in bits) (by +64 bits) 'io_context* task_struct::io_context' offset changed from 17024 to 17088 (in bits) (by +64 bits) 'capture_control* task_struct::capture_control' offset changed from 170= 88 to 17152 (in bits) (by +64 bits) 'unsigned long int task_struct::ptrace_message' offset changed from 171= 52 to 17216 (in bits) (by +64 bits) 'kernel_siginfo_t* task_struct::last_siginfo' offset changed from 17216= to 17280 (in bits) (by +64 bits) to 'struct task_struct at sched.h:635:1' changed: type size hasn't changed 1 data member insertion: 'in_ubsan', at offset 16704 (in bits) at sched.h:1006:1 there are data member changes: 'journal_info' offset changed from 16704 to 16768 (in bits) (by +64 bit= s) 'bio_list' offset changed from 16768 to 16832 (in bits) (by +64 bits) 'plug' offset changed from 16832 to 16896 (in bits) (by +64 bits) 'reclaim_state' offset changed from 16896 to 16960 (in bits) (by +64 bi= ts) 'backing_dev_info' offset changed from 16960 to 17024 (in bits) (by +64 bits) 'io_context' offset changed from 17024 to 17088 (in bits) (by +64 bits) 'capture_control' offset changed from 17088 to 17152 (in bits) (by +64 bits) 'ptrace_message' offset changed from 17152 to 17216 (in bits) (by +64 b= its) 'last_siginfo' offset changed from 17216 to 17280 (in bits) (by +64 bit= s) I think this very much applies to C structs as well as to C++ structs/class and maybe more similar language constructs of other languages. In fact, the above is a C example. I think we should use the non-qualified version if we are in a nested block where the rest of the qualified name is already emitted. In the above example, we are in the block of 'task_struct' differences, hence we can strip that part away from task_struct::in_ubsan'. --=20 You are receiving this mail because: You are on the CC list for the bug.=