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

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

Does ANSI C allow free() to always be empty?

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

Contents

  Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-08 22:08 -0800
    Re: Does ANSI C allow free() to always be empty? Kaz Kylheku <kaz@kylheku.com> - 2014-03-09 06:55 +0000
      Re: Does ANSI C allow free() to always be empty? David Brown <david.brown@hesbynett.no> - 2014-03-10 00:47 +0100
        Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-09 22:37 -0700
          Re: Does ANSI C allow free() to always be empty? David Brown <david.brown@hesbynett.no> - 2014-03-10 10:20 +0100
            Re: Does ANSI C allow free() to always be empty? Keith Thompson <kst-u@mib.org> - 2014-03-10 08:52 -0700
            Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-10 20:51 -0700
              Re: Does ANSI C allow free() to always be empty? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-11 01:08 -0500
              Re: Does ANSI C allow free() to always be empty? David Brown <david.brown@hesbynett.no> - 2014-03-11 12:52 +0100
                Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-12 00:09 -0700
                  Re: Does ANSI C allow free() to always be empty? David Brown <david.brown@hesbynett.no> - 2014-03-12 12:59 +0100
        Re: Does ANSI C allow free() to always be empty? Kaz Kylheku <kaz@kylheku.com> - 2014-03-10 09:01 +0000
      Re: Does ANSI C allow free() to always be empty? Nick Bowler <nbowler@draconx.ca> - 2014-03-10 15:56 +0000
    Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-09 01:11 -0800
      Re: Does ANSI C allow free() to always be empty? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-09 12:39 +0000
        Re: Does ANSI C allow free() to always be empty? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-09 13:05 +0000
        Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-09 22:28 -0700
          Re: Does ANSI C allow free() to always be empty? Martin Shobe <martin.shobe@yahoo.com> - 2014-03-10 07:27 -0500
            Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-10 20:55 -0700
              Re: Does ANSI C allow free() to always be empty? Martin Shobe <martin.shobe@yahoo.com> - 2014-03-11 08:19 -0500
                Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-11 23:22 -0700
                  Re: Does ANSI C allow free() to always be empty? Martin Shobe <martin.shobe@yahoo.com> - 2014-03-12 08:09 -0500
                    Re: Does ANSI C allow free() to always be empty? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 11:29 -0400
        Re: Does ANSI C allow free() to always be empty? Martin Shobe <martin.shobe@yahoo.com> - 2014-03-10 07:29 -0500
    Re: Does ANSI C allow free() to always be empty? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-09 09:14 +0000
      Re: Does ANSI C allow free() to always be empty? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-10 15:33 -0500
    Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-09 23:05 -0700
      Re: Does ANSI C allow free() to always be empty? Martin Shobe <martin.shobe@yahoo.com> - 2014-03-10 07:43 -0500
        Re: Does ANSI C allow free() to always be empty? gordonb.3qcze@burditt.org (Gordon Burditt) - 2014-03-10 12:05 -0500
          Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-10 20:16 -0700
          Re: Does ANSI C allow free() to always be empty? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 16:27 -0700
        Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-10 21:48 -0700
          Re: Does ANSI C allow free() to always be empty? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-11 05:52 +0000
    Re: Does ANSI C allow free() to always be empty? partremmaps@gmail.com - 2014-03-20 19:14 -0700
      Re: Does ANSI C allow free() to always be empty? Kaz Kylheku <kaz@kylheku.com> - 2014-03-21 03:25 +0000
        Re: Does ANSI C allow free() to always be empty? Richard Damon <Richard@Damon-Family.org> - 2014-03-21 20:58 -0400
          Re: Does ANSI C allow free() to always be empty? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 16:11 -0700
            Re: Does ANSI C allow free() to always be empty? Richard Damon <Richard@Damon-Family.org> - 2014-03-29 22:27 -0400
              Re: Does ANSI C allow free() to always be empty? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-30 13:18 -0700
                Re: Does ANSI C allow free() to always be empty? Richard Damon <Richard@Damon-Family.org> - 2014-03-30 20:49 -0400
                  Re: Does ANSI C allow free() to always be empty? Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-17 10:52 -0700
              Re: Does ANSI C allow free() to always be empty? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 11:18 -0400
      Re: Does ANSI C allow free() to always be empty? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-21 03:31 +0000
      Re: Does ANSI C allow free() to always be empty? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 15:39 -0700
        Re: Does ANSI C allow free() to always be empty? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-30 04:22 +0000

Page 1 of 3  [1] 2 3  Next page →

#41500 — Does ANSI C allow free() to always be empty?

According to the ANSI C Standard, may free() be an empty function?

I am not talking about implementations which do not support dynamic memory allocation.

I am also not talking about cases where free() is passed as an argument something other than a current valid pointer earlier returned by a successful call to calloc, malloc, or realloc.

I am talking about implementations and architecture which fully support malloc, calloc, and realloc, and the situation where free() has been passed a valid and current pointer to currently allocated space, having been allocated earlier by a successful call by malloc().

A couple of people who are in the daily habit of giving C advice on IRC told me that even in these implementations and situations, free() may be an empty function and do nothing and still be standards compliant.

Their reasoning is thus:

"Because the C program cannot, using only semantics of the C Abstract Machine, determine that free() did nothing, it is therefore compliant for free() to do nothing even though it was passed a pointer to valid allocated space having earlier been allocated by malloc()."

and

"On a system where malloc and free are fully supported by hardware and software, free() still may be void and empty and always do nothing while still being ANSI C compliant because free() never has  a measurable effect, so nothing need be done to produce a measurable effect."

I protested that if a program were to allocate and free memory repeatedly, and that if free() were allowed to perform no action, that the computer would run out of memory even though it actually had plenty of memory for the program if free() did as described.

They responded that it was up to the user to select an implementation that did what he needed.

The standard of course does describe free as causing the space pointed by ptr to be deallocated and made available for further allocation.

