public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>,
	Manuel Rigger <rigger.manuel@gmail.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	Manuel Rigger <manuel.rigger@jku.at>,
	gcc@gcc.gnu.org, Stefan Marr <s.marr@kent.ac.uk>,
	Bram Adams <bram.adams@polymtl.ca>
Subject: Re: Unused GCC builtins
Date: Sat, 27 Jan 2018 19:11:00 -0000	[thread overview]
Message-ID: <257df89f-3617-c18b-60ad-31095b2bcb83@gmail.com> (raw)
In-Reply-To: <20180124140956.GC2063@tucnak>

On 01/24/2018 07:09 AM, Jakub Jelinek wrote:
> On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote:
>> In a second step, we also considered internal builtins and found that the
>> vararg handling builtins (__builtin_va_start, __builtin_va_end,
>> __builtin_va_arg, and __builtin_va_copy) are relied upon by many projects,
>> even though they are undocumented in GCC's builtins API. Could they be
>> added to the documentation?
>
> Why?  What is documented is va_start/va_end/va_arg/va_copy, that is
> what people should use, the builtins are just internal implementation of
> those macros.

There are a number of reasons why documenting visible APIs is
helpful whether or not they are meant to be used by end users.

Features that are not meant to be used should be documented
as such.  Mentioning that they are meant only for internal use
makes their purpose clear and sets the right expectation about
the level of support and portability between GCC versions.  It
also makes it clear that we didn't forget to document them by
accident.

The manual isn't just a reference for GCC users.  It's also
a helpful reference for developers of GCC-compatible compilers
who are not allowed to read GCC source code due to copyright or
licensing constraints, or for people maintaining or supporting
their own GCC-based operating environments.  Finally, it is also
a reference for GCC developers.

For all these reasons I think every built-in that can be used
(intentionally or otherwise) deserves to be documented in
the manual.

Martin

      parent reply	other threads:[~2018-01-27 19:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 15:47 Manuel Rigger
2018-01-22 15:55 ` David Brown
2018-01-22 16:02   ` Joel Sherrill
2018-01-22 16:07   ` Jakub Jelinek
2018-01-22 16:10   ` Andrew Pinski
2018-01-22 18:30 ` Florian Weimer
2018-01-24 14:05   ` Manuel Rigger
2018-01-24 14:10     ` Jakub Jelinek
2018-01-24 18:15       ` Florian Weimer
2018-01-27 19:11       ` Martin Sebor [this message]

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=257df89f-3617-c18b-60ad-31095b2bcb83@gmail.com \
    --to=msebor@gmail.com \
    --cc=bram.adams@polymtl.ca \
    --cc=fw@deneb.enyo.de \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=manuel.rigger@jku.at \
    --cc=rigger.manuel@gmail.com \
    --cc=s.marr@kent.ac.uk \
    /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).