sizeof

[Richard Bos]

What would be non-conforming about it? (My guess is that, given
this scenario, it's possible that malloc succeeds [ie: returns a
non-NULL value], but the program fails later when it access this
memory and the O/S discovers "oops, there's really not enough
virtual memory available to allocate".)

Yes. And this is anathema to solid programming and safe computer
systems.

Nevertheless I believe this is what everyday GNU/Linux actually does--
apparently gives you the block then hits you with a SIGSEGV later when
you try to use it.

A bit like when you go to the bank to withdraw your money and they say,
sorry you can't have it because we've already lent it to other people,
four times over (real banks do not use the "Banker's Algorithm").

Tuppence? *Tuppence*?

Richard

 

[CBFalconer]

I've seen systems which can "allocate" memory without actually
using any memory until something is written to it. As long as
you have at least 103 bits of address space, one could "allocate"
that much memory on such a system, as long as you didn't try to
write to all of it.

There's some debate about whether such systems are conforming.

What would be non-conforming about it? (My guess is that, given
this scenario, it's possible that malloc succeeds [ie: returns a
non-NULL value], but the program fails later when it access this
memory and the O/S discovers "oops, there's really not enough
virtual memory available to allocate".)

Yes. And this is anathema to solid programming and safe computer
systems.

Why should the program fail? This whole scenario is for
multi-process systems, so all that need be done is to have the
program sleep until the actual core is available. All is then
copasetic, remembering that there are no guarantees about speed.

If, in the process, the underlying system signal that it is
overloaded, that is not logically different from what happens when
the power fails. Both are beyond the scope of the language.

 

[Ben C]

Keith Thompson wrote:
[...]
I've seen systems which can "allocate" memory without actually
using any memory until something is written to it. As long as
you have at least 103 bits of address space, one could "allocate"
that much memory on such a system, as long as you didn't try to
write to all of it.

There's some debate about whether such systems are conforming.

What would be non-conforming about it? (My guess is that, given
this scenario, it's possible that malloc succeeds [ie: returns a
non-NULL value], but the program fails later when it access this
memory and the O/S discovers "oops, there's really not enough
virtual memory available to allocate".)

Yes. And this is anathema to solid programming and safe computer
systems.

Why should the program fail? This whole scenario is for
multi-process systems, so all that need be done is to have the
program sleep until the actual core is available. All is then
copasetic, remembering that there are no guarantees about speed.

This is sometimes a good approach, but it can cause deadlock. Suppose
you have two processes (two instances of the same process let's say)
that have both allocated huge amounts of memory, and have both reached
line 6 below, and are both waiting for those 100 bytes (there are only
50 bytes left):

1: T *everything_else = malloc(LOTS);
2: ...
3:
4: T *buf = malloc(100);
5: if (buf == NULL) exit(1);
6: f(buf); /* waits for buf to actually be
available */
7: free(buf);
8: free(everything_else);

Since there are only 50 bytes left on the heap, many other processes
may end up waiting as well, which might cause deadlocks on other
resources. The user will probably have to cause the power to fail...

 

[CBFalconer]

.... snip ...

What would be non-conforming about it? (My guess is that, given
this scenario, it's possible that malloc succeeds [ie: returns a
non-NULL value], but the program fails later when it access this
memory and the O/S discovers "oops, there's really not enough
virtual memory available to allocate".)

Yes. And this is anathema to solid programming and safe computer
systems.

Why should the program fail? This whole scenario is for
multi-process systems, so all that need be done is to have the
program sleep until the actual core is available. All is then
copasetic, remembering that there are no guarantees about speed.

This is sometimes a good approach, but it can cause deadlock.
Suppose you have two processes (two instances of the same process
let's say) that have both allocated huge amounts of memory, and
have both reached line 6 below, and are both waiting for those
100 bytes (there are only 50 bytes left):

Anytime you have concurrent processes contending for resources you
can have deadlocks. This is not concerned with the C language in
the least. The point is purely that optimistic filling of malloc
requests is, or can be, conforming.

 

[Kenneth Brody]

[...]
(BTW, does the Standard say where variable-length arrays are stored?
Can the compiler do the equivalent of malloc/free to handle it?)

Sure.

this would make it impossible to use such constructs in a signal
handler (or other reentrant context).

Not if the implementation gets it right. [...]
Likewise, if VLAs are allocated by malloc, the implementation has to
free them at the right time. This might be more difficult, but I know
of no reason why it wouldn't be possible.

Well, it would require a reentrant version of malloc/free, lest it
fail if the signal handler were called from within malloc/free.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Richard Tobin]

Anytime you have concurrent processes contending for resources you
can have deadlocks. This is not concerned with the C language in
the least.

However it explains why there may well be no real systems that satisfy
your theoretically true assertion:

The point is purely that optimistic filling of malloc
requests is, or can be, conforming.

-- Richard

 

[Richard Tobin]

[/QUOTE]

Well, it would require a reentrant version of malloc/free

Fortunately these are widely available.

-- Richard

 

[tedu]

Well, it would require a reentrant version of malloc/free

Fortunately these are widely available.[/QUOTE]

such as? all the implementations i'm familiar with (which may be a
limited set) have some degree of support for threads, but are certainly
not safe to call from within a signal handler.

 