My concern is not that somebody may try to run a program on a machine which does not have enough memory, but that the program will end up needing an infinite quantity of memory if it is run for long enough, even though it was written in such a way as to free the memory it allocated before allocating more.

If these fellows' claims are true, then this raises more questions like whether input and output functions must also do their described task even under circumstances where the C program, using only semantics of the C Abstract Machine, has no way to determine that the described side effect actually took place.

For example, if stat and fopen and all file open/existence related functions were "optimized" in such a way to always falsely return "file not found," then the C program, when using only the semantics of the C Abstract machine, would not be able to tell that the file did actually exist, and thus the implementation should be considered compliant.

For another example, what if putchar() was "optimized" to simply return the character supplied to it as an argument but neglected to actually put the char to stdout - the C program could not test whether the char was actually sent to stdout.

These fellows responded that a human could observe that a file did indeed exist or that nothing was being sent to stdout, and that was sufficient to observe a missing side effect.

However, they said that a human observing a memory leak was not allowed as a test but that the test of whether a side effect was performed could only be tested by the C program in question, and only within the semantics of the C Abstract machine.

Furthermore, If said claim is true, then it raises the question of why does the standard describe a specific functionality if it doesn't really matter if free() does anything anyway?

To me, memory is a finite resource, and whether free frees it as described does matter, which is why the standard specifies an action for free.

In other words, for free() to fail to do as the standard describes, the operation of the program could be severely affected.

They cite the standard where it talks about optimization and says "An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced"
(See section "Program Execution" in the standard.)

The value of free() may not be used, but the freed memory well could be used.

The standard also says that modifying an object (or calling a function that does so) is a side effect.
(See section "Program Execution".)

But does free() particularly modify an object? It does delete it, but is that considered a modification to the execution environment?

But I guess the question is whether one ought to take a subtle technical wording in such a way as to render other explicit content of the standard to be meaningless in such a way that the program would behave drastically outside of how it was written according to the standard.

The standard does say (in cases where there is an operating system other than the C program in question) that free() shall conform to the described specification if it is present. (See "Execution environments" and "Hosted environment.")

To me, common sense says that it would be incorrect to construe a vague technical wording to render explicit portions of the standard meaningless.

My view is that, according to the standard, free() must do exactly as described in the standards under the section "The free function," and that it makes no sense to construe the standard in such a way as to void its very explicitly described functionality of various functions.

Is there a definitive answer on whether free() may be empty and void and still standards compliant, in the context of this post?

Thanks,

~Jesse

[toc] | [next] | [standalone]

#41501

On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
> According to the ANSI C Standard, may free() be an empty function?

Of course, this is an empty function:

  void free(void *ptr) { }

But just to be sure, that is what you mean, right?

I believe the answer is yes.

> A couple of people who are in the daily habit of giving C advice on IRC told
> me that even in these implementations and situations, free() may be an empty
> function and do nothing and still be standards compliant.

This is correct. To require free to actually liberate memory would mean that
an implementation cannot turn free into a no-op and provide garbage collection.

However, if an implementation doesn't provide garbage collection, and its free
function does nothing, that will obviously cause memory leaks in
C programs, and big, runaway memory leaks in some kinds of C programs.

This would simply count as a low quality implementation.

> Their reasoning is thus:
>
> "Because the C program cannot, using only semantics of the C Abstract
> Machine, determine that free() did nothing, it is therefore compliant for
> free() to do nothing even though it was passed a pointer to valid allocated
> space having earlier been allocated by malloc()."

However, a C program can bomb because it exhausted all memory, even though the
program meticulously uses free, and there should be plenty of memory available
for that program.

In the real world, that is a visible effect.

A C implementation can conform to the standard and be a piece of crap in all
sorts of ways besides this. Conformance is only part of the picture.

For instance, a compiler can be conforming, yet do things like generate code
which passes and returns structures in a global memory area. Users who expect
to be able to use that compiler to write re-entrant code in their OS kernel
require a compiler to generate reentrant code for call and returns. This means
that the compiler has to conform to an additional requirement which isn't in
the ISO C standard.  There are all kinds of requirements like that.

Diagnostics are an obvious area. A conforming C compiler can simply stop
translating and put out a message like "this translation unit requires a
diagnostic according to ISO C".  But, of course, users want to know what kind
of diagnostic, and in what line of code.  That is not required by the standard!

The ISO C standard is not (and is not meant to be) a complete requirement
specification for a useful implementation of C.

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

#41526

On 09/03/14 07:55, Kaz Kylheku wrote:
> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>> According to the ANSI C Standard, may free() be an empty function?
>
> Of course, this is an empty function:
>
>    void free(void *ptr) { }
>
> But just to be sure, that is what you mean, right?
>
> I believe the answer is yes.
>
>> A couple of people who are in the daily habit of giving C advice on IRC told
>> me that even in these implementations and situations, free() may be an empty
>> function and do nothing and still be standards compliant.
>
> This is correct. To require free to actually liberate memory would mean that
> an implementation cannot turn free into a no-op and provide garbage collection.
>
> However, if an implementation doesn't provide garbage collection, and its free
> function does nothing, that will obviously cause memory leaks in
> C programs, and big, runaway memory leaks in some kinds of C programs.
>
> This would simply count as a low quality implementation.
>

There are (at least) two types of program for which an empty free() and 
no garbage collection would be perfectly acceptable.  The first is 
programs that don't allocate heap memory at all - you can do a lot 
without it.  In the world of small-system embedded programming, malloc() 
and free() are rare, and are often banned entirely by coding standards. 
  The second would be programs that don't need much re-use of memory, 
and run under an OS - they can simply keep all their memory until the 
program ends and the OS frees it.  There is also the combination - 
embedded programs that allocate memory initially, but never need to free 
it because they never end (until someone turns the power off).

The few times I have used malloc() and free() in small embedded systems, 
the malloc() just used a simple index in a statically-allocated memory 
pool, and free() was empty.

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

#41533

