In article <Cw3yn9.Inx@scone.london.sco.com> clive@sco.com (Clive D.W. Feather) writes:
|However, the Standard cannot rely on this, hence its wording.
|
|Another case is that of monolithic shared libraries. Some implementations
|of shared libraries link the whole library into one block, resolving all
|internal references. So if a library function refers to "malloc", it will
|get the one in the library, no matter whether or not there is a user
|function called "malloc". This arrangement also conforms to the Standard.

The C standard permits an implementation to do lots of things.
However, that doesn't mean that doing such things is a good idea.

Resolving malloc calls within the standard library is generally a bad
idea, since most user-supplied replacements of malloc will not work in
the presence of the original, system-supplied version of malloc.

    Thomas.

In article <354jbs$54q@ritz.cec.wustl.edu>,
John Andrew Fingerhut <sg3235@shelob.sbc.com> wrote:
> However, the victim of both of these situations will find out about it
> pretty quickly.

However, the Standard cannot rely on this, hence its wording.

Another case is that of monolithic shared libraries. Some implementations
of shared libraries link the whole library into one block, resolving all
internal references. So if a library function refers to "malloc", it will
get the one in the library, no matter whether or not there is a user
function called "malloc". This arrangement also conforms to the Standard.

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

jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) writes:

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

... or when things work fine until you try to port the program
(e.g. to the next version of the operating system.)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

[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

In article <352ps8$j32@reuter.cse.ogi.edu>,
Scott David Daniels <daniels@cse.ogi.edu> 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

>>>>> "rfg" == Ronald F Guilmette <rfg@netcom.com> writes:

    rfg> In article <CvIH4L.8G2@crdnns.crd.ge.com> volpe@ausable.crd.ge.com writes:

    rfg> It's my understanding that nothing provided by the implementation is
    rfg> supposed to call malloc.  (At least that is the rule in ANSI/ISO C,
    rfg> I believe.  I'm less sure about draft standard C++.)  In other words,
    rfg> user's should be able to replace `malloc' which their own routine of
    rfg> the same name.

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?

Michael.

In article <MCOOK.94Sep9104817@galaga.lna.logica.com> 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.

Richard Tobin (richard@cogsci.ed.ac.uk) wrote:
> In article <MCOOK.94Sep9104817@galaga.lna.logica.com> 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.

Even with that restriction, there would be a problem.  The standard does not
require that functions be packaged separately.  It is quite possible that
the runtime library packages other functions in with malloc and cannot
link them separately.  For example, if malloc() and calloc() were in the same
module and function level linking were not supported, replacing malloc()
would lose calloc().

--
Mike Rubenstein

In article <CvIH4L.8G2@crdnns.crd.ge.com> volpe@ausable.crd.ge.com writes:
>In article <1994Sep2.102654.14783@ida.liu.se>, tompa@ida.liu.se (Thomas Padron-McCarthy) writes:
>>
>>In a review of Herbert Schildt's "The Annotated C Standard",
>>written by C.D.W. Feather,
>>he says this specifically about Schildt's annotation of 5.2.3:
>[...]
>
>>> 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.

Recently, I had occasion to try to see if the (POSIX) `getcwd' implementa-
tion provided by various C/C++ compilers ever called malloc.  (The one
provided by SunPro seems to do so for some reason, but none of the four
DOS-based compilers I tried did so.)  Anyway, I initially was getting some
really strange results from my little test program, so I hacked on it
until it the results made more sense.  (The test program is given below.)

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.

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


cut here for test program
---------------------------------------------------------------------------
/* Copyright (c) 1994 Ronald F. Guilmette; All rights reserved.  */

#include <stdio.h>

static char malloc_buffer[16383];
static char *malloc_p = malloc_buffer;
static unsigned malloc_calls = 0;

union U { char c; short s; int i; long l;
          float f; double d; long double ld;
          void *p; };

struct S { char ch; union U u; } obj;

static unsigned align;

#define roundup(n) (((n + align - 1) / align) * align)

void *
malloc (size_t size)
{
  register void *ret_val = malloc_p;

  /* Must do this here also, in case malloc is called before main. */
  align = ((char *) &obj.u) - ((char *) &obj.ch);

  malloc_calls++;
  malloc_p += roundup (size);
  return ret_val;
}

int
main (void)
{
  register unsigned early_calls;
  register unsigned total_calls;

  align = ((char *) &obj.u) - ((char *) &obj.ch);

  early_calls = malloc_calls;
  printf ("There were %u malloc calls before main.\n", early_calls);
  total_calls = malloc_calls;
  printf ("There were %u malloc calls during the prior printf.\n",
          total_calls - early_calls);
  printf ("Standard malloc block alignment for this implementation is %u bytes.\n",
          align);
  return 0;
}
--

-- 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 <rfgCvpCJ4.I3F@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

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

What is the basis of your understanding?  I don't have my copy of the
ISO C standard here, so I am going out on a limb, but I believe that
in a hosted environment, all of the library function names are
reserved in the global name space.  (E.i.: you can write and use a
static function malloc if your compilation unit doesn't include
stdlib.h, but you are not allowed to provide a global one.)

As for malloc not being used by library routines, where does it say
this.  There are a number of definite statements of the sort: the
library shall perform as if function x is not called by any other
library routine, but I don't remember malloc being among them.

As for the upcoming C++ standard...  I believe that this is to be
handled by namespaces.  The system libraries are in a specific
namespace, and that namespace belongs to the system.  So you can
define as many mallocs as you like in other namespaces, but you cannot
define anything in the system namespace.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <rfgCvpCJ4.I3F@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> 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

Ronald F. Guilmette (rfg@netcom.com) wrote:
> In article <CvIH4L.8G2@crdnns.crd.ge.com> volpe@ausable.crd.ge.com writes:
> >In article <1994Sep2.102654.14783@ida.liu.se>, tompa@ida.liu.se (Thomas Padron-McCarthy) writes:
> >>
> >>In a review of Herbert Schildt's "The Annotated C Standard",
> >>written by C.D.W. Feather,
> >>he says this specifically about Schildt's annotation of 5.2.3:
> >[...]
> >
> >>> 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.

> Recently, I had occasion to try to see if the (POSIX) `getcwd' implementa-
> tion provided by various C/C++ compilers ever called malloc.  (The one
> provided by SunPro seems to do so for some reason, but none of the four
> DOS-based compilers I tried did so.)  Anyway, I initially was getting some
> really strange results from my little test program, so I hacked on it
> until it the results made more sense.  (The test program is given below.)

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

Or perhaps you are wrong.  Please cite where in the standard it says
that the library may not call malloc.  I cannot find it.

--
Mike Rubenstein

rfg@netcom.com (Ronald F. Guilmette) writes:

> 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, `malloc' is reserved for use as an identifier with external linkage.
ANSI Classic 4.1.2.1 ``Reserved Identifiers'' says:

   * All identifiers with external linkage in any of the following sections
     (including the future library directions) are always reserved for use
     as identifiers with external linkage.

This means that a conforming library function can invoke `malloc' without
having to worry about whether a conforming program might redefine `malloc'.
The same thing goes for other Standard C functions, e.g. `remove';
it does not, however, go for functions that are not Standard C functions,
e.g. `unlink'.