Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yury Gribov <y.gribov@samsung.com>, Doug Evans <dje@google.com>
Cc: chet.ramey@case.edu, bug-readline@gnu.org,
	       Vyacheslav Barinov <v.barinov@samsung.com>,
	       Yury Usishchev <y.usishchev@samsung.com>,
	       "gdb@sourceware.org" <gdb@sourceware.org>,
	       Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [Bug-readline] [PATCH] Enable visibility annotations
Date: Wed, 20 Apr 2016 10:19:00 -0000	[thread overview]
Message-ID: <5717579B.1020302@redhat.com> (raw)
In-Reply-To: <57174FBC.7080909@samsung.com>

On 04/20/2016 10:45 AM, Yury Gribov wrote:
> On 04/20/2016 12:22 PM, Pedro Alves wrote:

>> - Claim that the symbols may no longer be available in a
>>    future release.
> 
> You mean just email respective package maintainers?

I was thinking readline's CHANGES / release notes.

Emailing respective package maintainers / filing bugs with them
doesn't hurt of course.

> 
>> - Give time for packages to clean themselves up, and propose
>>    any necessary new replacement APIs.
> 
> This would require significant expertise in readline though...

The alternative is bless the private symbols as
public API forever...  Each package owner will know what their
package needs from readline and why they found a need
to (ab)use readline private symbols.  I see no way around that.

> 
>> - Optionally, in the release after the next, mark the symbols
>>    as deprecated with __attribute__((deprecated)), so packages
>>    that abuse private symbols get a build-time warning.
> 
> That won't help as these symbols are not present in headers anyway.  All
> users have their own private declarations.

OK.  Making it a linker warning instead,using ".gnu.warning.SYMBOL"
sections might still work:

 http://www.airs.com/blog/archives/54

Not sure it's a good idea to raise warnings without alternatives
already in place though, thus my "Optionally".

Thanks,
Pedro Alves


  reply	other threads:[~2016-04-20 10:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 18:16 Doug Evans
2016-04-20  6:02 ` Yury Gribov
2016-04-20  9:22   ` Pedro Alves
2016-04-20  9:45     ` Yury Gribov
2016-04-20 10:19       ` Pedro Alves [this message]
2016-04-20 10:55         ` Yury Gribov
2016-04-20 15:30           ` Chet Ramey
2016-04-20 21:16 ` Chet Ramey
2016-04-22 14:43   ` Pedro Alves
2016-04-22 15:25     ` Chet Ramey
     [not found] <570F38DD.1030703@samsung.com>
     [not found] ` <570F3C7E.30005@samsung.com>
     [not found]   ` <570F7554.7070901@redhat.com>
     [not found]     ` <570FB04D.2060107@case.edu>
2016-04-14 15:19       ` 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=5717579B.1020302@redhat.com \
    --to=palves@redhat.com \
    --cc=bug-readline@gnu.org \
    --cc=chet.ramey@case.edu \
    --cc=dje@google.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=v.barinov@samsung.com \
    --cc=y.gribov@samsung.com \
    --cc=y.usishchev@samsung.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