On Sunday, March 9, 2014 4:47:12 PM UTC-7, David Brown wrote:
> On 09/03/14 07:55, Kaz Kylheku wrote:
>
> > On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>
> >> According to the ANSI C Standard, may free() be an empty function?
>

<snip>

>
>
>
> There are (at least) two types of program for which an empty free() and
>
> no garbage collection would be perfectly acceptable.  The first is
>
> programs that don't allocate heap memory at all - you can do a lot
>
> without it.  In the world of small-system embedded programming, malloc()
>
> and free() are rare, and are often banned entirely by coding standards.
>
>   The second would be programs that don't need much re-use of memory,
>
> and run under an OS - they can simply keep all their memory until the
>
> program ends and the OS frees it.  There is also the combination -
>
> embedded programs that allocate memory initially, but never need to free
>
> it because they never end (until someone turns the power off).
>
>
>
> The few times I have used malloc() and free() in small embedded systems,
>
> the malloc() just used a simple index in a statically-allocated memory
>
> pool, and free() was empty.


If I understand correctly, the standard makes allowance for embedded applications which it calls freestanding environment which do not benefit from an operating system.

And indeed, if I understand correctly, in a freestanding environment, it appears that the standard allows library facilities to be implementation defined - which would allow for free() to be empty.

I too have used C on little micros - and I agree, you don't really need malloc to manage 256 bytes of ram! And if you did, the standard does allow a lot of leeway in how those functions are implemented, so an empty free() would be allowed.

However, the context of my original question was for a system where the program was running with the benefit of an operating system and as such, "shall conform to the following specifications...", one of which free() is. (See section Hosted Environment.)

Thanks,

~Jesse

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

#41539

On 10/03/14 06:37, partremmaps@gmail.com wrote:
> On Sunday, March 9, 2014 4:47:12 PM UTC-7, David Brown wrote:
>> On 09/03/14 07:55, Kaz Kylheku wrote:
>> 
>>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com>
>>> wrote:
>> 
>>>> According to the ANSI C Standard, may free() be an empty
>>>> function?
>> 
> 
> <snip>
> 
>> 
>> 
>> 
>> There are (at least) two types of program for which an empty free()
>> and no garbage collection would be perfectly acceptable.  The first
>> is programs that don't allocate heap memory at all - you can do a
>> lot without it.  In the world of small-system embedded programming,
>> malloc() and free() are rare, and are often banned entirely by
>> coding standards. The second would be programs that don't need much
>> re-use of memory, and run under an OS - they can simply keep all
>> their memory until the program ends and the OS frees it.  There is
>> also the combination - embedded programs that allocate memory
>> initially, but never need to free it because they never end (until
>> someone turns the power off).
>> 
>> 
>> The few times I have used malloc() and free() in small embedded
>> systems, the malloc() just used a simple index in a
>> statically-allocated memory pool, and free() was empty.
> 
> 
> If I understand correctly, the standard makes allowance for embedded
> applications which it calls freestanding environment which do not
> benefit from an operating system.
> 

Yes.

> And indeed, if I understand correctly, in a freestanding environment,
> it appears that the standard allows library facilities to be
> implementation defined - which would allow for free() to be empty.

Yes.  I think there are some restrictions about what the library
facilities should do, even in a freestanding environment - but you don't
need to implement everything.  In particular, a freestanding
implementation does not have to include <stdlib.h>.

As far as I read the wording in the C11 standards, a conforming hosted
implementation /could/ have malloc() always return 0, and free() be empty.

Even in embedded systems, of course, these functions are usually
implemented "sensibly" in the library.  It is the choice of the user to
overrule them with a simple implementation (such as an empty free()) if
that suits the application.

> 
> I too have used C on little micros - and I agree, you don't really
> need malloc to manage 256 bytes of ram! And if you did, the standard
> does allow a lot of leeway in how those functions are implemented, so
> an empty free() would be allowed.

People writing high reliability, safety-critical, or real-time embedded
systems will generally avoid any sort of dynamic memory if they can -
memory size has nothing to do with it.  If it is unavoidable (it is
difficult to implement a network stack efficiently without some dynamic
memory handling, for example), then they normally write specific and
targeted dynamic memory handling with fixed size pools.  The trouble
with standard malloc() and free() is that it is extremely difficult to
reason about them, it is very difficult to guess their timing, they can
sometimes fail, and general malloc() algorithms are prone to memory
fragmentation which can be a huge problem in embedded systems (without
virtual memory).

> 
> However, the context of my original question was for a system where
> the program was running with the benefit of an operating system and
> as such, "shall conform to the following specifications...", one of
> which free() is. (See section Hosted Environment.)
> 

Fair enough - I was just pointing out some wider variety.

My own reading of the standards is that an empty free() is allowed in
hosted environments, and it could be useful since the OS will re-claim
the memory on program termination anyway.  (That assumes an
appropriately powerful OS, of course.)

> Thanks,
> 
> ~Jesse
> 

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

#41551

David Brown <david.brown@hesbynett.no> writes:
> On 10/03/14 06:37, partremmaps@gmail.com wrote:
[...]
>> And indeed, if I understand correctly, in a freestanding environment,
>> it appears that the standard allows library facilities to be
>> implementation defined - which would allow for free() to be empty.
>
> Yes.  I think there are some restrictions about what the library
> facilities should do, even in a freestanding environment - but you don't
> need to implement everything.  In particular, a freestanding
> implementation does not have to include <stdlib.h>.
[...]

N1570 5.1.2.1:

    Any library facilities available to a freestanding program, other
    than the minimal set required by clause 4, are implementation-defined.

A freestanding implementation needn't provide malloc() and free() at
all.  It can provide functions with those names that compute square
roots (though that would be perverse).  The headers that are required
for freestanding implementations are the ones that don't declare any
functions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#41591

