NetBSD Problem Report #8004

Received: (qmail 2031 invoked from network); 15 Jul 1999 17:04:45 -0000
Message-Id: <199907151704.NAA10248@rekusant.rivage.tjls.com>
Date: Thu, 15 Jul 1999 13:04:42 -0400 (EDT)
From: tls@rek.tjls.com
Reply-To: tls@rek.tjls.com
To: gnats-bugs@gnats.netbsd.org
Subject: namespace pollution (type "free_func") in zlib.h
X-Send-Pr-Version: 3.95

>Number:         8004
>Category:       lib
>Synopsis:       zlib.h typedefs "free_func" and "alloc_func", which are not uncommon names in user-supplied code, e.g. OpenSSL
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 15 10:05:01 +0000 1999
>Closed-Date:    
>Last-Modified:  
>Originator:     Thor Lancelot Simon
>Release:        19990710
>Organization:
	damned little
>Environment:
System: NetBSD rekusant.rivage.tjls.com 1.4F NetBSD 1.4F (REKUSANT) #5: Wed Jul 14 05:20:43 EDT 1999 root@rekusant.rivage.tjls.com:/lfs/kobj/REKUSANT i386

>Description:
	zlib.h typedefs "free_func" and "alloc_func".  These names are _way_
	too commonplace and nonspecific to be defined in a public header file.
	The expected chaos ensues, e.g. if one has software with a variable
	named free_func...
>How-To-Repeat:
	Try to build a C source file that includes zlib.h and openssl/rsa.h
>Fix:
	It's not clear to me whether or not we can safely make free_func and
	alloc_func disappear in our zlib API.

>Release-Note:
>Audit-Trail:
>Unformatted:

Home	PR Database Search