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.
According to MitchAlsup1 <[email protected]>:
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.
According to MitchAlsup1 <[email protected]>:
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.
On 10/15/24 9:08 PM, John Levine wrote:
According to MitchAlsup1 <[email protected]>:
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.
"Paul A. Clayton" <[email protected]> writes:
On 10/15/24 9:08 PM, John Levine wrote:
According to MitchAlsup1 <[email protected]>:
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).
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.
On 2024-10-16, John Levine <[email protected]> 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?
Obviously, this would not be portable, but sbrk() and mmap() are not portable.
On 2024-10-16, John Levine <[email protected]> wrote:
The first C standard wasn't published until 1985.
Wasn't it 1989?
On Thu, 17 Oct 2024 19:49:59 -0000 (UTC), Thomas Koenig wrote:
On 2024-10-16, John Levine <[email protected]> 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.
On Sun, 20 Oct 2024 07:08:20 -0000 (UTC), Lawrence D'Oliveiro <[email protected]d> wrote:
On Thu, 17 Oct 2024 19:49:59 -0000 (UTC), Thomas Koenig wrote:
On 2024-10-16, John Levine <[email protected]> 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.
George Neuner <[email protected]> writes:
On Sun, 20 Oct 2024 07:08:20 -0000 (UTC), Lawrence D'Oliveiro
<[email protected]d> 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.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 13:18:14 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,518,006 |