On Monday, March 10, 2014 2:20:37 AM UTC-7, David Brown wrote:
> On 10/03/14 06:37, partremmaps@gmail.com wrote:
>
> > On Sunday, March 9, 2014 4:47:12 PM UTC-7, David Brown wrote:
>
> >> On 09/03/14 07:55, Kaz Kylheku wrote:
>
> >>
>
> >>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com>
>
> >>> wrote:
>
> >>
>
> >>>> According to the ANSI C Standard, may free() be an empty
>
> >>>> function?
>
> >>
>
> >
>
> >

<snip>

>
>
> > And indeed, if I understand correctly, in a freestanding environment,
>
> > it appears that the standard allows library facilities to be
>
> > implementation defined - which would allow for free() to be empty.
>
>
>
> Yes.  I think there are some restrictions about what the library
>
> facilities should do, even in a freestanding environment - but you don't
>
> need to implement everything.  In particular, a freestanding
>
> implementation does not have to include <stdlib.h>.
>
>
>
> As far as I read the wording in the C11 standards, a conforming hosted
>
> implementation /could/ have malloc() always return 0, and free() be empty.
>


Could you explain which part of C11 would allow malloc() to always return 0 and free() to be empty?


I see in the standard:

5.1.2.2 [Hosted environment]

1   A hosted environment need not be provided, but shall conform to the following
    specifications if present.

then the description of malloc() and free() are below that at 7.22.3 [Memory management functions].


Doesn't that look like a hosted environment shall conform if present?

(At first when I read 5.1.2.2, I thought it meant that the following functions were optional in a hosted environment, but that any function present must conform. However, it really looks like the wording says that if a hosted environment is provided, it shall conform to all of the following specifications.)

And the description of malloc() and friends clearly all describe a general effort to allocate, and "7.22.3 [Memory management functions]" says "The pointer returned if the allocation succeeds is suitably aligned so that it may be ...."

Notice "if the allocation succeeds." One cannot have the chance to succeed if they do not attempt, and simply returning NULL is not attempting anything.

Also, realloc uses both the phrases "If memory for the new object cannot be allocated," and "or a null pointer if the new object could not be allocated."

I really don't see how the standard allows for malloc to simply return NULL without attempting to allocate.



<snip>


>
>
> My own reading of the standards is that an empty free() is allowed in
>
> hosted environments, and it could be useful since the OS will re-claim
>
> the memory on program termination anyway.  (That assumes an
>
> appropriately powerful OS, of course.)
>
>

Specifically what parts of the standard do you see as allowing free() to be empty?
(In a hosted environment with fully functioning malloc() of course.)

If free() is allowed to be empty, doesn't that sort of defeat the whole purpose of describing free() as deallocating memory? If all that was meant was that the program must free all allocated memory on exit then that's what it would have said.

Furthermore, the standard describes free() as making the space pointed to made available for further allocation. Considering the purpose and stated functionality of free, that further allocation should include further allocation by the same program that just freed it.

If free() is empty, then not only does it not free the memory, it is program termination which frees the memory -- not free().

Thanks,


~Jesse

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

#41596

On Mon, 10 Mar 2014 20:51:23 -0700 (PDT), partremmaps@gmail.com wrote:

>On Monday, March 10, 2014 2:20:37 AM UTC-7, David Brown wrote:
>> On 10/03/14 06:37, partremmaps@gmail.com wrote:
>>
>> > On Sunday, March 9, 2014 4:47:12 PM UTC-7, David Brown wrote:
>>
>> >> On 09/03/14 07:55, Kaz Kylheku wrote:
>>
>> >>
>>
>> >>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com>
>>
>> >>> wrote:
>>
>> >>
>>
>> >>>> According to the ANSI C Standard, may free() be an empty
>>
>> >>>> function?
>>
>> >>
>>
>> >
>>
>> >
>
><snip>
>
>>
>>
>> > And indeed, if I understand correctly, in a freestanding environment,
>>
>> > it appears that the standard allows library facilities to be
>>
>> > implementation defined - which would allow for free() to be empty.
>>
>>
>>
>> Yes.  I think there are some restrictions about what the library
>>
>> facilities should do, even in a freestanding environment - but you don't
>>
>> need to implement everything.  In particular, a freestanding
>>
>> implementation does not have to include <stdlib.h>.
>>
>>
>>
>> As far as I read the wording in the C11 standards, a conforming hosted
>>
>> implementation /could/ have malloc() always return 0, and free() be empty.
>>
>
>
>Could you explain which part of C11 would allow malloc() to always return 0 and free() to be empty?
>
>
>I see in the standard:
>
>5.1.2.2 [Hosted environment]
>
>1   A hosted environment need not be provided, but shall conform to the following
>    specifications if present.
>
>then the description of malloc() and free() are below that at 7.22.3 [Memory management functions].
>
>
>Doesn't that look like a hosted environment shall conform if present?
>
>(At first when I read 5.1.2.2, I thought it meant that the following functions were optional in a hosted environment, but that any function present must conform. However, it really looks like the wording says that if a hosted environment is provided, it shall conform to all of the following specifications.)
>
>And the description of malloc() and friends clearly all describe a general effort to allocate, and "7.22.3 [Memory management functions]" says "The pointer returned if the allocation succeeds is suitably aligned so that it may be ...."
>
>Notice "if the allocation succeeds." One cannot have the chance to succeed if they do not attempt, and simply returning NULL is not attempting anything.
>
>Also, realloc uses both the phrases "If memory for the new object cannot be allocated," and "or a null pointer if the new object could not be allocated."
>
>I really don't see how the standard allows for malloc to simply return NULL without attempting to allocate.


So if a loaded program took exactly the available memory on some
implementation, and left no room to malloc() anything, the
implementation becomes non-conforming?

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

#41605

