my little implementation of malloc

[Mark McIntyre]

I agree with that. How can one write an allocator
without calling the OS?

You probably can't. The point is that it was offtopic in both CLC and
CLA since it is by its nature highly platform specific.

Moreover the style was highly reminiscent of LaCrilola or whatever the
troll was called who enjoys messing with CLC, CLC++ and CLA in similar
fashion. The fact that the comments are in italian is substantive.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[santosh]

jacob navia wrote, On 27/01/07 14:54:

(e-mail address removed) a écrit :

#include <windows.h>
#include <winbase.h>
#include <wincon.h>
#include <winuser.h>
#include "winb.h"

All of the above are non-standard. [...]

you NEED to call system to do memory management.

In any case, based on what others have spotted in the code it looks
suspiciously like the return of a troll who has been here before, in
which case the the purpose is not to demonstrate anything, it is merely
to annoy.

I think he, (ITYM RSolsCrilolia), has always been here, (clc). I
suspect he posts under the handle ab or avb.

 

[Kelly]

(e-mail address removed) a écrit :

I agree with that. How can one write an allocator
without calling the OS?

jacob

I am not an expert in 'c' but then how does malloc allocate memory
independent of different systems then?
this discussion is confusing me!
Is is not possible to write an allocator which is independent of the
architecture and the OS?? i doubt it

 

[Default User]

¬a\/b wrote:

#define P printf
#define W while
#define F for
#define R return

Back again with a new ID? Well, *plonk* again as well.





Brian

 

[santosh]

I am not an expert in 'c' but then how does malloc allocate memory
independent of different systems then?

Generally no, it can't. The implementation of malloc() for a
particular system, does call the system's API to get memory.

this discussion is confusing me!
Is is not possible to write an allocator which is independent of the
architecture and the OS?? i doubt it

Independant of architecture, I doubt that. Independant of the OS,
quite possible, but that's not the case with most desktop and
mainframe computers.

malloc() is in almost all cases, very system dependant, which is why,
among other reasons, ab's post is not topical to clc. It would've for
example been topical in comp.os.ms-windows.win32.programmer. OTOH,
generic allocation strategies are topical to comp.programming.

 

[Keith Thompson]

At some level, yes. The traditional one is brk() and mmap()
has recently been added to most OSes. malloc() itself is _NOT_
a syscall but very deliberately a libc call.

malloc(), as far as the C language is concerned, is simply a standard
function provided by the implementation. The standard doesn't mention
syscalls; malloc() could theoretically be implemented as a syscall, as
an ordinary function call, or as a message sent by carrier pigeon.
(It probably happens to be a function call that may use syscalls
internally on most systems.)

 

[vid512]

hey, don't be nazi.

OK, you've lost the argument according to standard Usenet etiquette.

wow, didn't think this word will "generate" so much reactions. what i
meant: don't follow rules too strict beyond their purpose. simple
phrase.

I've got no idea what you mean by "asmers", but a lot of people don't
use Windows here. Of the half dozen machines I've been using whilst
working today, or example, *none* are running Windows.

most assembly programers i know use win as their workstations. btw, I
count people, not number of their machines.

In any case, based on what others have spotted in the code it looks
suspiciously like the return of a troll who has been here before, in
which case the the purpose is not to demonstrate anything, it is merely
to annoy.

i am pretty new here, no idea. but i would like to test it, i have
been testing my own heap manager recently, and it's no fun to catch
some errors.

Depending on your definition of "calling the OS" I can think of three ways.

sure, i meant more like "using OS-specific interface"

Allocate memory from a large static array.

i meant, real-world usable general heap manager of course...

 

[Flash Gordon]

(e-mail address removed) wrote, On 27/01/07 21:54:

Please leave in the attribution lines. The little bits that say who
posted what. It makes it easier to follow the conversation.

wow, didn't think this word will "generate" so much reactions. what i
meant: don't follow rules too strict beyond their purpose. simple
phrase.

Doesn't matter. The rules are the rules. Anyway, the rules have been
developed for good reasons.

most assembly programers i know use win as their workstations. btw, I
count people, not number of their machines.

Then you only know a small proportion of assembler programmers. My
experience is that most of them are working on embedded systems using
processors that would not run any version of Windows.

i am pretty new here, no idea. but i would like to test it, i have
been testing my own heap manager recently, and it's no fun to catch
some errors.

Test it if you wish, but would you really want to use C code that the C
exports say is bad and from a known troll?

sure, i meant more like "using OS-specific interface"

Then it belongs on an OS-specific group. Surprising that OS-specifics
belong on OS-specific groups, isn't it ;-)

Well, alt.lang.asm might be OK as well for all I know, but comp.lang.c
definitely is *not* the right place.

i meant, real-world usable general heap manager of course...

That *is* a real-world used heap management strategy, and used for very
good reasons.

 

[Mark McIntyre]

most assembly programers i know use win as their workstations.

What, including all the ones programming for Unix, Linux, VMS, MVS ??
Shurely Shome Mishtake.

i meant, real-world usable general heap manager of course...

This _is_ a realworld usable method. Think about what the OS itself
does...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Betov]

most assembly programers i know use win as their workstations.

Therefore your interrest with the "portability" mythology,
must be...



Betov.

