From -5963217968266006004 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-13 18:46:44 PST Path: bga.com!news.sprintlink.net!redstone.interpath.net!ddsw1!panix!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!wupost!bigfoot.wustl.edu!ritz.cec.wustl.edu!not-for-mail From: jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) Newsgroups: comp.std.c,comp.std.c++ Subject: Re: malloc calls FROM the standard library (was: Re: Question on 5.2.3.) Date: 13 Sep 1994 11:18:04 -0500 Organization: Washington University, St. Louis MO Lines: 30 Message-ID: <354jbs$54q@ritz.cec.wustl.edu> References: <1994Sep10.033223.23015@nlm.nih.gov> <352ps8$j32@reuter.cse.ogi.edu> Reply-To: sg3235@shelob.sbc.com NNTP-Posting-Host: ritz.cec.wustl.edu Xref: bga.com comp.std.c:2914 comp.std.c++:4250 In article <352ps8$j32@reuter.cse.ogi.edu>, Scott David Daniels wrote: >[Roughly, why cannot a user write a malloc-replacement and still be in-standard] > >Even worse, a user may choose to implement his ``malloc'' by calling ``calloc,'' >blissfully unaware that the run-time implementor has chosen to build ``calloc'' >by calling ``malloc'' for the storage and then clearing it. > >In this case, the C system builder has used the standard interface to malloc, >and the user has provided a result, but none of this actually helps. > >-Scott David Daniels >daniels@cse.ogi.edu However, the victim of both of these situations will find out about it pretty quickly. In the first case, I believe that the linker will find that calloc is undefined and include the object file in the library containing the definition of that symbol. Since that file also contains the definition for malloc, it will have been defined twice...a linker error. In the second case, an infinite loop would result immediately upon the first call of either malloc or calloc. Once the stack blows, any decent debugger could determine the cause. Therefore, the restriction that the library developers only use the standard interfaces would not really be hindered by this problem. I don't particularly mind when things don't work early in the development cycle....it's when they blow up after the customer has it that really causes a problem. Stephen Gevers sg3235@shelob.sbc.com