From Newsgroup: comp.arch

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

But I would be quite surprised if either of those ever made it into
any version of standard C.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On Wed, 16 Oct 2024 1:08:40 +0000, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

But I would be quite surprised if either of those ever made it into
any version of standard C.

sbrk() was in the std. library on PDP-11/70 that I used 1982.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

According to MitchAlsup1 <mitchalsup@aol.com>:

It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

But I would be quite surprised if either of those ever made it into
any version of standard C.

sbrk() was in the std. library on PDP-11/70 that I used 1982.

It was in the library on the PDP-11/45 I used in 1976, too, but
the C library was whatever was in the C library, a mix of Unix
system calls and other stuff. The first C standard wasn't
published until 1985.

In 1976 I also wrote C code that ran on an 11/05 that controlled some
early bitmap terminals. It didn't have sbrk() becasue there wasn't an
operating system underneath.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On 16/10/2024 03:08, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

Note that these are in no way universal. They might be common on some systems, but there are vast numbers of C implementations that are not
used on POSIX or *nix type systems.

And while it is, I think, /possible/ to write a malloc() in pure
portable standard C (plus something like sbrk), it is never done. There
are always advantages in using implementation-specific features for
picking good sizes and alignments, handling locks for threading safety,
using different algorithms with different balances between speed and compactness, and so on.

But I would be quite surprised if either of those ever made it into
any version of standard C.

Indeed.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On 10/15/24 9:08 PM, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

Another possibility might be for the OS/hardware to support
allocate on use. This would be similar to an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
would not be portable, but sbrk() and mmap() are not portable.

(unmap() might be supported by memsetting a page as zero. With
hardware support, this information could be communicated to the
OS. Using deduplication to "free" such memory would also be
possible, but that seems relatively expensive.)

Permissions would seem to require some kind of system call.
(Separating the address space into execute, read-only, and
read-write segments might extend the use cases for such a "simple"
allocation interface. JIT compilation seems problematic.)

I am not certain how/if this could handle an allocation failure
(from the OS) other than by catching signals (SIGSEGV?) from the
OS. If malloc() only found a suitably-sized free chunk in the
address space and did not access any of that page (if it is new),
the signal would point to the first load/store instruction to
access the chunk, which sounds more difficult to handle.

This is not terribly dissimilar to the Mill's backless storage
where hardware allocates a free page when a write is performed to
an appropriately marked region (unitialized backless store reads
as zero). (An OS handles underflow and overflow of the hardware
free list with watermarks to avoid actual, stalling underflow and
overflow.)


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 10/15/24 9:08 PM, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

Another possibility might be for the OS/hardware to support
allocate on use. This would be similar to an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
would not be portable, but sbrk() and mmap() are not portable.

The easiest way to implement malloc in standard C is to
start with a statically defined allocation region.

e.g. malloc.c:

...
static unsigned char region[MAX_HEAP_IN_BYTES];

void *
malloc(size_t size)
{
/* manage heap and return allocation of size bytes */
}

Downside is that the application always uses MAX_HEAP_IN_BYTES
plus the app size in memory; appropriate for standalone apps.
(traditional definition of standalone - no OS or other
runtime support).

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On 16/10/2024 21:41, Scott Lurndal wrote:

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 10/15/24 9:08 PM, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).

Another possibility might be for the OS/hardware to support
allocate on use. This would be similar to an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
would not be portable, but sbrk() and mmap() are not portable.

The easiest way to implement malloc in standard C is to
start with a statically defined allocation region.

e.g. malloc.c:

...
static unsigned char region[MAX_HEAP_IN_BYTES];

void *
malloc(size_t size)
{
/* manage heap and return allocation of size bytes */
}

Downside is that the application always uses MAX_HEAP_IN_BYTES
plus the app size in memory; appropriate for standalone apps.
(traditional definition of standalone - no OS or other
runtime support).

There are other downsides to this.

One is that the "region" must be zeroed by the pre-main startup code.
On some systems, there may be efficient ways to handle this, but on
small embedded devices it usually means effectively memset'ing the heap
before main() can start. That can be a significant inconvenience for
some systems. C has (at the moment) no standard way to say that a
variable does not need to be initialised, but there are usually implementation-specific ways to handle this.

The other issue is that returned memory blocks have a type - they are
arrays of unsigned char - and when you use them for something else, your malloc'ed object aliases part of another normal C object (the array
"region"). This can cause complications with advanced compiler analysis.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On 2024-10-16, John Levine <johnl@taugh.com> wrote:

