public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: dje@google.com, gdb-patches@sourceware.org,
	brobecker@adacore.com, ken@linux.vnet.ibm.com, tromey@redhat.com,
	pedro@codesourcery.com
Subject: Re: [doc RFA] Switch to GCC coding style [Re: [patch] initial OpenCL C language support]
Date: Tue, 02 Nov 2010 19:21:00 -0000	[thread overview]
Message-ID: <8339rj5y7z.fsf@gnu.org> (raw)
In-Reply-To: <20101102172246.GA22137@host0.dyn.jankratochvil.net>

> Date: Tue, 2 Nov 2010 18:22:46 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>,        Ken Werner <ken@linux.vnet.ibm.com>, Tom Tromey <tromey@redhat.com>,        Pedro Alves <pedro@codesourcery.com>
> 
> On Tue, 02 Nov 2010 18:04:39 +0100, Doug Evans wrote:
> > There are lots of things on the gcc codingconventions page that need
> > to be converted (e.g., gcc_assert),
> 
> Done.
> 
> > or revised (e.g., prototypes for _initialize_foo fns can appear in .c files
> > (and should *only* appear in .c files)).
> 
> I do not see a current GDB doc problem with this (+it may be offtopic for this
> patch).
> 
> 
> Thanks,
> Jan

Are you submitting this for doc review, or will we discuss the issue
first?  Or maybe the issue is already decided?  Please help me out
here.

> -@value{GDBN} follows the GNU coding standards, as described in
> -@file{etc/standards.texi}.  This file is also available for anonymous
> -FTP from GNU archive sites.  @value{GDBN} takes a strict interpretation
> -of the standard; in general, when the GNU standard recommends a practice
> -but does not require it, @value{GDBN} requires it.
> +@value{GDBN} follows the GCC Coding Conventions, available from
> +@url{http://gcc.gnu.org/codingconventions.html}.  @value{GDBN} takes a strict
> +interpretation of the standard; in general, when the GCC conventions recommend
> +a practice but do not require it, @value{GDBN} requires it.

The old text talked about "GNU coding _standards_", so it was
understandable when it later mentioned "interpretation of the
standard".  But you replaced "standards" with "Conventions", so now
"interpretation of the standard" begs the question: "what standard?".

Also, this is actually the first violation in GDB history of the GCC
Conventions, which request to use @uref, not @url for references to
Web pages. ;-)

> -The standard GNU recommendations for formatting must be followed
> +The standard GCC recommendations for formatting must be followed
>  strictly.

There are no "recommendations for formatting" that I could spot in the
GCC Conventions.  At least they are not called that.

> -The standard GNU requirements on comments must be followed strictly.
> +The standard GCC requirements on comments must be followed strictly.

I see no requirements on comments in the GCC Conventions.  But even if
I missed something, why single out only this part?

> +@code{gcc_assert} references in GCC Coding Conventions should be replaced by
> +@code{gdb_assert}.  @code{gcc_unreachable} should be replaced by
> +@code{gdb_assert_not_reached}.  Standard @code{<ctype.h>} header file and its
> +functions can and should be used.

I don't think this is enough, sorry.  The GCC Conventions mention a
lot of details that are utterly inapplicable to GDB.  The exceptions
you mention are just a drop in that sea.  What about references to
ERROR_MARK, RTL, --param arguments, what about fastjar and boehm-gc?
And those are just a few random examples.

On balance, I think we should simply have our own coherent document.
It can copy verbatim all the stuff that is relevant to GDB, but it
should include the above renames, and it should omit everything that
is irrelevant.  Any other way, we will just confuse potential
contributors: it is perhaps easy for us old-timers to distinguish
between the relevant and the rest, but for a newbie contributor it
could be an impossible requirement.  To say nothing of the fact that
they will now have to read two documents instead of 1.

Thanks.

  parent reply	other threads:[~2010-11-02 19:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 17:21 [patch] initial OpenCL C language support Ken Werner
2010-10-25 22:41 ` Tom Tromey
2010-10-26 13:05   ` Ken Werner
2010-10-26 13:44     ` Tom Tromey
2010-10-26 16:02       ` Ken Werner
2010-10-26 17:49         ` Eli Zaretskii
2010-10-26 19:58         ` Joel Brobecker
2010-10-26 20:03           ` Joel Brobecker
2010-10-27 13:36             ` Ken Werner
2010-11-02 19:23               ` Joel Brobecker
2010-11-03 13:03                 ` Ken Werner
2010-11-03 15:27                   ` Joel Brobecker
2010-11-04 15:39                     ` Ken Werner
2010-11-04 17:48                       ` Eli Zaretskii
2010-11-05 14:21                         ` Ken Werner
2010-11-05 14:39                     ` Ken Werner
2010-10-27 19:04           ` Jan Kratochvil
2010-10-27 19:21             ` Pedro Alves
2010-10-27 21:01               ` Ken Werner
2010-11-02 16:52               ` [doc RFA] Switch to GCC coding style [Re: [patch] initial OpenCL C language support] Jan Kratochvil
2010-11-02 17:04                 ` Doug Evans
2010-11-02 17:23                   ` Jan Kratochvil
2010-11-02 17:29                     ` Doug Evans
2010-11-02 19:21                     ` Eli Zaretskii [this message]
2010-11-02 19:29                       ` Joel Brobecker
2010-11-08 12:50                       ` Jan Kratochvil
2010-11-08 16:11                         ` Joel Brobecker
2010-11-08 16:38                           ` Mark Kettenis
2010-11-08 16:43                             ` Joel Brobecker
2010-11-08 16:54                             ` Pedro Alves
2010-11-08 18:36                               ` Joel Brobecker
2010-11-02 18:01                   ` Joel Brobecker
2010-11-02 18:10                     ` [doc RFA] Switch to GCC coding style Jan Kratochvil
2010-11-02 18:20                       ` Doug Evans
2010-11-02 18:58                         ` Joel Brobecker
2010-11-02 19:19                           ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8339rj5y7z.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=ken@linux.vnet.ibm.com \
    --cc=pedro@codesourcery.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).