On 11/03/14 04:51, partremmaps@gmail.com wrote:
> On Monday, March 10, 2014 2:20:37 AM UTC-7, David Brown wrote:
>> On 10/03/14 06:37, partremmaps@gmail.com wrote:
>> 
>>> On Sunday, March 9, 2014 4:47:12 PM UTC-7, David Brown wrote:
>> 
>>>> On 09/03/14 07:55, Kaz Kylheku wrote:
>> 
>>>> 
>> 
>>>>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com>
>> 
>>>>> wrote:
>> 
>>>> 
>> 
>>>>>> According to the ANSI C Standard, may free() be an empty
>> 
>>>>>> function?
>> 
>>>> 
>> 
>>> 
>> 
>>> 
> 
> <snip>
> 
>> 
>> 
>>> And indeed, if I understand correctly, in a freestanding
>>> environment,
>> 
>>> it appears that the standard allows library facilities to be
>> 
>>> implementation defined - which would allow for free() to be
>>> empty.
>> 
>> 
>> 
>> Yes.  I think there are some restrictions about what the library
>> 
>> facilities should do, even in a freestanding environment - but you
>> don't
>> 
>> need to implement everything.  In particular, a freestanding
>> 
>> implementation does not have to include <stdlib.h>.
>> 
>> 
>> 
>> As far as I read the wording in the C11 standards, a conforming
>> hosted
>> 
>> implementation /could/ have malloc() always return 0, and free() be
>> empty.
>> 
> 
> 
> Could you explain which part of C11 would allow malloc() to always
> return 0 and free() to be empty?
> 
> 
> I see in the standard:
> 
> 5.1.2.2 [Hosted environment]
> 
> 1   A hosted environment need not be provided, but shall conform to
> the following specifications if present.
> 
> then the description of malloc() and free() are below that at 7.22.3
> [Memory management functions].
> 
> 
> Doesn't that look like a hosted environment shall conform if
> present?
> 
> (At first when I read 5.1.2.2, I thought it meant that the following
> functions were optional in a hosted environment, but that any
> function present must conform. However, it really looks like the
> wording says that if a hosted environment is provided, it shall
> conform to all of the following specifications.)
> 
> And the description of malloc() and friends clearly all describe a
> general effort to allocate, and "7.22.3 [Memory management
> functions]" says "The pointer returned if the allocation succeeds is
> suitably aligned so that it may be ...."
> 
> Notice "if the allocation succeeds." One cannot have the chance to
> succeed if they do not attempt, and simply returning NULL is not
> attempting anything.
> 
> Also, realloc uses both the phrases "If memory for the new object
> cannot be allocated," and "or a null pointer if the new object could
> not be allocated."
> 
> I really don't see how the standard allows for malloc to simply
> return NULL without attempting to allocate.
> 
> 

Under 7.22.3.4:

"The malloc function returns either a null pointer or a pointer to the
allocated space."


I believe that this can be interpreted as allowing malloc() to return a
null pointer for every invocation.

Of course, such an implementation would be useless, and a toolchain that
had such an implementation would be unpopular.  And I don't think the
standards document intended such an "implementation" to be considered
conforming - but I think the language of the standard allows it.


It is also worth noting that there is no way (with just the
standard-required library) for a program to distinguish between an
"always null" malloc() and a real malloc that cannot allocate the memory
that was asked for.  Similarly, there is no way for a program to
distinguish between an empty free() and one that does useful work.

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

#41636

On Tuesday, March 11, 2014 4:52:39 AM UTC-7, David Brown wrote:

<snip>


> 
> Under 7.22.3.4:
> 
> 
> 
> "The malloc function returns either a null pointer or a pointer to the
> 
> allocated space."
> 
> 
> 
> 
> 
> I believe that this can be interpreted as allowing malloc() to return a
> 
> null pointer for every invocation.
> 


If that were the whole story, then I would completely agree. All it says is that it does one or the other - a pointer to allocated space or NULL.

However, it is important to note that not every paragraph provides all supporting context for itself. Most paragraph's rely on intention and context from previous paragraphs.

For example, in 7.22.3 [Memory management functions] there is general information that provides context to all of the memory management functions.
It clearly uses the phrase "The pointer returned if the allocation succeeds is..." and "If the space cannot be allocated, a null pointer is returned."

One cannot succeed with out attempting. And notice the very explicit sentence "If the space cannot be allocated, a null pointer is returned."

Furthermore, [The realloc function] specifically uses the phrase "... or a null pointer if the new object could not be allocated."

Now technically, the section specific to malloc() does not specify under what circumstances malloc() is to return NULL or a valid pointer to space.

Again, technically speaking, the standard says that if the space cannot be allocated, then it returns NULL. However, you could say that it doesn't say that realloc can't also return NULL on success.

Now we have to realize that any two or three words taken out of context from a massive document can be made to say just about anything one wants, including claims which are completely contrary to the purpose and meaning of that document.

When we read the standard's section on malloc(), we must also read the standard's section on Memory managed functions. 

Any construing of the standard in a way that contradicts the obvious intent and wording seems improper to me.






> 
> 
> Of course, such an implementation would be useless, and a toolchain that
> 
> had such an implementation would be unpopular.  And I don't think the
> 
> standards document intended such an "implementation" to be considered
> 
> conforming - but I think the language of the standard allows it.
> 
> 

So the authors of the standards document failed to make themselves clear?

To me it looks more like the idea that the "language that allows" free to be no-op is actually missing language that doesn't prevent it.

100% of the language that IS there completely describes free() as performing the described act of freeing memory. 

What would the standard have to say? Currently it says that free frees memory. Do they need to add a note to every sentence that says "Note: This means what it says. Free actually must free memory to be compliant."?



> 
> 
> 
> It is also worth noting that there is no way (with just the
> 
> standard-required library) for a program to distinguish between an
> 
> "always null" malloc() and a real malloc that cannot allocate the memory
> 
> that was asked for.  Similarly, there is no way for a program to
> 
> distinguish between an empty free() and one that does useful work.


I see noplace in the standard where a requested action can be skipped just because the result of that cannot be tested from within the program.

The whole point of optimization is that the program still do what it was written to do according to the functions in the standard.

