From 5682003866631553991 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1149ec,f5b50f79e3b33c8d X-Google-Attributes: gid1149ec,public X-Google-Thread: f78e5,c0143c56db298752 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-09-10 05:57:11 PST Newsgroups: comp.std.c,comp.std.c++ Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!pipex!warwick!uknet!festival!edcogsci!richard From: richard@cogsci.ed.ac.uk (Richard Tobin) Subject: Re: malloc calls FROM the standard library (was: Re: Question on 5.2.3.) Message-ID: Organization: HCRC, University of Edinburgh References: Date: Fri, 9 Sep 1994 16:04:31 GMT Lines: 25 Xref: nntp.gmd.de comp.std.c:7846 comp.std.c++:8917 In article michaelc@lna.logica.com writes: > rfg> It's my understanding that nothing provided by the implementation is > rfg> supposed to call malloc. This has already been corrected. >What would be the point of such a restriction? If a library were to call >`malloc' directly, why would that preclude someone from replacing `malloc' >with their own implementation? The problem arises if library functions make use of undocumented features of the malloc implementation, which the users will not be able to replicate. It would be useful if implementations guaranteed that this was not the case; i.e. guaranteed that library functions only interact with each other through the standard interfaces. It's probably too restrictive for the C standard to guaranteed this. -- Richard -- Richard Tobin, HCRC, Edinburgh University R.Tobin@ed.ac.uk Ooooh! I didn't know we had a king. I thought we were an autonomous collective.