Questions about malloc()

[Joona I Palaste]

Well, it's about as pointless as returning a value that's always going to
be the same as one of the parameters..

So therefore the current design of free() - not returning anything at
all - is the best.

 

[Joona I Palaste]

So therefore the current design of free() - not returning anything at
all - is the best.

One "clever" use for always returning the value of a specific parameter
would be in fprintf(), to allow this sort of trick:

fclose(fprintf(fopen("foo.txt", "w"), "Hello world!"));

where FILE *fprintf(FILE *stream, char *format, ...) is defined as
returning the stream it writes to.
Of course if the fopen() fails this will cause undefined behaviour.

 

[Charlie Gordon]

One "clever" use for always returning the value of a specific parameter
would be in fprintf(), to allow this sort of trick:

fclose(fprintf(fopen("foo.txt", "w"), "Hello world!"));

Not really clever, childish at best.

where FILE *fprintf(FILE *stream, char *format, ...) is defined as
returning the stream it writes to.
Of course if the fopen() fails this will cause undefined behaviour.

QED

Conversely, the string functions that return their destination parameter can be
used that way :

fp = fopen(strcat(strcat(strcpy(dest, dir), "/"), filename), "r");

But that is pretty lame too, and doesn't add much to neither readability nor
performance.
Not to mention lack of precise semantics : what if dir end with / already, what
if it is "/" iself ? what does an empty dir mean is this context ?...

 

[Charlie Gordon]

The advantage the assembly programmer has is knowing the
actual cases that are important, and may be able to make
optimizations that a compiler can't. Just one example.

A program may need to multiply two N bit integers generating
a 2N bit product. In C this must be done by multiplying two
2N bit numbers, yet the hardware might have an instruction
that can multiply N bit numbers with a 2N bit product.
It is possible the compiler will figure this out, but it
is likely that it won't.

Some machines have some special instructions that are
not normally used by compilers. It might be that they
are not useful in the general case, but are in a
specific case.

That's a good example, but a good compiler will notice the pattern and produce
the correct code :

short op1, op2;
long result = (long)op1 * (long)op2;

long op1, op2;
long long result = (long long)op1 * (long long)op2;

where short is 16 bits, long is 32 bits ans long long is 64 bits.
gcc will use the appropriate IA86 instruction for these instead of using the
general case.

Evolution has made compilers very clever, but programmers still beat them on
intelligence sometimes.

 

[Michael Wojcik]

AFAIK free()ing a properly allocated pointer always succeeds, and
free()ing a pointer that has not been properly allocated always causes
undefined behaviour.

free(0) has defined behavior. Not that it matters particularly to this
argument, which I agree with - there's little point in returning any
value from free.

 

[CBFalconer]

Well, it's about as pointless as returning a value that's always
going to be the same as one of the parameters..

No, that last has the advantage of inducing silly programming
errors and making FAQs valuable.

 

[CBFalconer]

.... snip ...

One "clever" use for always returning the value of a specific
parameter would be in fprintf(), to allow this sort of trick:

fclose(fprintf(fopen("foo.txt", "w"), "Hello world!"));

where FILE *fprintf(FILE *stream, char *format, ...) is defined
as returning the stream it writes to. Of course if the fopen()
fails this will cause undefined behaviour.

fprintf is not so defined, it actually returns a useful value.
Some idiot is going to try your statement and get all sorts of
nonsense.

 

[Dave Vandervies]

C is designed to beat assembly programmers, to shorten development
time in assembly developement, to shorten runtime and/or resource
usage whenever possible and to increase portability.

Just like any other general-purpose high-level language, then?


dave

 

[Eric Sosman]

[...]

It would be trivial for malloc/realloc/calloc to 'remember' what
they do in a List so that free() can do the right thing. If we call
free() with a 'wild' pointer the system would look it up in the List
and, not finding it, do nothing.

Nothing in the Standard forbids such an implementation.
Indeed, I have written implementations that maintain such
records as debugging aids -- but when trouble is detected
they complain as loudly as they can rather than doing nothing.

[...]
Also, because the List remembers ALL *alloc() calls, we can support
yet another function, freeall(), which will free all allocated memory.
[...]

Why would anybody ever want such a thing? Or to put
it another way: What actions could a program take after
a freeall() without risking undefined behavior? Which
library functions are forbidden to obtain memory from
malloc(), or are required to work even if their allocated
memory is torn out from underneath them without warning?
What good is a pointer obtained from malloc() if it can
be invalidated at any moment by a completely unrelated
piece of code that doesn't even have knowledge of the
pointer's existence?

In light of such issues, I think the Standard already
provides freeall(), but under a different name: abort().

 

[Dan Pop]

Flash Gordon wrote:

(snip)


(snip)

For a sufficiently small piece of code I could probably agree.
That size might be about 10 lines of C. Past that, the
combinatorics are so bad that the assembly programmer would
never finish. A compiler using a dynamic programming algorithm
can find an optimal path through a long series of operation
extremely fast.

The nature of the target processor makes quite a lot of difference.
Compilers have never been competitive on 8-bit CPUs with limited
resources (even when used as cross-compilers and run on platforms with
plenty of resources). I haven't even heard about a C compiler for
the i8048 chip, yet I've written many non-trivial embedded control
applications for that platform in assembly. The smallest chip a C
compiler can target seems to be the i8051, but I doubt many applications
have been written in C for the unextended i8051 chip.

Dan

 

[Dan Pop]

Yea, I suppose not. It could return a NULL:

p = free(p);

I just think free()'ing p and setting p = 0 should be handled in one step
since the operations are closely related and it avoids programmer error.

Now, engage your brain and explain what's the point of nullifying p if
you don't also nullify *all* the other pointers currently pointing into
the memory block that is being deallocated.

And if a free() returning a null pointer is what you want, you can
trivially have it:

#define FREE(p) (free(p), (void *)0)

Dan