What standard library functions must deal with allocated memory?

[Francois Grieu]

I'm trying to list all the standard C99/C2011 library functions that, by
design, must deal with allocated memory in any way.

I've seen calloc malloc realloc free. Is there any other?
If strdup was a standard function (it is not), it would be in my list.

Francois Grieu

 

[James Kuyper]

I'm trying to list all the standard C99/C2011 library functions that, by
design, must deal with allocated memory in any way.

I've seen calloc malloc realloc free. Is there any other?
If strdup was a standard function (it is not), it would be in my list.

In C2011, add aligned_alloc(). Otherwise, your list is complete.

Note that the rules for fopen() and fclose() are written in such a way
that the FILE* objects they return, or the buffers managed by those
objects, could be dynamically allocated, though not necessarily by the
malloc() family. The behavior is undefined if you make any use of a
FILE* returned by fopen(), after it has been passed to fclose(), as
would naturally be the case if it were allocated by a call to malloc().

 

[Francois Grieu]

In C2011, add aligned_alloc(). Otherwise, your list is complete.

Thanks both for the missed one, and the reassurance.

Francois Grieu

 

[Barry Schwarz]

I'm trying to list all the standard C99/C2011 library functions that, by
design, must deal with allocated memory in any way.

I've seen calloc malloc realloc free. Is there any other?
If strdup was a standard function (it is not), it would be in my list.

strdup doesn't really "deal" with allocated memory so much as it uses
the allocated memory malloc provided. If you are going to include all
the functions that call malloc et al then you may need to add:

fopen and fclose if the FILE* returned is allocated dynamically.

memmove and wmemmove if the "as if temporary array" is allocated
dynamically.

It is not a library function but do you want to include variable
length arrays as dealing with allocated memory in some way?

 

[Keith Thompson]

strdup doesn't really "deal" with allocated memory so much as it uses
the allocated memory malloc provided. If you are going to include all
the functions that call malloc et al then you may need to add:

fopen and fclose if the FILE* returned is allocated dynamically.

memmove and wmemmove if the "as if temporary array" is allocated
dynamically.

fopen, fclose, memmove, and wmmemmove, *might* use allocated
memory (via malloc or something similar), but not in any way that
a programmer can or should be concerned with. For example, passing
a FILE* that was returned by fopen to free has undefined behavior.
(And memmove and wmemmove are more likely to simply copy in reverse
order if the source and destination happen to overlap.)

For that matter, any standard library function might allocate and
deallocate memory behind the scenes.

It is not a library function but do you want to include variable
length arrays as dealing with allocated memory in some way?

Depends on what you mean by "allocated" -- and fixed-size arrays,
or any other declared objects, have the same issue. VLAs do not
have allocated storage duration; I'm not sure if that's the criterion
Francois is most concerned with.

 

[Francois Grieu]

strdup doesn't really "deal" with allocated memory so much as it uses
the allocated memory malloc provided.

It would interest me because one can not implement strdup without calling
calloc malloc realloc (since the result must be a valid argument to free).

If you are going to include all
the functions that call malloc et al then you may need to add:

fopen and fclose if the FILE* returned is allocated dynamically.

memmove and wmemmove if the "as if temporary array" is allocated
dynamically.

Neither of these is forced to use calloc malloc realloc, since the number
of files can be limited, and memmove/wmemmove are implementable with no
intermediary array.

It is not a library function but do you want to include variable
length arrays as dealing with allocated memory in some way?

I suspect this is often done using the stack.

Francois Grieu

 

[Eric Sosman]

It would interest me because one can not implement strdup without calling
calloc malloc realloc (since the result must be a valid argument to free).

When did strdup() appear in the Standard library? I don't have
the actual Standard, but strdup() is absent from the ISO/IEC 9899:201x
draft of 2011-04-12.

 

[Quentin Pope]

When did strdup() appear in the Standard library? I don't have
the actual Standard, but strdup() is absent from the ISO/IEC 9899:201x
draft of 2011-04-12.

Why deliberately misrepresent people Eric? Francois said right at the
start that he knows strdup is not standard.

In fact I think he is wrong for another reason. Pointers from malloc
needed to be aligned for all types: a library strdup() function could
potentially use an unaligned malloc-like function as long as the data
structure was still compatible with free().

 

[Dr Nick]

Why deliberately misrepresent people Eric? Francois said right at the
start that he knows strdup is not standard.

In fact I think he is wrong for another reason. Pointers from malloc
needed to be aligned for all types: a library strdup() function could
potentially use an unaligned malloc-like function as long as the data
structure was still compatible with free().

I /think/ it could use something else entirely as long as the pointer so
generated had a magic value that free() could recognise.

So strdup could allocate from an entirely separate pool or pools and
free knows the bounds of any such pools and so knows what do with it.
Could be useful if the use pattern is lots and lots of roughly equal
sized allocations and frees. It would need to do some undefined stuff
in checking pointers against each other to know, but it's part of the
implementation and so allowed to do this.

Am I right?

 

[Malcolm McLean]

בת×ריך ×™×•× ×©× ×™,23 ב×פריל 2012 19:01:49 UTC+1, מ×ת Francois Grieu:

I'm trying to list all the standard C99/C2011 library functions that, by
design, must deal with allocated memory in any way.

I've seen calloc malloc realloc free. Is there any other?
If strdup was a standard function (it is not), it would be in my list.

None of them, except for malloc(), realloc() and free() themselves.

This appears to have been a deliberate design decision. strdup() is an obvious candidate for a library function, but including it would make the string library dependent on an allocation package being available.

 

[Keith Thompson]

בת×ריך ×™×•× ×©× ×™, 23 ב×פריל 2012 19:01:49 UTC+1, מ×ת Francois Grieu:
None of them, except for malloc(), realloc() and free() themselves.

This appears to have been a deliberate design decision. strdup() is an
obvious candidate for a library function, but including it would make
the string library dependent on an allocation package being available.

It wasn't a matter of depending on the availability of an allocation
package; *any* conforming hosted implementation must provide malloc/free
and the functions declared in <string.h>.

I think the committee just felt it was a cleaner design.

 

[Stephen Sprunk]

בת×ריך ×™×•× ×©× ×™, 23 ב×פריל 2012 19:01:49 UTC+1, מ×ת Francois Grieu:

None of them, except for malloc(), realloc() and free() themselves.

This appears to have been a deliberate design decision. strdup() is an
obvious candidate for a library function, but including it would make
the string library dependent on an allocation package being available.

I thought it was a combination of wanting memory-allocation functions to
be clearly identifiable as such and avoiding functions that were trivial
combinations of other primitive functions already provided.

S

 

[Malcolm McLean]

בת×ריך ×™×•× ×¨×‘×™×¢×™, 25 ב×פריל 2012 06:24:33 UTC+1, מ×ת Keith Thompson:

It wasn't a matter of depending on the availability of an allocation
package; *any* conforming hosted implementation must provide malloc/free
and the functions declared in <string.h>.

A lot of implementations aren't conforming hosted implementations. Even MS Windows has a vandalised stderr in Window API mode.
malloc() is one of the functions which is often difficult to provide. It's also banned in some environments. Proably this happens less often now than it did, as memories have got larger, malloc faster, and software design theory better understood. But many people felt that dynamic memory was slow and bug-prone.