AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2012.07.29 19:51 "[Tiff] What about hiding not-officially-exported functions?", by Tom Lane
2012.07.30 12:40 "Re: [Tiff] What about hiding not-officially-exported functions?", by Jay Berkenbilt
2012.07.30 23:45 "Re: [Tiff] What about hiding not-officially-exported functions?", by Tom Lane
2012.07.31 01:04 "Re: [Tiff] What about hiding not-officially-exported functions?", by Bob Friesenhahn
2012.07.31 13:54 "Re: [Tiff] What about hiding not-officially-exported functions?", by Edward Lam

2012.07.29 19:51 "[Tiff] What about hiding not-officially-exported functions?", by Tom Lane

When we had the discussion of symbol versioning back in January, I had the idea that part of what was being discussed was deleting all not-officially-exported functions from the library's symbol table, so it would be impossible not just deprecated for client applications to call them. I noticed by accident that this is not in fact what was done: libtiff.map and libtiffxx.map still allow all function names to get through to the finished library. There might be a filter in effect when building on Windows; I'm not sure what the libtiff.def file is used for, but it looks like it might be intended for Windows. Nothing of the sort happens on Linux though.

Is it intentional that we're still letting clients call things like, say, _TIFFsetDoubleArray()? If not, at what point could we consider changing it? It's probably too late for 4.0, at least on distros that have already shipped that. I still have a bit of a window to apply a filter for Red Hat's distribution of 4.0, though.

regards, tom lane