This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/21989] Made regs from comma-separated to dashed range


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]