Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #19839 > unrolled thread

What standard library functions must deal with allocated memory?

Back to article view | Back to comp.lang.c

Contents

  What standard library functions must deal with allocated memory? Francois Grieu <fgrieu@gmail.com> - 2012-04-23 20:01 +0200
    Re: What standard library functions must deal with allocated memory? James Kuyper <jameskuyper@verizon.net> - 2012-04-23 14:17 -0400
      Re: What standard library functions must deal with allocated memory? Francois Grieu <fgrieu@gmail.com> - 2012-04-23 20:37 +0200
    Re: What standard library functions must deal with allocated memory? Barry Schwarz <schwarzb@dqel.com> - 2012-04-23 12:26 -0700
      Re: What standard library functions must deal with allocated memory? Keith Thompson <kst-u@mib.org> - 2012-04-23 14:04 -0700
        Re: What standard library functions must deal with allocated memory? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-23 17:15 -0500
      Re: What standard library functions must deal with allocated memory? Francois Grieu <fgrieu@gmail.com> - 2012-04-23 23:18 +0200
        Re: What standard library functions must deal with allocated memory? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-23 21:55 -0400
          Re: What standard library functions must deal with allocated memory? Quentin Pope <nospam@nospam.invalid> - 2012-04-24 02:07 +0000
            Re: What standard library functions must deal with allocated memory? Dr Nick <3-nospam@temporary-address.org.uk> - 2012-04-24 07:05 +0100
    Re: What standard library functions must deal with allocated memory? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-24 00:38 -0700
      Re: What standard library functions must deal with allocated memory? Keith Thompson <kst-u@mib.org> - 2012-04-24 22:24 -0700
        Re: What standard library functions must deal with allocated memory? pete <pfiland@mindspring.com> - 2012-04-25 08:04 -0400
        Re: What standard library functions must deal with allocated memory? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-28 04:09 -0700
      Re: What standard library functions must deal with allocated memory? Stephen Sprunk <stephen@sprunk.org> - 2012-04-25 01:19 -0500
        Re: What standard library functions must deal with allocated memory? pete <pfiland@mindspring.com> - 2012-04-25 07:55 -0400
    Re: What standard library functions must deal with allocated memory? gordonb.ho66c@burditt.org (Gordon Burditt) - 2012-04-27 20:44 -0500

#19839 — What standard library functions must deal with allocated memory?

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

[toc] | [next] | [standalone]

#19840

On 04/23/2012 02:01 PM, Francois Grieu wrote:
> 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().

[toc] | [prev] | [next] | [standalone]

#19841

On 23/04/2012 20:17, James Kuyper wrote:
> On 04/23/2012 02:01 PM, Francois Grieu wrote:
>> 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.

Thanks both for the missed one, and the reassurance.

  Francois Grieu

[toc] | [prev] | [next] | [standalone]

#19842

On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu <fgrieu@gmail.com>
wrote:

>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?

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#19850

Barry Schwarz <schwarzb@dqel.com> writes:
> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu <fgrieu@gmail.com>
> wrote:
>
>>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.

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#19855

On Mon, 23 Apr 2012 14:04:09 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Barry Schwarz <schwarzb@dqel.com> writes:
>> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu <fgrieu@gmail.com>
>> wrote:
>>
>>>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.
>
>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.  


I don't think memmove and friends are allowed to fail with an
out-of-memory error, thus they cannot use malloc.

fopen(), sure, but as you mention, it's not required.

[toc] | [prev] | [next] | [standalone]

#19852

On 23/04/2012 21:26, Barry Schwarz wrote:
> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu<fgrieu@gmail.com>
> wrote:
>
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#19857

On 4/23/2012 5:18 PM, Francois Grieu wrote:
> On 23/04/2012 21:26, Barry Schwarz wrote:
>> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu<fgrieu@gmail.com>
>> wrote:
>>
>>> 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.
>
> 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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#19858

On 24 Apr 2012 at  1:55, Eric Sosman wrote:
> On 4/23/2012 5:18 PM, Francois Grieu wrote:
>>> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu<fgrieu@gmail.com>
>>> wrote:
>>>> If strdup was a standard function (it is not), it would be in my list.
<snip>
>> 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.

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().

[toc] | [prev] | [next] | [standalone]

#19860

Quentin Pope <nospam@nospam.invalid> writes:

> On 24 Apr 2012 at  1:55, Eric Sosman wrote:
>> On 4/23/2012 5:18 PM, Francois Grieu wrote:
>>>> On Mon, 23 Apr 2012 20:01:49 +0200, Francois Grieu<fgrieu@gmail.com>
>>>> wrote:
>>>>> If strdup was a standard function (it is not), it would be in my list.
> <snip>
>>> 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.
>
> 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?
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#19861

בתאריך יום שני, 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.

-- 
Basic Algorithms: memory games - how to write your own fast allocators
http://www.malcolmmclean.site11.com/wwww

[toc] | [prev] | [next] | [standalone]

#19885

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> בתאריך יום שני, 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.

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#19900

Keith Thompson wrote:
> 
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > בתאריך יום ×©× ×™, 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.
> 
> 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.

If strdup were to have been part of the standard library,
it would have have made more sense to declare it in stdlib.h
as one of the "Memory management functions",
rather than to declare it in string.h.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#20023

בתאריך יום רביעי, 25 באפריל 2012 06:24:33 UTC+1, מאת Keith Thompson:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.
 
-- 
Basic Algorithms - a must have for every C programmer's library. Now available as an iBook.
http://www.malcommclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#19886

On 24-Apr-12 02:38, Malcolm McLean wrote:
> בתאריך יום שני, 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.

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

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#19899

Stephen Sprunk wrote:
> 
> On 24-Apr-12 02:38, Malcolm McLean wrote:
> > בתאריך יום ×©× ×™, 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.
> 
> 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.

There's already at least a couple of string functions which are 
trivial combinations of other primitive functions already provided.

char *
strcat(char *s1, const char *s2)
{
    strcpy(strlen(s1) + s1, s2);
    return s1;
}

char *
strpbrk(const char *s1, const char *s2)
{
    s1 += strcspn(s1, s2);
    return *s1 != '\0' ? (char *)s1 : NULL;
}

There's also some trivial repackaging declared in stdio.h

int 
vprintf(const char *format, va_list arg)
{
    return vfprintf(stdout, format, arg);
}

and also declared in ctype.h

int 
isalpha(int c) 
{
    return islower(c) || isupper(c);
}

int 
isalnum(int c) 
{
    return isdigit(c) || isalpha(c);
}

-- 
pete

[toc] | [prev] | [next] | [standalone]

#20016

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

strcpy() must "deal with in any way" allocated memory should someone
pass a pointer to dynamically allocated memory to it as one of its
arguments (as source or destination).  Yes, I think that's part of
the design.  The same applies to any standard library function that
takes a pointer to memory that *might be* dynamically allocated as
an argument without at the same time invoking undefined behavior.
I don't think that's what you meant, though.

In this situation, the fact that it's allocated memory is not
relevant unless there's something peculiar in the implementation,
like allocated memory being taken from a region of memory that most
of the machine instructions can't access.  Such a compiler would
have a hard time meeting the standard's requirements unless it
assumed that most every pointer *might* point to dynamically allocated
memory unless it could prove otherwise.

> I've seen calloc malloc realloc free. Is there any other?

By reasonable interpretation of what you meant, I don't think so.

> If strdup was a standard function (it is not), it would be in my list.

fopen() and fclose() are a pair which *could* (not *must*) be
implemented using dynamic memory allocation of FILE structures,
(and they commonly are, but it's not required).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web