From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Joel Brobecker'" <brobecker@adacore.com>
Cc: "'Pedro Alves'" <palves@redhat.com>, <devans@sourceware.org>,
<gdb-patches@sourceware.org>
Subject: RE: PING: [RFA] Fix New ARI warning Tue Nov 6 01:58:48 UTC 2012
Date: Mon, 12 Nov 2012 16:01:00 -0000 [thread overview]
Message-ID: <000601cdc0ee$effc4810$cff4d830$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <20121112155053.GS5103@adacore.com>
> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : lundi 12 novembre 2012 16:51
> À : Pierre Muller
> Cc : 'Pedro Alves'; devans@sourceware.org; gdb-patches@sourceware.org
> Objet : Re: PING: [RFA] Fix New ARI warning Tue Nov 6 01:58:48 UTC 2012
>
> > There is probably a list of other similar functions that we should
> > obsolete.
>
> Can you tell us which functions you have in mind?
It depends if we only consider GDB specific functions
or also functions which are part of some system headers.
For the second category, a possible solution would be to
add or override the function as a macro that would generate an error
at compilation time,
but I am not sure this is easy to do in a way that would
work for all systems...
We could forbid by this scheme
function like bcmp/bcopy, abort,
even forbidden constants as true or false
See the list of 'Fixed' items at the bottom of the ARI web page.
> > 1-- Brutal method:
> > Remove function from both header and C sources
> > as well as from ARI script.
>
> I'd go with this approach.
As long as we reach an agreement on the method...
Pierre
next prev parent reply other threads:[~2012-11-12 16:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 1:59 GDB Administrator
2012-11-06 11:08 ` [RFA] Fix " Pierre Muller
[not found] ` <5098efb2.05fd440a.7696.ffffd821SMTPIN_ADDED@mx.google.com>
2012-11-06 19:02 ` Pedro Alves
2012-11-12 9:17 ` PING: " Pierre Muller
2012-11-12 15:51 ` Joel Brobecker
2012-11-12 16:01 ` Pierre Muller [this message]
2012-11-12 16:28 ` Tom Tromey
[not found] ` <22453.3111825169$1352736109@news.gmane.org>
2012-11-12 16:29 ` Tom Tromey
2012-11-12 17:06 ` Joel Brobecker
[not found] ` <40242.9794231013$1352711862@news.gmane.org>
2012-11-14 16:45 ` Tom Tromey
2012-11-15 8:14 ` Pierre Muller
2012-11-15 8:32 ` Pierre Muller
[not found] ` <50a4a88c.47f0440a.4029.ffff805aSMTPIN_ADDED@mx.google.com>
2012-11-15 11:36 ` Pedro Alves
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='000601cdc0ee$effc4810$cff4d830$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=brobecker@adacore.com \
--cc=devans@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@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