And from the context standard's description of malloc() and free() is that it allows memory to be allocated and freed then reallocated again.



Am I thoroughly confused? Do I not understand the standard's intention or purpose? What am I lacking?


Thank you very much,

~Jesse

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

#41642

On 12/03/14 08:09, partremmaps@gmail.com wrote:
> On Tuesday, March 11, 2014 4:52:39 AM UTC-7, David Brown wrote:
> 
<snip>

> 
> I see noplace in the standard where a requested action can be skipped
> just because the result of that cannot be tested from within the
> program.
> 

The action of the program is determined by its observable results - if
you cannot confirm that the malloc() implementation is doing something
non-conforming, then you cannot claim that it /is/ non-conforming.

> The whole point of optimization is that the program still do what it
> was written to do according to the functions in the standard.

True, but not relevant.

> 
> And from the context standard's description of malloc() and free() is
> that it allows memory to be allocated and freed then reallocated
> again.
> 

That is the intention - and any C library will implement it this way if
people are going to use it (except perhaps for very special cases).  I
just don't think the wording of the C standard actually requires this
behaviour in order to be conforming.

> 
> 
> Am I thoroughly confused? Do I not understand the standard's
> intention or purpose? What am I lacking?
> 

I don't know whether you are confused or not - but if you have to ask
the question, then I guess you are!

However, I cannot say here that /I/ am right and /you/ are wrong.  This
is just my reading of words of the standard - it has no more authority
than /your/ reading (and certainly less authority than the opinions of
others in this group who have been "language lawyers" for decades).  So
you must feel entirely free to reject my opinion here if you don't agree
with it.  I am just trying to give you ideas based to what I hope was a
hypothetical question.

> 
> Thank you very much,
> 
> ~Jesse
> 

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

#41538

On 2014-03-09, David Brown <david.brown@hesbynett.no> wrote:
> On 09/03/14 07:55, Kaz Kylheku wrote:
>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>>> According to the ANSI C Standard, may free() be an empty function?
>>
>> Of course, this is an empty function:
>>
>>    void free(void *ptr) { }
>>
>> But just to be sure, that is what you mean, right?
>>
>> I believe the answer is yes.
>>
>>> A couple of people who are in the daily habit of giving C advice on IRC told
>>> me that even in these implementations and situations, free() may be an empty
>>> function and do nothing and still be standards compliant.
>>
>> This is correct. To require free to actually liberate memory would mean that
>> an implementation cannot turn free into a no-op and provide garbage collection.
>>
>> However, if an implementation doesn't provide garbage collection, and its free
>> function does nothing, that will obviously cause memory leaks in
>> C programs, and big, runaway memory leaks in some kinds of C programs.
>>
>> This would simply count as a low quality implementation.
>>
>
> There are (at least) two types of program for which an empty free() and 
> no garbage collection would be perfectly acceptable.  The first is 
> programs that don't allocate heap memory at all - you can do a lot 
> without it.  In the world of small-system embedded programming, malloc() 
> and free() are rare, and are often banned entirely by coding standards. 

Sure; so if you don't actually call free, you don't care if it's empty, or if
it calls abort(), ...

>   The second would be programs that don't need much re-use of memory, 
> and run under an OS - they can simply keep all their memory until the 
> program ends and the OS frees it.

And this category can even have bugs fixed in it if free is replaced by a
no-op.

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

#41552

On Sun, 09 Mar 2014 06:55:27 +0000, Kaz Kylheku wrote:
> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>> According to the ANSI C Standard, may free() be an empty function?
> 
> Of course, this is an empty function:
> 
>   void free(void *ptr) { }
> 
> But just to be sure, that is what you mean, right?
> 
> I believe the answer is yes.
> 
>> A couple of people who are in the daily habit of giving C advice on
>> IRC told me that even in these implementations and situations, free()
>> may be an empty function and do nothing and still be standards
>> compliant.
> 
> This is correct. To require free to actually liberate memory would
> mean that an implementation cannot turn free into a no-op and provide
> garbage collection.

Unfortunately, at any point during the execution of a C program it
is, in general, undecidable whether or not any region of memory is
"unreferenced"[1].  This implies that no conforming C implementation
can provide any sort of useful garbage collection for malloc.  The
garbage collectors for C necessarily require the programmer to not
do various silly things with pointers (such as encrypting them, or
receiving them as input from the user) that are technically allowed
by the language.

[1] "Unreferenced" here means the program cannot construct a valid
    pointer to that memory by any sequence of well-defined operations.

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

#41505

On Saturday, March 8, 2014 10:55:27 PM UTC-8, Kaz Kylheku wrote:
> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>
> > According to the ANSI C Standard, may free() be an empty function?
>
>
>
> Of course, this is an empty function:
>
>
>
>   void free(void *ptr) { }
>
>
>
> But just to be sure, that is what you mean, right?
>
>


That is exactly what I mean.


>
> I believe the answer is yes.
>
>
>
> > A couple of people who are in the daily habit of giving C advice on IRC told
>
> > me that even in these implementations and situations, free() may be an empty
>
> > function and do nothing and still be standards compliant.
>
>
>
> This is correct. To require free to actually liberate memory would mean that
>
> an implementation cannot turn free into a no-op and provide garbage collection.
>



