This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/21989] Made regs from comma-separated to dashed range
- From: "akhilesh.k at samsung dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 24 Aug 2017 07:39:59 +0000
- Subject: [Bug libc/21989] Made regs from comma-separated to dashed range
- Auto-submitted: auto-generated
- References: <bug-21989-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21989
Akhilesh Kumar <akhilesh.k at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph at codesourcery dot com
--- Comment #2 from Akhilesh Kumar <akhilesh.k at samsung dot com> ---
> The <regs> can be a comma-separated list, or a dashed range, or a
> > mixture.
>
> The fact that there are two different ways of writing some code is not a
> justification for changing from one to the other. You need to explain
> why your change is an improvement. For example, is there some external
> coding standard for ARM assembly code that you wish to propose glibc
> follows, which recommends one alternative over the other in this case?
My changes make code more readable I believe in case of comma-separated coding
mistake is possible (same happened with me also in past)
> And, given that there are many uses of both syntaxes in glibc, not just in
> those two files, are you proposing to change all such uses to the
> preferred syntax if we reach consensus on the preferred syntax?
I found only two files where comma-separated is used.
also in glibc most of the places almost all dashed range is used
Example
sysdeps/arm/dl-trampoline.S
sysdeps/unix/sysv/linux/arm/setcontext.S
> In such a case, where it's necessary first to reach consensus on the
> preferred option before making things consistent, and there is no
> user-visible bug, I don't think filing bugs in Bugzilla is appropriate.
> Rather, you should start with an analysis of the issue and a recommended
> approach, seeking a discussion leading to consensus.
> You also need to describe how a patch was tested (e.g. by verifying that
> binaries of glibc built before and after the patch were identical). And
> note the standard syntax for ChangeLog entries, as used in existing
> examples.
I agree no change in size also I did
basic verification with fwrite function I believe this code with hit when we
do fwrite also code is bit more readable
Before build
Toolchain_script$ ls -l build-glibc/libc.so
-rwxr-xr-x 1 akhilesh.k 13827168 Aug 24 10:19 build-glibc/libc.so
After build
Toolchain_script$ ls -l build-glibc/libc.so
-rwxr-xr-x 1 akhilesh.k 13827168 Aug 24 10:28 build-glibc/libc.so
--
You are receiving this mail because:
You are on the CC list for the bug.