From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 18 Jul 2013 17:12:58 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130718151258.GA5201@polynum.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] mallocz in APE Topicbox-Message-UUID: 6c8a95ec-ead8-11e9-9d60-3106f5b1d025 On Thu, Jul 18, 2013 at 03:48:17PM +0100, Steve Simon wrote: > > But because getcallerpc() is not prefexid by an underscore or file scope, > by the "rules" it is poluting the namespace of the APE app. > > Its a minor thing I know but somone put a lot of effort into adding _MALLOCZ() and > all the other internal funcs it seems a pity to not do the same with > setmalloctag() and getcallerpc(). > > its not a major issue, probably OCD on my part. No, you are perfectly right. Having to deal with "porting" a software to various OSes, every namespace pollution comes in the way because one can not rely on one and only one doc: precisely the standard, without having to know the various time dependent idiosynchrazies (the standard says that it is that, and everything else should not be here except with a leading '_' etc.). (I had to add macros for several TeX routines whose names are not conflicting with ANSI C, but happen to conflict with routines added by system X in its libc; and generally, one add a macro definition to rename... before being told that the new name is conflicting with a name added by system Y version a.b.c.d in its libc...; so the "solution" is always a temporary one; with the standard, one could prove being right; without the standard, one can only prove being OK "so far"...) -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C