Ronald F. Guilmette (rfg@netcom.com) wrote:
: >I don't know of any rule in the C standard which prohibits any library
: >function from calling malloc.

: You are correct, and I stand corrected.

[Uninformed?] question: If the use of malloc in the library is ... uhm ...
debatable, why wouldn't one simply say "The library must use [e.g.]
__LIB_malloc and __LIB_free which may be set up to call malloc/free by the
implementation but must be replacable"? Wouldn't this be the
straightforward way to avoid any problems?

: -- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------

--
Heinz Wrobel        Edotronik GmbH: heinz@edohwg.adsp.sub.org
                    Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

In article <heinz.0p4g@hwg.muc.de> heinz@hwg.muc.de (Heinz Wrobel   ) writes:
>Ronald F. Guilmette (rfg@netcom.com) wrote:
>: >I don't know of any rule in the C standard which prohibits any library
>: >function from calling malloc.
>
>: You are correct, and I stand corrected.
>
>[Uninformed?] question: If the use of malloc in the library is ... uhm ...
>debatable, why wouldn't one simply say "The library must use [e.g.]
>__LIB_malloc and __LIB_free which may be set up to call malloc/free by the
>implementation but must be replacable"? Wouldn't this be the
>straightforward way to avoid any problems?

In fact, under all implementations of the SVr4 operating system... at least
all the ones that *I'm* aware of... each and every library function can
be replaced by an identically named function in the user's own code, and
providing any such user replacements will have no effect whatever on the
operation of any other library functions because internal calls within
and between library function themselves are always linked to ``hidden''
entry points for the real library functions.  These ``hidden'' entry
points can be thought of as having the same names as their normal counter-
parts, except with a couple of extra leading underscores.  (That's not
really how they are implemented, but that should give you the basic
idea.)  It is almost as if every library function (e.g. `foo') were
really implemented as:

 <return-type> foo (<args>)
 {
  return __foo (<args>);
 }

Also, if (internally, within the library) `__foo' needs  to call `bar'
(like for example __printf needs to call malloc) it is instead written
(by the folks who create SVr4) to call __bar.

This way, any user can have his/her own `bar' function, and it will not
affect the library one wit.

Make sense?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article I3F@netcom.com, rfg@netcom.com (Ronald F. Guilmette) writes:

>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.

I don't know of any rule in the C standard which prohibits any library
function from calling malloc. In fact, some library functions (e.g. in
stdio) are required to do dynamic memory allocation. If you can find a
prohibition against calling malloc, please post it.

Next, malloc (again, in C) is a reserved external identifier and any attempt
to define an external 'malloc' results in undefined behavior.

Of course, many implementations will continue to work properly if you replace
all of malloc/calloc/realloc/free with your own versions which follow the
requirements in the Standard, but you cannot rely on that.

The C++ standard so far follows the C standard in this regard, with some
extra words about overloading.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <34i50u$8nv@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM writes:
>In article I3F@netcom.com, rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>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.
>
>I don't know of any rule in the C standard which prohibits any library
>function from calling malloc.

You are correct, and I stand corrected.

>In fact, some library functions (e.g. in
>stdio) are required to do dynamic memory allocation...

Eh?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -