Re: [PATCH] Enable visibility annotations
Yury Gribov <[email protected]>
| Newsgroups | gmane.comp.gnu.readline,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 04/20/2016 01:19 PM, Pedro Alves wrote: > 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. Guess that's what's going to happen (unless some motivated readline maintainer steps in, willing to work with various users on getting rid of leaked symbols). >>> - 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 Oh my, this is such a cool feature. I was actually thinking about a "Deprecated" attribute for ELF symbols which static/runtime linker could use to bark. Pushing such thing to Binutils and GCC would take ages though... > Not sure it's a good idea to raise warnings without alternatives > already in place though, thus my "Optionally". > > Thanks, > Pedro Alves > > >