The standard does make the following statements in the following order:
(Reading from SO/IEC 9899:TC3 Committee Draft September 7, 2007 WG14/N1256, http://www.iso-9899.info/n1256.html)

5.1.2.2: A hosted environment need not be provided, but shall conform to the following specifications if present. (See Hosted environment)

(A hosted environment is one where there is an operating system which benefits the C program, as apposed to a Freestanding Environment where there is no operating system that benefits the C program -- like an embedded system. (See Execution environments.))
(Freestanding environments are allowed much more deviation from the standard as compared to hosted environments.)

5.1.2.3p2: ... At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be omplete and no side effects of subsequent evaluations shall have taken place.

7.20.3: The lifetime of an allocated object extends from the allocation until the deallocation. (See Memory management functions)

7.20.3.2: The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. (See The free function)

I am talking only about "Hosted environments" here - those with an operating system benefiting the C program in question.

So it looks to me like while no implementation must support free(), free() must conform to the standard if free() is present in the implementation. And obviously free would be present if you had void free(void *ptr) { } .

The standard says that a lifetime of an allocated object extends from allocation until deallocation, and it says that free deallocates, making it available for further allocation.

And as a reminder, I am talking about an implementation and platform that fully supports malloc, calloc, realloc, and has a free() function.

Thus, it looks to me like, since the lifetime must end at deallocation, and free() is to deallocate, then free cannot be "void free(void *ptr) { }."

You could say "Well, what if they use a garbage collector that automatically frees the allocated space when the empty function free() is called..."
That would be fine, except that the standard specifies that the allocated object lives up until the point of deallocation and no more and no less, and it says that free deallocates -- so if free() were an empty function, then the GC would have no way of knowing when free() had been called.

Furthermore, the standard does clearly describe free as deallocating and liberating memory to make it available for further allocation.

The concept of a garbage collector+empty free() seems a bit risky since the standard also requires side effects to be completed before the next sequence point, so if there was a garbage collector, it would have to free the memory while the void free() was running, otherwise the side effect required by the call to free would happen outside of its sequence period and thus not be compliant.

But are you saying then that free() may be empty as long as the implementation comes up with some other method to free the requested space during the time that free() is executing?

Then we'd have an empty function which changed how the program worked depending on whether the call to the empty function was present or not...!



> However, if an implementation doesn't provide garbage collection, and its free
> function does nothing, that will obviously cause memory leaks in
> C programs, and big, runaway memory leaks in some kinds of C programs.


> This would simply count as a low quality implementation.



But if the implementation provided neither a functioning free() nor some other trick to fully emulate a functioning free, would not that then fail to comply with the standard where it says "The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation?"

I agree that it would be a low quality implementation but I cannot see how it would still be compliant when it failed to conform to the clear description of functionality in the standard: http://www.iso-9899.info/n1256.html#7.20.3.2


Thank you very much. I'm trying hard to understand.

~Jesse

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

#41509

partremmaps@gmail.com writes:

> On Saturday, March 8, 2014 10:55:27 PM UTC-8, Kaz Kylheku wrote:
>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>>
>> > According to the ANSI C Standard, may free() be an empty function?
<snip>
> The standard says that a lifetime of an allocated object extends from
> allocation until deallocation, and it says that free deallocates,
> making it available for further allocation.
<snip>
> Thus, it looks to me like, since the lifetime must end at
> deallocation, and free() is to deallocate, then free cannot be "void
> free(void *ptr) { }."

Strictly speaking, I think the lifetime issue is a red herring.  The
lifetime of an object is a guarantee of when it is usable, not a
guarantee that it is unavailable subsequently.  For example, a C
implementation that used static allocation for automatic variables where
that is possible (basically in functions that can't be called while they
are active) would be conforming.  Also, in code like this:

   void f(void)
   {
      ....
      if (...) {
          int i;
          ...
      }
      /* Must i really be "gone" here? */
      ...
   }

no one would claim that an implementation that did not actually make the
object referred by 'i' invalid after the 'if' is non-conforming.  You
can't ever tell when an object's lifetime ends, so if the standard
merely said that free ends the lifetime of the allocated space, there
would be nothing to debate.

Thus, in my view, your question all revolves around the extra phrase
"made available for further allocation".  Must this happen immediately,
or could the storage be made available some while later?  Could it be
made available right at the end of the program's execution (when it's
too late for the program itself)?

This is the kind of question that I have sworn off getting involved
with, so I won't offer an opinion.  But you have to ask yourself if it
really matters.  If a C library offered a free function that did not
make some reasonable best-effort to make freed storage available, I
would try to avoid it, regardless of whether it conforms or not.

<snip>
-- 
Ben.

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

#41511

In article <0.61928655fbd082e51693.20140309123928GMT.87d2hv35rz.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
...
>This is the kind of question that I have sworn off getting involved
>with, so I won't offer an opinion.  But you have to ask yourself if it
>really matters.  If a C library offered a free function that did not
>make some reasonable best-effort to make freed storage available, I
>would try to avoid it, regardless of whether it conforms or not.

Yeah, but if you've been around for this newsgroup for more than a week or
so, you'd know that nobody cares about QOI here.  Conformance to the
almighty standard is the be-all and end-all of our existence.  In the
religion of CLC, conformance uber alles, and all those other things, like
performance, stability, usability - well, you can just go discuss them
somewhere else.

Note that the above sounds like sarcasm, etc, but it is just the truth.

-- 
"The God of the Old Testament is arguably the most unpleasant character
in all fiction: jealous and proud of it; a petty, unjust, unforgiving
control-freak; a vindictive, bloodthirsty ethnic cleanser; a misogynistic,
homophobic, racist, infanticidal, genocidal, filicidal, pestilential,
megalomaniacal, sadomasochistic, capriciously malevolent bully."

 - Richard Dawkins, The God Delusion -

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

#41532

On Sunday, March 9, 2014 5:39:28 AM UTC-7, Ben Bacarisse wrote:
> partremmaps@gmail.com writes:
>
>
>
> > On Saturday, March 8, 2014 10:55:27 PM UTC-8, Kaz Kylheku wrote:
>
> >> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
>
> >>
>
> >> > According to the ANSI C Standard, may free() be an empty function?
>
> <snip>
>
> > The standard says that a lifetime of an allocated object extends from
>
> > allocation until deallocation, and it says that free deallocates,
>
> > making it available for further allocation.
>
> <snip>
>
> > Thus, it looks to me like, since the lifetime must end at
>
> > deallocation, and free() is to deallocate, then free cannot be "void
>
> > free(void *ptr) { }."
>
>
>
> Strictly speaking, I think the lifetime issue is a red herring.  The
>
> lifetime of an object is a guarantee of when it is usable, not a
>
> guarantee that it is unavailable subsequently.  For example, a C
>
> implementation that used static allocation for automatic variables where
>
> that is possible (basically in functions that can't be called while they
>
> are active) would be conforming.  Also, in code like this:
>
>
>
>    void f(void)
>
>    {
>
>       ....
>
>       if (...) {
>
>           int i;
>
>           ...
>
>       }
>
>       /* Must i really be "gone" here? */
>
>       ...
>
>    }
>


