Re: The dangers of replacing malloc()

From: D. J. Bernstein (djb_at_cr.yp.to)
Date: 06/26/03

  • Next message: D. J. Bernstein: "Re: ten thousand small processes" 
    Date: 26 Jun 2003 21:05:07 -0000
To: freebsd-performance@freebsd.org

    Terry proposed that I obtain the desired sequence of sbrk() calls by
    writing my own version of malloc(). I explained how this can destroy
    data; it isn't portable. Terry now makes the rather strange claim that
    POSIX guarantees the portability of the resulting programs---even though
    POSIX doesn't specify sbrk() or various other functions that I use.

    Terry Lambert writes:
    > Memeory allocation in the C library is *defined by standards*,
    > all of which require the ability to replace memory allocation and
    > freeing functions with equivalents, *as a unit*.

    You obviously aren't claiming that POSIX requires _all_ system functions
    to use a replacement malloc()/realloc()/free() library for allocation.
    That would prohibit sbrk() itself, for example.

    Are you trying to say that POSIX requires all _POSIX functions_ to do
    their memory allocation via malloc()/realloc()/free()? This has no
    relevance to anything I said. We aren't talking about programs that
    restrict themselves to the POSIX functions.

    > > Suppose the OS distributor decides that valloc() or xyzalloc() should do
    > > its own thing, rather than calling malloc().
    > Then that OS distributor's OS no longer complies with standards.

    I already showed you code demonstrating that the Linux valloc() works
    this way. If, as you claim, there's a ``standard'' prohibiting the Linux
    behavior, then that ``standard'' is not useful for people who care about
    real-world portability. Anyway, I see no evidence supporting your claim.

    > If you are in non-compliance with the Intel Application Binary Interface
    > specification, you should expect to *minimally* be required to relink,
    > recompile, or have to modify your program source code, each time the
    > OS major version number changes

    If you link statically, upgrades can break your _source code_?

    Wow. I never realized that the -static option had such power. Will it
    also cause hair to grow on your palms?

    ---D. J. Bernstein, Associate Professor, Department of Mathematics,
    Statistics, and Computer Science, University of Illinois at Chicago
    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

  • Next message: D. J. Bernstein: "Re: ten thousand small processes"

    Relevant Pages

    • Re: Win XP. Active Perl and POSIX:termios not implemented
      ... run it on Windows XP with Active Perl I've this warning: ... require POSIX; ... I recommend you to not use POSIX if you want to create multiplatform script or import a few POSIX functions only. ...
      (comp.lang.perl.modules)
    • Re: posix documentation
      ... Marko Vihoma wrote: ... posix documentation ... Where can a brief description of the posix functions be found? ...
      (comp.unix.bsd.freebsd.misc)