passing address of pointer for more useful functions

[MJL]

I am working on a small project that involves the manipulation of
dynamically allocated memory for strings. I was wondering why the
string.h functions are the way they are and why not as follows:

mystrcat(char** s1,char** s2);

where s1's memory allocation can now be handled inside of the function
and s2 can be freed and pointed to NULL inside the function.

I'm not saying the built in functions are not useful as they are, but
this seems to be a simple way to hide away some of the messy memory
management statements.

char *s1,*s2;
assignstrings(&s1,&s2);
mystrcat(&s1,&s2);
dostuff(s1);
free s1;

see, not a single visible malloc statement and only one string to free
at end. Of course the functions would have to be well documented for
the use of others.

 

[Jens.Toerring]

I am working on a small project that involves the manipulation of
dynamically allocated memory for strings. I was wondering why the
string.h functions are the way they are and why not as follows:

mystrcat(char** s1,char** s2);

where s1's memory allocation can now be handled inside of the function
and s2 can be freed and pointed to NULL inside the function.

Probably because such functions wouldn't be of general usefulness
and also would open up some nasty cans of worms. Take for example
the string pointed to by s2. There's nothing that would tell you
within your function that this string is actually pointing to
malloc()ed memory - it could also be a pointer to a string literal
or a char array. In that case you wouldn't be able to call free()
on it. Moreove, there are lots of cases where you don't want to
free() the source string.

The same problem would exist for s1. It could also be a pointer
to a char array. And you wouldn't even have any information how
much memory s1 is already pointing to. So how do you decide if
you can realloc() memory at all and if yes if you need to? More-
over, the caller would have to be aware that the address of s1
can change and if there are several other pointers around
pointing to the original string all of them would have to be
updated.

All in all I would say that you gain only a minimal amount in
functionality while making it rather difficult to use that kind
of functions correctly (since they can't be used with all kinds
of strings but only those for which memory has been obtained
dynamically). So they may be very useful for the project of yours
where you know exactly what you do but as general purpose
functions there would be much too many pitfalls the casual user
would have to be aware of.
Regards, Jens

 

[Gordon Burditt]

I am working on a small project that involves the manipulation of

dynamically allocated memory for strings. I was wondering why the
string.h functions are the way they are and why not as follows:

mystrcat(char** s1,char** s2);

where s1's memory allocation can now be handled inside of the function
and s2 can be freed and pointed to NULL inside the function.

All strings are NOT necessarily dynamically allocated strings.

I'm not saying the built in functions are not useful as they are, but
this seems to be a simple way to hide away some of the messy memory
management statements.

The memory management details still need to be visible, among
other things, to prevent memory leaks.

char *s1,*s2;
assignstrings(&s1,&s2);
mystrcat(&s1,&s2);
dostuff(s1);
free s1;

see, not a single visible malloc statement and only one string to free
at end.

mystrcat() frees its second argument!!!???!!! This is an unobvious
behavior that is likely to lead to bugs. Frequently I want to use
a string without destroying it. I'd be interested in seeing what
you intend to do with functions like printf(), strchr(), strtol(),
and strtok().

Another extremely unobvious feature is that mystrcat() may MOVE
where the string points, thereby invalidating any pointers *INTO*
the string.

Your proposed functions do have their uses (although I disagree
strongly with the idea that a read-only string argument to a function
like mystrcat() should be freed by it), but it gets much messier
when you try to deal with strings as *BOTH* strings and sequences
of characters. What's the replacement for s1[2]? Call a function
which allocates a string of length 1 and copies the character (and
adds a terminator)? (Sounds really inefficient, and when do I free
this short string?) How does one iterate over the characters in a
string, for, say, parsing it? It sounds like this would involve a
lot of copying and allocating and freeing.

Of course the functions would have to be well documented for
the use of others.

It seems to me you'd have to know these functions really, really,
really well in order to assure that you don't have memory leaks.
*ANY* function you pass one of these char **'s to might allocate,
free, or reallocate memory. Auditing a program for memory leaks
just got much, much messier. Does the new version of fopen() free()
its first argument? I usually want to keep that around for error
messages.

Gordon L. Burditt