Of course, the question was about space pointed to by a pointer and freed by free(), which i isn't in this case.


>
>
> no one would claim that an implementation that did not actually make the
>
> object referred by 'i' invalid after the 'if' is non-conforming.  You
>
> can't ever tell when an object's lifetime ends, so if the standard
>
> merely said that free ends the lifetime of the allocated space, there
>
> would be nothing to debate.
>

Except perhaps the standard does spell out that free is to deallocate. In your example above, I agree, the space used by i could live outside its scope for some length of time.

But since the standard does say that free deallocates, and since it does not have any comment that the action is allowed later, it causes me to question the correctness of assuming a "May be done later" clause when such a clause is no where to be seen (at least that I've found,) especially considering C's strong sequence point rules.

There is a very strong wording for free that it is to free the space for further allocation. That can't be ignored.

>
>
> Thus, in my view, your question all revolves around the extra phrase
>
> "made available for further allocation".  Must this happen immediately,
>
> or could the storage be made available some while later?  Could it be
>
> made available right at the end of the program's execution (when it's
>
> too late for the program itself)?
>


Well, one thing that bothers me is an attempt to render portions of the standard to mean nothing.
If the standard was meant to say simply that memory resources must be freed to the operating system upon program termination, then it would have said that, rather than describing free().

<snip>

>
> Ben.

Thanks!

~Jesse

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

#41546

On 3/10/2014 12:28 AM, partremmaps@gmail.com wrote:
> On Sunday, March 9, 2014 5:39:28 AM UTC-7, Ben Bacarisse wrote:
>> partremmaps@gmail.com writes:
>>> On Saturday, March 8, 2014 10:55:27 PM UTC-8, Kaz Kylheku wrote:
>>>> On 2014-03-09, partremmaps@gmail.com <partremmaps@gmail.com> wrote:
[snip]
>>> Thus, it looks to me like, since the lifetime must end at
>>> deallocation, and free() is to deallocate, then free cannot be "void
>>> free(void *ptr) { }."

>> Strictly speaking, I think the lifetime issue is a red herring.  The
>> lifetime of an object is a guarantee of when it is usable, not a
>> guarantee that it is unavailable subsequently.  For example, a C
>> implementation that used static allocation for automatic variables where
>> that is possible (basically in functions that can't be called while they
>> are active) would be conforming.  Also, in code like this:

>>     void f(void)
>>     {
>>        ....
>>        if (...) {
>>            int i;
>>            ...
>>        }
>>        /* Must i really be "gone" here? */
>>        ...
>>     }

> Of course, the question was about space pointed to by a pointer and freed by free(), which i isn't in this case.

Yes, but it does show a hole in the argument that starts with "since 
lifetime must end be deallocation, ...". Lifetime has little to do with 
your question.

>> no one would claim that an implementation that did not actually make the
>> object referred by 'i' invalid after the 'if' is non-conforming.  You
>> can't ever tell when an object's lifetime ends, so if the standard
>> merely said that free ends the lifetime of the allocated space, there
>> would be nothing to debate.

> Except perhaps the standard does spell out that free is to deallocate. In your example above, I agree, the space used by i could live outside its scope for some length of time.
> But since the standard does say that free deallocates, and since it does not have any comment that the action is allowed later, it causes me to question the correctness of assuming a "May be done later" clause when such a clause is no where to be seen (at least that I've found,) especially considering C's strong sequence point rules.
> There is a very strong wording for free that it is to free the space for further allocation. That can't be ignored.

But is the wording strong enough to require that a subsequent malloc(1), 
or similar, actually succeed? If it's not, then the "as-if" rule would 
apply, and you can have free() do nothing.

[snip]

Martin Shobe

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

#41592

On Monday, March 10, 2014 5:27:53 AM UTC-7, Martin Shobe wrote:
> On 3/10/2014 12:28 AM, partremmaps@gmail.com wrote:
> 

<snip>

> > There is a very strong wording for free that it is to free the space for further allocation. That can't be ignored.
> 
> 
> 
> But is the wording strong enough to require that a subsequent malloc(1), 
> 
> or similar, actually succeed? If it's not, then the "as-if" rule would 
> 
> apply, and you can have free() do nothing.
> 
> 
> 
> [snip]
> 
> 
> 
> Martin Shobe


Could you expound on the "as-if" rule (or reference standard section)?


Thanks,

~Jesse

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

#41607

On 3/10/2014 10:55 PM, partremmaps@gmail.com wrote:
> On Monday, March 10, 2014 5:27:53 AM UTC-7, Martin Shobe wrote:
>> On 3/10/2014 12:28 AM, partremmaps@gmail.com wrote:
>>
>
> <snip>
>
>>> There is a very strong wording for free that it is to free the space for further allocation. That can't be ignored.
>>
>>
>>
>> But is the wording strong enough to require that a subsequent malloc(1),
>>
>> or similar, actually succeed? If it's not, then the "as-if" rule would
>>
>> apply, and you can have free() do nothing.
>>
>>
>>
>> [snip]
>>
>>
>>
>> Martin Shobe
>
>
> Could you expound on the "as-if" rule (or reference standard section)?

Take a look at 5.1.2.3.1, 5.1.2.3.4, and 5.1.2.3.6 in N1570. Part of 
5.1.2.3.4 says that side-effects can be omitted if they aren't needed. 
5.1.2.3.6 tells you what's needed.

Martin Shobe

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web