From 1901730840551493457 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-07 04:27:31 PST Newsgroups: comp.std.c,comp.std.c++ Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!rutgers!sgigate.sgi.com!sgiblab!pacbell.com!ihnp4.ucsd.edu!swrinde!pipex!hunts.x.co.uk!scone.london.sco.com!clive From: clive@sco.com (Clive D.W. Feather) Subject: Re: malloc calls FROM the standard library (was: Re: Question on 5.2.3.) Organization: Santa Cruz Operation Ltd., Watford, United Kingdom Date: Tue, 6 Sep 1994 13:10:23 GMT Message-ID: References: <1994Sep2.102654.14783@ida.liu.se> Lines: 47 Xref: nntp.gmd.de comp.std.c:7751 comp.std.c++:8857 In article , Ronald F. Guilmette wrote: >>>> The latter rule is particularly important: code using malloc must not >>>> call malloc from within signal handlers. > To heck with user code! What about library code and/or other code (e.g. > startup code) provided by the implementation? > > It's my understanding that nothing provided by the implementation is > supposed to call malloc. (At least that is the rule in ANSI/ISO C, > I believe. I'm less sure about draft standard C++.) In other words, > user's should be able to replace `malloc' which their own routine of > the same name. No, no, no. Firstly, there is no such blanket rule in 7.1, which is where I would expect it to be, and I don't recall any such rule at all. There *is* a rule for certain functions, such as setlocale [7.4.1.1] or the time conversion functions [7.12.3]. This, however, is because these functions modify a static that is visible to the programmer. The name "malloc" is reserved with external linkage under all circumstances. If you define your own malloc(), you have entered the world of undefined behaviour. The reason for this is that library functions *can* call malloc, and different linkers will do different things when two mallocs exist: - use the one in the program [typically when the library malloc is in a separate module that never gets linked in] - refuse to link [typically when the library malloc is in the same module as (say) free, which another module requests] - calls in the program use the one in the program, and calls in the library use the one in the library [typical with some types of shared library] > As it turns out, three out of four popular MS-DOS based C/C++ compilers > either have printf functions or else startup routines that screw up by > calling malloc. Try it yourself and see if you've got one of the bad > ones. Nothing prevents them from doing so. A preliminary reply to a Defect Report states that even va_start can call malloc. -- Clive D.W. Feather | Santa Cruz Operation | If you lie to the compiler, clive@sco.com | Croxley Centre | it will get its revenge. Phone: +44 1923 813541 | Hatters Lane, Watford | - Henry Spencer Fax: +44 1923 813811 | WD1 8YN, United Kingdom | <= NOTE: NEW PHONE NUMBERS