How to check whether malloc has allocated memory properly in case ifmalloc(0) can return valid point

[e p chandler]

[OT] Huh? The 8086 was a 16 bit bus version of the 8088. The 8088 came
from
the 8080, the 8080 from the 8008 and the 8008 from the 4004. The 4004 was
designed to do 4 bit (BCD) arithmetic inside a Japanese calculator. I
remember seeing a 4004 based computer design inside a university EE lab
back
in 1972.

Well, the 8086 came before the 8088, but otherwise that is pretty
much the way it went. The 8086 instruction set is designed to be
assembly source compatible (with appropriate macros in a few cases)
with the 8080 instructions set.

[drifting] CALL 5 still exists as an alternative to int 20H, with a
different register mapping, as a relic of CP/M in MS-DOS. Old DOS software
also used FCBs instead of file handles. I've had some very early DOS
software burp on Win NT/XP as it wants more than the usual number of FCBs
(file control blocks). These need to be set in CONFIG.NT instead of
CONFIG.SYS. I don't remember if any DOS Fortran compilers fall into that
category.
So when I go to 64 bit Windows I can finally kiss MS-DOS goodbye.

 

[Tim Rentsch]

I may have misunderstood Keith's post else-thread, but it (Message-ID:
<[email protected]>) contradicts what you say above
(i.e., the implementation could return a pointer that is non-null and
unique so that p == q holds).

I think you did misunderstand it, presumably because I didn't state it
clearly enough. Eric is correct.

Here's what I wrote:

| I think the way the current definition came about is something
| like this: Before C89, some implementations had malloc(0) return a
| unique pointer value (that couldn't safely be dereferenced), and
| some had it return a null pointer. The former is arguably more
| consistent with the behavior of malloc() for non-zero sizes, and
| lets you distinguish between results of different malloc(0) calls; it
| makes malloc(0) a convenient way to generate a pointer value that's
| non-null, guaranteed to be unique, and consumes minimal resources.
| The latter avoids the conceptual problems of zero-sized objects.
| The ANSI C commmittee chose to allow either behavior, probably
| to avoid breaking existing implementations; they also defined the
| behavior of realloc() so it could deal consistently with either a
| null pointer or a pointer to a zero-sized object.
|
| Personally, I think it would have been better to define the behavior
| consistently and let implementations conform to what the standard
| requires.

What I meant by "unique pointer value" is a pointer value that's
unique *for each call*.

And something I missed: even an implementation that returns a
unique (per-call) non-null pointer value for malloc(0) cannot do
so arbitrarily many times. Each call (assuming nothing is free()d)
consumes some resources, at least address space if not actual memory.
Eventually there won't be enough left to allocate the bookkeeping
information, and malloc(0) will fail and return a null pointer
anyway.

But if you want a series of unique address values, and you're not
planning to dereference any of them, malloc(1) will serve the same
purpose. [snip]

It might not serve it equally well. A malloc(0) call could
allocate pointers to non-writable (or even non-accessible)
memory, and malloc(1) can't do that. There is (in some cases)
value in having malloc(0) return a pointer other than NULL.

 

[David Thompson]

But if you want a series of unique address values, and you're not
planning to dereference any of them, malloc(1) will serve the same
purpose. Or, with less overhead, you could return addresses of
successive elements of a big char array, expanding it with realloc()
as needed.

realloc() could invalidate the already-assigned values, and in theory
even fetching or comparing them would be UB; more practically I can
easily see examples where this results in duplicate addresses being
returned, thus not being unique as intended.

You need to allocate a new array 'chunk' without altering the old
one(s). You can probably just leak the old chunk(s), although
personally I would keep a linked-list just in case I should want to do
some debug checking or maybe statistics.

 

[Keith Thompson]

realloc() could invalidate the already-assigned values, and in theory
even fetching or comparing them would be UB; more practically I can
easily see examples where this results in duplicate addresses being
returned, thus not being unique as intended.

You need to allocate a new array 'chunk' without altering the old
one(s). You can probably just leak the old chunk(s), although
personally I would keep a linked-list just in case I should want to do
some debug checking or maybe statistics.

Quite right, I should have realized that.