This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Run indent on sysdeps/ieee754/dbl64/*.c ?
- From: Carlos O'Donell <carlos at systemhalted dot org>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 28 Jan 2013 13:50:27 -0500
- Subject: Re: [RFC] Run indent on sysdeps/ieee754/dbl64/*.c ?
- References: <20121228151723.GI25030@spoyarek.pnq.redhat.com>
On 12/28/2012 10:17 AM, Siddhesh Poyarekar wrote:
> Hi,
>
> I had posted a patch in the past with malloc/arena.c run through the
> indent program to get it into the GNU coding style. It was rejected
> because we have a policy of sticking to the original coding style. I
> wanted to know if an exception could be made for the libm code,
> specifically the stuff in dbl-64. The coding 'style' in this part is
> quite horrible and often hard to read, so a clean up would be really a
> big step forward IMO. If there is consensus, I'll start posting
> patches for review on Monday.
My personal opinion is that *all* the code should follow the GNU coding
style unless there is a *very* strong reason not to.
I think that the exception to malloc/arena.c et. al. should be lifted
and it should all be formatted in GNU style.
If we are ever going to go upstream to get a new malloc or an alternative
malloc, such an effort should start with the design of a framework that
would allow us to add/remove replacement mallocs (the same could be said
of libm on a function-by-function basis).
My conservative litmus test for *not* reformating code is:
-> Did you merge in new source from upstream in the last 5 years?
-> No? Reformat.
-> Yes! Don't reformat.
Cheers,
Carlos.