It was in the library on the PDP-11/45 I used in 1976, too, but
the C library was whatever was in the C library, a mix of Unix
system calls and other stuff. The first C standard wasn't
published until 1985.

Wasn't it 1989?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> writes:

On 2024-10-16, John Levine <johnl@taugh.com> wrote:

It was in the library on the PDP-11/45 I used in 1976, too, but
the C library was whatever was in the C library, a mix of Unix
system calls and other stuff. The first C standard wasn't
published until 1985.

Wasn't it 1989?

The first draft was released in '85, the X3J11 committee
was formed in '83.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On Wed, 16 Oct 2024 15:07:14 -0400, Paul A. Clayton wrote:

Obviously, this would not be portable, but sbrk() and mmap() are not portable.

They are portable at the OS level, since they are part of POSIX.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On Thu, 17 Oct 2024 19:49:59 -0000 (UTC), Thomas Koenig wrote:

On 2024-10-16, John Levine <johnl@taugh.com> wrote:

The first C standard wasn't published until 1985.

Wasn't it 1989?

As I recall, the ANSI standard corresponded to the second edition of the
K&R book.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On 10/20/24 3:07 AM, Lawrence D'Oliveiro wrote:

On Wed, 16 Oct 2024 15:07:14 -0400, Paul A. Clayton wrote:

Obviously, this would not be portable, but sbrk() and mmap() are not
portable.

They are portable at the OS level, since they are part of POSIX.

I think my (theoretical) proposal of "an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault" would be portable
at the OS level, though "portable to some obscure research OS" —
if such was every developed — could be reasonable argued as less
portable than "portable to POSIX".☺

(I do think such is an _interesting_ interface.)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On Sun, 20 Oct 2024 07:08:20 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

On Thu, 17 Oct 2024 19:49:59 -0000 (UTC), Thomas Koenig wrote:

On 2024-10-16, John Levine <johnl@taugh.com> wrote:

The first C standard wasn't published until 1985.

Wasn't it 1989?

As I recall, the ANSI standard corresponded to the second edition of the
K&R book.

I may be mistaken, but my recollection is that '89 ANSI corresponded
to the Kernighan and Plauger book.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> writes:

On Sun, 20 Oct 2024 07:08:20 -0000 (UTC), Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 17 Oct 2024 19:49:59 -0000 (UTC), Thomas Koenig wrote:

On 2024-10-16, John Levine <johnl@taugh.com> wrote:

The first C standard wasn't published until 1985.

Wasn't it 1989?

As I recall, the ANSI standard corresponded to the second edition of the
K&R book.

I may be mistaken, but my recollection is that '89 ANSI corresponded
to the Kernighan and Plauger book.

The book by Kernighan and Ritchie, The C Programming Language, was
first published in 1978; the second edition was published in 1988.

The book by Kernighan and Plauger, Elements of Programming Style,
was first published in 1974, with a second edition published in 1978.

The second edition of K&R was written during the time that the C standardization effort (started roughly 1982) was taking place. The
intent of K&R 2 was to reflect the language specification of the
anticipated ANSI C standard. My understanding is that K&R 2, because
it was finished a year or two before the ANSI C standard was finished,
has some minor differences with respect to C89. (I have not made any
effort to see whether that is so; I am simply passing along second
hand information.)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.arch

On Mon, 21 Oct 2024 18:19:02 -0700, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:

George Neuner <gneuner2@comcast.net> writes:

On Sun, 20 Oct 2024 07:08:20 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

As I recall, the ANSI standard corresponded to the second edition of the >>> K&R book.

I may be mistaken, but my recollection is that '89 ANSI corresponded
to the Kernighan and Plauger book.

The book by Kernighan and Ritchie, The C Programming Language, was
first published in 1978; the second edition was published in 1988.

The book by Kernighan and Plauger, Elements of Programming Style,
was first published in 1974, with a second edition published in 1978.

The second edition of K&R was written during the time that the C >standardization effort (started roughly 1982) was taking place. The
intent of K&R 2 was to reflect the language specification of the
anticipated ANSI C standard. My understanding is that K&R 2, because
it was finished a year or two before the ANSI C standard was finished,
has some minor differences with respect to C89. (I have not made any
effort to see whether that is so; I am simply passing along second
hand information.)

Your information is better than mine 8-)
Thanks.
--- Synchronet 3.20a-Linux NewsLink 1.114