< http://rosasm.org >

 

[Betov]

"(e-mail address removed)" <[email protected]> écrivait



Sorry, i just noticed that the return address was:

< alt.lang.asm,comp.lang.c >

.... hopefully, i am utterly drunk... which is way over
any "comp.lang.c"...


Betov.

< http://rosasm.org >

 

[Keith Thompson]

wow, didn't think this word will "generate" so much reactions. what i
meant: don't follow rules too strict beyond their purpose. simple
phrase.

Then say so. The word "Nazi" is highly offensive to many people.

And please don't snip attribution lines (the ones that say "so-and-so
write:")

 

[CBFalconer]

.... snip ...


most assembly programers i know use win as their workstations. btw,
I count people, not number of their machines.

Confusion reigns, due to the crosspost to alt.lang.asm. I am
seeing this in comp.lang.c.

i am pretty new here, no idea. but i would like to test it, i have
been testing my own heap manager recently, and it's no fun to catch
some errors.

Take a look at the testing methods in my nmalloc package, for
DJGPP. Fully tested before it ever called a system routine. There
is a recently discovered bug in the realignment routine, which
causes errors in later gcc versions, and is easily fixed.

<http://cbfalconer.home.att.net/download/>

 

[¬a\\/b]

¬a\/b wrote: [snip]

#define P printf
#define W while
#define F for
#define R return

To avoid being thought an illiterate fool, get rid of the above.

We've been telling him that for years; it hasn't done any good.

you don't take in account that i could be right and all you wrong

 

[Richard Heathfield]

¬a\/b said:

you don't take in account that i could be right and all you wrong

We don't take into account the possibility that the sky will fall on our
heads today, either. So?

 

[vid512]

Then say so. The word "Nazi" is highly offensive to many people.

allright. :]
But some people seem to take some things too seriously sometimes...

And please don't snip attribution lines (the ones that say "so-and-so
write:")

I do it somehow sub-conciously, but i will try. I bet they are useful
with some newsreaders.

 

[vid512]

Take a look at the testing methods in my nmalloc package, for

DJGPP. Fully tested before it ever called a system routine. There
is a recently discovered bug in the realignment routine, which
causes errors in later gcc versions, and is easily fixed.
<http://cbfalconer.home.att.net/download/>

will do, thanks.

 

[vid512]

will do, thanks.

i have looked at it a little. I didn't fully understand some it's
parts ("hook"s), but it works similary like my heap manager.

Differences i spotted are:
- my heap manager saves original requested size of block, and returns
it when asked about size of block by caller. Aligning aspect is thus
hidden from caller.
- there is block signature in header, which helps greatly to catch bad
pointer to block or heap corruption.
- it doesn't have speed-ups like yours freehdrs[] array... maybe i
will steal this idea in future

also, you can easily catch out-of-heap pointers instead of causing
crash... just ensure they are in range <heapptr, heapptr+heapsize)
before accessing them.

the test themselves spare me from some more thinking, i will rewrite
some of them for my lib, thanks again.

PS: use "bsr" instruction for faster "size2bucket()" function on x86

 

[CBFalconer]

i have looked at it a little. I didn't fully understand some it's
parts ("hook"s), but it works similary like my heap manager.

The hook mechanism allows other software to catch calls to and
exits from the various exported routines. See the malldbg module.
Also the documentation in nmalloc.txh. IIRC readme.txt explains
how to convert it into html with standard software.

Differences i spotted are:
- my heap manager saves original requested size of block, and
returns it when asked about size of block by caller. Aligning
aspect is thus hidden from caller.

Pointless, because the original allocator knows how much he
requested. No need to save it.

- there is block signature in header, which helps greatly to catch
bad pointer to block or heap corruption.

With the 'SAVEMEMORY' or something defeated, there are signatures
in nmalloc blocks. They involve expanding the overhead per
allocation from 16 to 24 bytes.

- it doesn't have speed-ups like yours freehdrs[] array... maybe
i will steal this idea in future

also, you can easily catch out-of-heap pointers instead of causing
crash... just ensure they are in range <heapptr, heapptr+heapsize)
before accessing them.

Where a crash is forced, it is known that the memory arena has been
fouled, and there is no way to recover. Otherwise the user can
control the actions of signal and raise. There is no such thing as
a range and heapsize, since there may well be multiple 'heaps' in
use. that is up to the actual action of sbrk. I think sbrkbgn is
the thing that keeps track of multiple heaps. All this, except the
use of sbrk, is fully standard C outside of the assumption of
arithmetic on the pointers.

the test themselves spare me from some more thinking, i will rewrite
some of them for my lib, thanks again.

PS: use "bsr" instruction for faster "size2bucket()" function on x86

No such routine in standard C. It is up to the compiler to decide
what instructions to use.

I just uploaded a revision last night, so you may want to reload
your copy.

 

[Keith Thompson]

also, you can easily catch out-of-heap pointers instead of causing
crash... just ensure they are in range <heapptr, heapptr+heapsize)
before accessing them.

[...]

This is possible on some systems, but not possible in general. Apply
relational operators ("<", "<=", ">", ">=") to pointers that don't
point into the same object (or just past the end of it) invokes
undefined behavior. Not all systems have linear memory addressing
systems.