General rules on interface (function) design

[Robert Latest]

On Tue, 23 May 2006 16:00:27 -0400,

Are you sure this was the reason? I can find nothing
about the matter in the Rationale; what did I overlook?

I've thought about this, too; my personal explanation so far is that the
committee wanted to keep the memory handling interface small and clean.
I don't think there are any functions besides malloc(), calloc() and
realloc() that return dynamically allocated memory which IMO is a good
idea.

Maybe I'm wrong though. I'd appreciate comments.

robert

 

[Eric Sosman]

On Tue, 23 May 2006 16:00:27 -0400,



I've thought about this, too; my personal explanation so far is that the
committee wanted to keep the memory handling interface small and clean.
I don't think there are any functions besides malloc(), calloc() and
realloc() that return dynamically allocated memory which IMO is a good
idea.

Maybe I'm wrong though. I'd appreciate comments.

These are the only Standard library functions that are
"advertised" to return dynamically allocated memory, hence
the only functions for which the burden of managing the
memory's lifetime falls on the caller, the only functions
whose returned value is safe to pass to free().

However, other library functions "may" return pointers
to dynamically allocated memory. fopen(), for example, returns
a FILE*, a pointer to a FILE. Might the FILE be dynamically
allocated? Certainly it might, and fclose() presumably takes
care of deallocating it.

As I wrote elsewhere in this thread, the important issue
isn't whether memory is dynamically allocated, but that the
allocation is properly managed. When a function allocates
memory, it must be clear who is responsible for managing it
afterwards. malloc() and calloc() and realloc() are the only
Standard library functions that place the entire burden on
their callers, but other functions (like the hypothetical
fopen() above) may make other arrangements.

The original suggestion in this thread was that "local"
functions should not as a rule allocate dynamic memory. I'm
still unsure what "local" is supposed to mean, but does anyone
think it a bad idea for fopen() to call malloc()?

 

[pete]

but does anyone
think it a bad idea for fopen() to call malloc()?

I don't think it breaks anything
if fopen does call malloc,
with the implication you described,
that fclose will behave suitably.

 

[Robert Latest]

On Wed, 24 May 2006 08:53:11 -0400,

The original suggestion in this thread was that "local"
functions should not as a rule allocate dynamic memory. I'm
still unsure what "local" is supposed to mean, but does anyone
think it a bad idea for fopen() to call malloc()?

No. In fact, it probably does on my implementation (a Linux system).
From the fopen(3) manpage:

The fopen, fdopen and freopen functions may also fail and set
errno for any of the errors specified for the routine malloc(3).

There you go.

robert

 

[CBFalconer]

.... snip ...

The original suggestion in this thread was that "local"
functions should not as a rule allocate dynamic memory. I'm
still unsure what "local" is supposed to mean, but does anyone
think it a bad idea for fopen() to call malloc()?

I certainly hope not. I suspect the OP considers statid functions
to be 'local' functions. At any rate I see no problem with such
animals calling malloc and friends, as long as they are clearly
documented as requiring an eventual free, or corresponding release
call. The latter may be necessary for things that have internal
levels, such as structures with pointers to strings.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[lovecreatesbeauty]

I suspect the OP considers statid functions
to be 'local' functions.

Is statid a misspelling of "static"?

I used the word "local" wrongly in the original post. I am sorry to
bring the confusion. Please ignore it.

A function has file scope. When function name is qualified with
"static", the function is visible only within the file. I think this is
the only one difference between a static function and non-static one.
So, some general rules on function interface design can be applied to
static function as same as non-static one.