[CBFalconer]

such as? all the implementations i'm familiar with (which may be
a limited set) have some degree of support for threads, but are
certainly not safe to call from within a signal handler.

Since malloc, by its very nature, is allocating a limited system
resource, namely memory, it must have protected access to various
variables. This means it cannot be truly re-entrant. However, by
use of suitable concurrency constructs it can be made thread safe.

 

[Richard Tobin]

Fortunately these are widely available.

[/QUOTE]

such as? all the implementations i'm familiar with (which may be a
limited set) have some degree of support for threads, but are certainly
not safe to call from within a signal handler.

I had read that the Solaris malloc was re-entrant, but I can't find
any such statement in Sun's own documentation.

-- Richard

 

[$hiv.....]

Xicheng Jia posted:



A macro function perhaps:


#define SizeOf(Type) \
( \
(const char*)128 - \
\
(const char*)( (const Type*)128 - 1 ) \
)

it will not compile if we give like this, any Solutions for this ??
SizeOf( 4 )

 

[Andrew Poelstra]

it will not compile if we give like this, any Solutions for this ??
SizeOf( 4 )

Just use regular sizeof().

 

[Frederick Gotham]

$hiv..... posted:

it will not compile if we give like this, any Solutions for this ??
SizeOf( 4 )

#define SizeOf( L-value ) \
( \
(const char*)(&L-value + 1) \
- (const char*)(&L-value) \
)

I'm getting bored of this one... any ideas for another riddle?

 

[Richard G. Riley]

No more than it says where anything is stored. VLAs are like any
other auto objects; they're created at the point of declaration, and
cease to exist at the end of their scope.


There's some debate about whether such systems are conforming.

OT : interestingly enough Linux malloc works like this. It was a
surprise to me.

from the man page :

By default, Linux follows an optimistic memory allocation
strategy. This means that when malloc() returns non-NULL there
is no guarantee that the memory really is available. This is a
really bad bug.

 

[ozbear]

Since malloc, by its very nature, is allocating a limited system
resource, namely memory, it must have protected access to various
variables. This means it cannot be truly re-entrant. However, by
use of suitable concurrency constructs it can be made thread safe.

Nonsense. A trivial implementation of malloc which just passes an
allocation request on to the underlying O/S and an implementation
of free that does the same to perform the deallocation can
certainly be fully re-entrant.

Oz

 

[CBFalconer]

Nonsense. A trivial implementation of malloc which just passes an
allocation request on to the underlying O/S and an implementation
of free that does the same to perform the deallocation can
certainly be fully re-entrant.

Where did you find an OS even mentioned? If you have one, what
makes you think its system calls are re-entrant?

 

[pete]

Where did you find an OS even mentioned? If you have one, what
makes you think its system calls are re-entrant?

This is what the standard says about reentrancy:
The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

I also recall a somewhat cerebral analysis of the standard,
by Ben Pfaff,
which identified a few standard library functions
as having to be reentrant.
I don't recall malloc as being one of them.

The point I'm getting at,
is that you're slipping towards offtopicancy.

 

[CBFalconer]

This is what the standard says about reentrancy:
The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static storage duration.

I also recall a somewhat cerebral analysis of the standard, by Ben
Pfaff, which identified a few standard library functions as having
to be reentrant. I don't recall malloc as being one of them.

The point I'm getting at, is that you're slipping towards
offtopicancy.

Hardly. I am pointing out why the malloc group cannot be reentrant.

 

[Richard Bos]

Keith Thompson wrote:
[...]
I've seen systems which can "allocate" memory without actually
using any memory until something is written to it. As long as
you have at least 103 bits of address space, one could "allocate"
that much memory on such a system, as long as you didn't try to
write to all of it.

There's some debate about whether such systems are conforming.

What would be non-conforming about it? (My guess is that, given
this scenario, it's possible that malloc succeeds [ie: returns a
non-NULL value], but the program fails later when it access this
memory and the O/S discovers "oops, there's really not enough
virtual memory available to allocate".)

Yes. And this is anathema to solid programming and safe computer
systems.

Why should the program fail?

Don't ask me, ask the people who write such over-clock^tconfid^t
allocating systems, and typically do make one program or another crash
and burn when they run out of over-allocated memory.

Richard

 

[Richard Tobin]

Where did you find an OS even mentioned?

Why does it have to have been mentioned, when providing an example of
how something is possible?

If you have one, what
makes you think its system calls are re-entrant?

Most operating systems will provide locking such that an implementation
of malloc that just calls the OS for each allocation will appear to be
re-entrant in that you can't make it "go wrong" by calling malloc from
signal handlers. Perhaps you meant to exclude this by adding "truly"
before "re-entrant"?

-- Richard