Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-i.one.com (mx-i.one.com [91.198.169.56])
	by mail6.b-one.net (Postfix) with ESMTP id 9B5698017F7FD
	for <filtered@awaresystems.be>; Sun, 29 Jul 2012 22:19:25 +0200 (CEST)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-i: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.212.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
	by mx-i.one.com (Postfix) with ESMTP id 345A1323DD
	for <filtered@awaresystems.be>; Sun, 29 Jul 2012 20:19:25 +0000 (UTC)
Received: by vbjk17 with SMTP id k17so5160656vbj.21
        for <filtered@awaresystems.be>; Sun, 29 Jul 2012 13:19:24 -0700 (PDT)
Received: by 10.52.100.229 with SMTP id fb5mr7830229vdb.102.1343593164507;
        Sun, 29 Jul 2012 13:19:24 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.58.208.231 with SMTP id mh7csp117162vec;
        Sun, 29 Jul 2012 13:19:24 -0700 (PDT)
Received: by 10.52.21.177 with SMTP id w17mr7723544vde.98.1343593163556;
        Sun, 29 Jul 2012 13:19:23 -0700 (PDT)
Received-SPF: neutral (google.com: 91.198.169.58 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.58;
Received: by 10.220.20.141 with POP3 id f13mf4641841vcb.16;
        Sun, 29 Jul 2012 13:19:23 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail6.b-one.net (Postfix) with ESMTP id 87B448017F7FD
	for <info@awaresystems.be>; Sun, 29 Jul 2012 22:13:48 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-k.one.com (Postfix) with ESMTP id 49B5E2AAFC3
	for <info@awaresystems.be>; Sun, 29 Jul 2012 20:13:48 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 1BD353AD9A0;
	Sun, 29 Jul 2012 15:12:42 -0500 (EST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by lists.maptools.org (Postfix) with ESMTP id D33D73AD9CE
	for <tiff@lists.maptools.org>; Sun, 29 Jul 2012 14:51:32 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6TJpVj5026456
	for <tiff@lists.maptools.org>; Sun, 29 Jul 2012 15:51:31 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tiff@lists.maptools.org
Date: Sun, 29 Jul 2012 15:51:31 -0400
Message-ID: <26455.1343591491@sss.pgh.pa.us>
Subject: [Tiff] What about hiding not-officially-exported functions?
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

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
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
