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

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

Competing criteria

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

Contents

  Competing criteria nroberts <roberts.noah@gmail.com> - 2011-10-21 14:49 -0700
    Re: Competing criteria Seebs <usenet-nospam@seebs.net> - 2011-10-21 22:16 +0000
      Re: Competing criteria Roberto Waltman <usenet@rwaltman.com> - 2011-10-22 14:06 -0400
        Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 16:47 -0400
          Re: Competing criteria Ark <akhasin@macroexpressions.com> - 2011-10-22 17:33 -0400
            Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 18:20 -0400
              Re: Competing criteria Ark <akhasin@macroexpressions.com> - 2011-10-22 21:29 -0400
              Re: Competing criteria "io_x" <a@b.c.invalid> - 2011-10-23 10:32 +0200
                Re: Competing criteria "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-10-23 11:06 +0200
                  Re: Competing criteria Willem <willem@toad.stack.nl> - 2011-10-23 09:09 +0000
                    Re: Competing criteria "io_x" <a@b.c.invalid> - 2011-10-23 12:04 +0200
                      Re: Competing criteria "io_x" <a@b.c.invalid> - 2011-10-27 08:44 +0200
                  Re: Competing criteria Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-23 05:01 -0700
              Re: Competing criteria Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-23 08:29 -0400
                Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-23 09:15 -0400
                  Re: Competing criteria Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-23 06:24 -0700
                    Re: Competing criteria Markus Wichmann <nullplan@gmx.net> - 2011-10-24 22:39 +0200
                      Re: Competing criteria Keith Thompson <kst-u@mib.org> - 2011-10-24 17:10 -0700
                      Re: Competing criteria Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-25 13:09 +0300
                      Re: Competing criteria Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-26 00:23 -0700
        Re: Competing criteria Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-23 00:02 +0300
        Re: Competing criteria Seebs <usenet-nospam@seebs.net> - 2011-10-24 20:10 +0000
          Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-24 19:36 -0400
          Re: Competing criteria nroberts <roberts.noah@gmail.com> - 2011-10-25 10:07 -0700
            Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-25 16:51 -0400
    Re: Competing criteria John Gordon <gordon@panix.com> - 2011-10-21 22:37 +0000
    Re: Competing criteria Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-21 20:42 -0400

Page 1 of 2  [1] 2  Next page →

#11948 — Competing criteria

I'm having trouble figuring out how to get seemingly mutually
exclusive goals and criteria to work together.

The technical lead/architect for the project I'm on is from an
embedded background and therefore doesn't like heap allocation.  I
don't know if this is a real issue in that domain, having never done
it myself, but that's what he's told me when complaining about my use
of allocated buffers and such.  Factory like functions also seem to
upset him.  I'm not so sure about function pointers, but every time
I've made something that wasn't of the direct call, stack or global
variable kind of design he's kind of freaked out on me.

At the same time he wants me to write reusable code and has previously
wanted me to make unit tests, though now I'm not even sure about that
since he won't even look at them.

I'm getting kind of pissed off to tell the truth, but I still want to
try.

I'm coming into a project where the best solution seems to be a
multithreaded service.  It's basically a proxy for a soap server
created by a third party that we're making generic and less soapy in
order for our various products to use it.  Some of the calls can take
a long time and writing it multithreaded allows us to use the gsoap
library without having to muck about to use it asynchronously as it
doesn't really support such use.

I created a prototype for this service in C++ using all the
allocation, RAII, polymorphism, etc...so I could get a clear picture
of the problem.  Now I need to convert the design into C (I'm fairly
certain he's going to tell me to).  Normally this would be fairly
easy, replace exception processing with error codes, rewrite std::list
and such for all the types I want to hold or to use void*...use opaque
types and createXXX() functions...  I'm not doing anything
particularly incredible with the C++, it could almost as easily be C.
This kind of stuff doesn't fly here though.

I can create circular buffer stacks to handle things like my thread
pools instead of allocating stack nodes.  I can just declare my opaque
types openly and have initXXX() functions. Etc...I think this kind of
thing would make the guy happy but I don't see how to do that while
also meeting another goal he's said I need to meet: make this thing so
that it's a generic architecture for any soap connecting proxy.  I
can't think of how to do such circular buffer stacks for specific
types (because I can't allocate) and still write them in a way that
can be used in different ways.

How does one make reusable components without at least some generics
and heap allocations?  When everything has to be a direct call, how do
you allow clients to override behavior?  What are some idioms,
patterns, whatever that I can use to at least make some attempt at
getting both of these ideals to work together?

[toc] | [next] | [standalone]

#11949

On 2011-10-21, nroberts <roberts.noah@gmail.com> wrote:
> I'm having trouble figuring out how to get seemingly mutually
> exclusive goals and criteria to work together.

Heh.

> The technical lead/architect for the project I'm on is from an
> embedded background and therefore doesn't like heap allocation.

This is probably an obsolete view, but who knows?  Anyway, the canonical
solution to "not heap allocation" is to define a reasonable maximum count
of simultaneous objects, statically allocate them, and then basically
write your own mini-allocator that keeps track of which ones you're using.

This, you will note, is probably stupid.

Note that either way, it is very important that you handle lack of
resources gracefully.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#11958

Seebs  wrote:
>  the canonical
>solution to "not heap allocation" is to define a reasonable maximum count
>of simultaneous objects, statically allocate them, and then basically
>write your own mini-allocator that keeps track of which ones you're using.
>This, you will note, is probably stupid.

Far from being stupid, that is the only way you can guarantee that
memory allocation will not fail due to memory fragmentation, in
systems with limited resources, no virtual memory and that must run
24/7.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

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

#11967

On 10/22/11 2:06 PM, Roberto Waltman wrote:
> Seebs  wrote:
>>   the canonical
>> solution to "not heap allocation" is to define a reasonable maximum count
>> of simultaneous objects, statically allocate them, and then basically
>> write your own mini-allocator that keeps track of which ones you're using.
>> This, you will note, is probably stupid.
>
> Far from being stupid, that is the only way you can guarantee that
> memory allocation will not fail due to memory fragmentation, in
> systems with limited resources, no virtual memory and that must run
> 24/7.
> --
> Roberto Waltman
>

As I mentioned last night, that isn't totally true. It can be generally 
considered safe to do heap allocation during initial startup (for 
buffers that will then live forever, perhaps handed out and collected 
with allocation functions.

While in principle, it would normally be possible to rewrite all the 
code that uses the heap to use statically allocated buffers, this often 
forces details of implementation to leak out, especially of objects that 
need internal buffers that can't be fixed in size over all uses.

It can also be acceptable to heap allocations for non-critical 
operations that are allowed to fail or be postponed for arbitrary 
periods of time. These allocations should be for a limited period of 
time, and it is desirable for there to be occasional times when most of 
these are all released at the same time to let the heap defragment.

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

#11969

On 10/22/2011 4:47 PM, Richard Damon wrote:
> On 10/22/11 2:06 PM, Roberto Waltman wrote:
>> Seebs wrote:
>>> the canonical
>>> solution to "not heap allocation" is to define a reasonable maximum
>>> count
>>> of simultaneous objects, statically allocate them, and then basically
>>> write your own mini-allocator that keeps track of which ones you're
>>> using.
>>> This, you will note, is probably stupid.
>>
>> Far from being stupid, that is the only way you can guarantee that
>> memory allocation will not fail due to memory fragmentation, in
>> systems with limited resources, no virtual memory and that must run
>> 24/7.
>> --
>> Roberto Waltman
>>
>
> As I mentioned last night, that isn't totally true. It can be generally
> considered safe to do heap allocation during initial startup (for
> buffers that will then live forever, perhaps handed out and collected
> with allocation functions.
>
> While in principle, it would normally be possible to rewrite all the
> code that uses the heap to use statically allocated buffers, this often
> forces details of implementation to leak out, especially of objects that
> need internal buffers that can't be fixed in size over all uses.
>
> It can also be acceptable to heap allocations for non-critical
> operations that are allowed to fail or be postponed for arbitrary
> periods of time. These allocations should be for a limited period of
> time, and it is desirable for there to be occasional times when most of
> these are all released at the same time to let the heap defragment.

IOW, malloc() can be (made) more or less benign but free() is totally 
unacceptable.
Which is not totally true either.
If memory serves me right, there are allocation algorithms that 
guarantee to succeed if the contiguous memory pool is "only" twice as 
large as the max you need at any given time. Of course if you already 
know what this max is, you can probably do better w.r.t. memory resources.
OTOH, for any allocation algorithm there is a pattern of 
allocations/deallocations which would fatally fragment the pool (aka 
heap), in the sense that enough total memory is available but it is not 
contiguous
- Ark

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

#11971

On 10/22/11 5:33 PM, Ark wrote:
>
>
> On 10/22/2011 4:47 PM, Richard Damon wrote:

>>
>> As I mentioned last night, that isn't totally true. It can be generally
>> considered safe to do heap allocation during initial startup (for
>> buffers that will then live forever, perhaps handed out and collected
>> with allocation functions.
>>
>> While in principle, it would normally be possible to rewrite all the
>> code that uses the heap to use statically allocated buffers, this often
>> forces details of implementation to leak out, especially of objects that
>> need internal buffers that can't be fixed in size over all uses.
>>
>> It can also be acceptable to heap allocations for non-critical
>> operations that are allowed to fail or be postponed for arbitrary
>> periods of time. These allocations should be for a limited period of
>> time, and it is desirable for there to be occasional times when most of
>> these are all released at the same time to let the heap defragment.
>
> IOW, malloc() can be (made) more or less benign but free() is totally
> unacceptable.
> Which is not totally true either.
> If memory serves me right, there are allocation algorithms that
> guarantee to succeed if the contiguous memory pool is "only" twice as
> large as the max you need at any given time. Of course if you already
> know what this max is, you can probably do better w.r.t. memory resources.
> OTOH, for any allocation algorithm there is a pattern of
> allocations/deallocations which would fatally fragment the pool (aka
> heap), in the sense that enough total memory is available but it is not
> contiguous
> - Ark

The rule I always use is a task is not allowed to fail, then it can't 
call on anything that might fail. malloc, in general, has the 
possibility to fail so needs to be avoided in tasks that can not fail.

free() is actually always safe, as free can never fail, and can never 
cause another malloc to fail. What can get you in trouble is to free a 
resource that you will need in the future, as after you free a memory 
block, you can't be sure you can get it back until every block allocated 
after it is freed too (based on normal heap rules).

While, as you say, there are patterns of allocations and deallocations 
that fragment the heap, the rule that allocations (after the startup 
code) are be of short/finite duration is designed it prevent those bad 
patterns. Also, the goal to have periods of time when you free most of 
the short term usage also minimizes how bad fragmentation gets.

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

#11972

On 10/22/2011 6:20 PM, Richard Damon wrote:
> On 10/22/11 5:33 PM, Ark wrote:
>>
>>
>> On 10/22/2011 4:47 PM, Richard Damon wrote:
>
>>>
>>> As I mentioned last night, that isn't totally true. It can be generally
>>> considered safe to do heap allocation during initial startup (for
>>> buffers that will then live forever, perhaps handed out and collected
>>> with allocation functions.
>>>
>>> While in principle, it would normally be possible to rewrite all the
>>> code that uses the heap to use statically allocated buffers, this often
>>> forces details of implementation to leak out, especially of objects that
>>> need internal buffers that can't be fixed in size over all uses.
>>>
>>> It can also be acceptable to heap allocations for non-critical
>>> operations that are allowed to fail or be postponed for arbitrary
>>> periods of time. These allocations should be for a limited period of
>>> time, and it is desirable for there to be occasional times when most of
>>> these are all released at the same time to let the heap defragment.
>>
>> IOW, malloc() can be (made) more or less benign but free() is totally
>> unacceptable.
>> Which is not totally true either.
>> If memory serves me right, there are allocation algorithms that
>> guarantee to succeed if the contiguous memory pool is "only" twice as
>> large as the max you need at any given time. Of course if you already
>> know what this max is, you can probably do better w.r.t. memory
>> resources.
>> OTOH, for any allocation algorithm there is a pattern of
>> allocations/deallocations which would fatally fragment the pool (aka
>> heap), in the sense that enough total memory is available but it is not
>> contiguous
>> - Ark
>
> The rule I always use is a task is not allowed to fail, then it can't
> call on anything that might fail. malloc, in general, has the
> possibility to fail so needs to be avoided in tasks that can not fail.
>
> free() is actually always safe, as free can never fail, and can never
> cause another malloc to fail. What can get you in trouble is to free a
> resource that you will need in the future, as after you free a memory
> block, you can't be sure you can get it back until every block allocated
> after it is freed too (based on normal heap rules).
>
> While, as you say, there are patterns of allocations and deallocations
> that fragment the heap, the rule that allocations (after the startup
> code) are be of short/finite duration is designed it prevent those bad
> patterns. Also, the goal to have periods of time when you free most of
> the short term usage also minimizes how bad fragmentation gets.

I don't think we disagree on anything.
By "free() is evil" I mean that a pattern of pre-allocating on start-up 
is fine (but doesn't buy you anything if you don't care about keeping 
the types opaque); anything else is risky.
<OT>
I believe the idea of malloc was driven by use cases of non-interactive 
programs that run and end, whether succeeding or failing. I mean, like 
grep. For a program that starts and never ends, be it an embedded 
freestanding program or hosted service/daemon, malloc /interface/ is 
suited exceptionally poorly. An intermediate group is indeterminately 
long interactive programs, like office applications - but they, as we 
know, *are* allowed to fail :)
</OT>
- Ark

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

#11977

"Richard Damon" <news.x.richarddamon@xoxy.net> ha scritto nel messaggio
news:j7vfkc$goj$1@dont-email.me...
> On 10/22/11 5:33 PM, Ark wrote:
> The rule I always use is a task is not allowed to fail, then it can't call on
> anything that might fail. malloc, in general, has the possibility to fail so
> needs to be avoided in tasks that can not fail.
>
> free() is actually always safe, as free can never fail, and can never cause
> another malloc to fail.

i think some free() function can fail in the wrost way

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

#11979

io_x wrote:
> "Richard Damon" <news.x.richarddamon@xoxy.net> ha scritto nel
> messaggio news:j7vfkc$goj$1@dont-email.me...
>> On 10/22/11 5:33 PM, Ark wrote:
>> The rule I always use is a task is not allowed to fail, then it
>> can't call on anything that might fail. malloc, in general, has the
>> possibility to fail so needs to be avoided in tasks that can not
>> fail. free() is actually always safe, as free can never fail, and can
>> never cause another malloc to fail.
>
> i think some free() function can fail in the wrost way

Indeed free() can fail if cou give something not NULL which hasn't come from 
malloc(), calloc() or realloc() or had been free()'d already, in which case 
undefined behavoir occurs (and free() doesn't have means to report an error)

From a Linux man-page:
free() frees the memory space pointed to by ptr, which must have been 
returned by a previous call to malloc(), calloc() or realloc(). Otherwise, 
or if free(ptr) has already been called before, undefined behaviour occurs. 
If ptr is NULL, no operation is performed.



Bye, Jojo

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

#11980

Joachim Schmitz wrote:
) io_x wrote:
)> "Richard Damon" <news.x.richarddamon@xoxy.net> ha scritto nel
)> messaggio news:j7vfkc$goj$1@dont-email.me...
)>> On 10/22/11 5:33 PM, Ark wrote:
)>> The rule I always use is a task is not allowed to fail, then it
)>> can't call on anything that might fail. malloc, in general, has the
)>> possibility to fail so needs to be avoided in tasks that can not
)>> fail. free() is actually always safe, as free can never fail, and can
)>> never cause another malloc to fail.
)>
)> i think some free() function can fail in the wrost way
)
) Indeed free() can fail if cou give something not NULL which hasn't come from 
) malloc(), calloc() or realloc() or had been free()'d already, in which case 
) undefined behavoir occurs (and free() doesn't have means to report an error)

IOW: free() can only fail if there is a programming error.
OTOH: malloc() can fail because of external circumstances.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#11983

"Willem" <willem@toad.stack.nl> ha scritto nel messaggio 
news:slrnja7mf6.3gb.willem@toad.stack.nl...
> Joachim Schmitz wrote:
> ) io_x wrote:
> )> "Richard Damon" <news.x.richarddamon@xoxy.net> ha scritto nel
> )> messaggio news:j7vfkc$goj$1@dont-email.me...
> )>> On 10/22/11 5:33 PM, Ark wrote:
> )>> The rule I always use is a task is not allowed to fail, then it
> )>> can't call on anything that might fail. malloc, in general, has the
> )>> possibility to fail so needs to be avoided in tasks that can not
> )>> fail. free() is actually always safe, as free can never fail, and can
> )>> never cause another malloc to fail.
> )>
> )> i think some free() function can fail in the wrost way
> )
> ) Indeed free() can fail if cou give something not NULL which hasn't come from
> ) malloc(), calloc() or realloc() or had been free()'d already, in which case
> ) undefined behavoir occurs (and free() doesn't have means to report an error)
>
> IOW: free() can only fail if there is a programming error.

1) for example programmer free some stack memory address etc

> OTOH: malloc() can fail because of external circumstances.

no, could be for the programming error:
2) malloc can fail when 1 is happen, and programmer write on
the memory returned from malloc in the case the memory
it is the free() one of case 1

>
> SaSW, Willem
> -- 
> Disclaimer: I am in no way responsible for any of the statements
>            made in the above text. For all I know I might be
>            drugged or something..
>            No I'm not paranoid. You all think I'm paranoid, don't you !
> #EOT 

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

#12138

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4ea3e5f6$0$1381$4fafbaef@reader1.news.tin.it...
>
> "Willem" <willem@toad.stack.nl> ha scritto nel messaggio
> news:slrnja7mf6.3gb.willem@toad.stack.nl...
>> Joachim Schmitz wrote:
>> ) io_x wrote:
>> )> "Richard Damon" <news.x.richarddamon@xoxy.net> ha scritto nel
>> )> messaggio news:j7vfkc$goj$1@dont-email.me...
>> )>> On 10/22/11 5:33 PM, Ark wrote:
>> )>> The rule I always use is a task is not allowed to fail, then it
>> )>> can't call on anything that might fail. malloc, in general, has the
>> )>> possibility to fail so needs to be avoided in tasks that can not
>> )>> fail. free() is actually always safe, as free can never fail, and can
>> )>> never cause another malloc to fail.
>> )>
>> )> i think some free() function can fail in the wrost way
>> )
>> ) Indeed free() can fail if cou give something not NULL which hasn't come
>> from
>> ) malloc(), calloc() or realloc() or had been free()'d already, in which case
>> ) undefined behavoir occurs (and free() doesn't have means to report an
>> error)
>>
>> IOW: free() can only fail if there is a programming error.
>
> 1) for example programmer free some stack memory address etc
>
>> OTOH: malloc() can fail because of external circumstances.
>
> no, could be for the programming error:
> 2) malloc can fail when 1 is happen, and programmer write on
> the memory returned from malloc in the case the memory
> it is the free() one of case 1

free() fail here means: free() does one operation
that it has not to do because it is an error

>> SaSW, Willem
>> -- 
>> Disclaimer: I am in no way responsible for any of the statements
>>            made in the above text. For all I know I might be
>>            drugged or something..
>>            No I'm not paranoid. You all think I'm paranoid, don't you !
>> #EOT
>
>

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

#11984

On Oct 23, 10:06 am, "Joachim Schmitz" <nospam.j...@schmitz-
digital.de> wrote:
> io_x wrote:
> > "Richard Damon" <news.x.richardda...@xoxy.net> ha scritto nel
> > messaggionews:j7vfkc$goj$1@dont-email.me...
> >> On 10/22/11 5:33 PM, Ark wrote:
> >> The rule I always use is a task is not allowed to fail, then it
> >> can't call on anything that might fail. malloc, in general, has the
> >> possibility to fail so needs to be avoided in tasks that can not
> >> fail. free() is actually always safe, as free can never fail, and can
> >> never cause another malloc to fail.
>
> > i think some free() function can fail in the wrost way
>
> Indeed free() can fail if cou give something not NULL which hasn't come from
> malloc(), calloc() or realloc() or had been free()'d already, in which case
> undefined behavoir occurs (and free() doesn't have means to report an error)
>
> From a Linux man-page:
> free() frees the memory space pointed to by ptr, which must have been
> returned by a previous call to malloc(), calloc() or realloc(). Otherwise,
> or if free(ptr) has already been called before, undefined behaviour occurs.
> If ptr is NULL, no operation is performed.

I wouldn't call this a failure on free()'s part. Essentially free()'s
pre-condition has been violated. The caller is the failure.

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

#11985

On 10/22/2011 6:20 PM, Richard Damon wrote:
> [...]
> The rule I always use is a task is not allowed to fail, then it can't
> call on anything that might fail. malloc, in general, has the
> possibility to fail so needs to be avoided in tasks that can not fail.

     You may be using "fail" too broadly.  Yes, malloc() can "fail" in
the sense that it reserves no memory.  But malloc() does not then abort
the program or something equally drastic; it returns NULL to inform the
caller of the outcome and allow the caller to take action as appropriate
in the context.  If the caller (and the caller's callers) cannot proceed
without the reserved memory, perhaps the program will then "fail" -- but
this is not an inevitable outcome when malloc() "fails."

     If getenv("FAILURE_OPTION") returns NULL, is that a "failure?"

     If strchr(string, '?') returns NULL, is that a "failure?"

     If fopen("nonsuch.txt", "r") returns NULL, is that a "failure?"

     Depending on the structure and needs of the program, the answers
could be any combination of "Yes," "No," and "It's complicated."  The
same goes for malloc().

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

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

#11988

On 10/23/11 8:29 AM, Eric Sosman wrote:
> On 10/22/2011 6:20 PM, Richard Damon wrote:
>> [...]
>> The rule I always use is a task is not allowed to fail, then it can't
>> call on anything that might fail. malloc, in general, has the
>> possibility to fail so needs to be avoided in tasks that can not fail.
>
> You may be using "fail" too broadly. Yes, malloc() can "fail" in
> the sense that it reserves no memory. But malloc() does not then abort
> the program or something equally drastic; it returns NULL to inform the
> caller of the outcome and allow the caller to take action as appropriate
> in the context. If the caller (and the caller's callers) cannot proceed
> without the reserved memory, perhaps the program will then "fail" -- but
> this is not an inevitable outcome when malloc() "fails."
>
> If getenv("FAILURE_OPTION") returns NULL, is that a "failure?"
>
> If strchr(string, '?') returns NULL, is that a "failure?"
>
> If fopen("nonsuch.txt", "r") returns NULL, is that a "failure?"
>
> Depending on the structure and needs of the program, the answers
> could be any combination of "Yes," "No," and "It's complicated." The
> same goes for malloc().
>

The simple answer is use the same definition of fail in the two places. 
If the task isn't allowed to fail by aborting, but can say "can't do 
it", then it can't call things that abort but can call things like 
malloc which may return a "can't do it" response (as long as you check 
for them and don't assume it gave you the memory). More commonly failure 
is an inability to do the task requested. As you examples show, 
sometimes what that really means is dependent on context.

As most guideline rules, it is stated in the simple, easy to remember 
format, not with all the appended legalese about unusual conditions and 
exemptions. As an example, a task that must complete, might be able to 
call malloc for a buffer, if the task has a suitable alternative that it 
can fall back on if the malloc returns no buffer, for example, maybe it 
has a buffer kept in reserve, that it can use in emergencies, but when 
it falls back on that, it sends out a notice that it may not be able to 
handle any more traffic (allowing future requests to fail).

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

#11989

On Oct 23, 3:15 pm, Richard Damon <news.x.richardda...@xoxy.net>
wrote:
>
> if the task has a suitable alternative that it
> can fall back on if the malloc returns no buffer,
>
People discuss this quite a bit. Technically it's often possible to
use a less memory-hungry algorithm if malloc() fails. However it's
almost never done in real code, because it means programs become much
more difficult to write and to test.
--
Basic algorithms. JPEG compressor/decompressor.
http://www.malcolmmclean.site11.com/www

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

#12054

On 23.10.2011 15:24, Malcolm McLean wrote:
> On Oct 23, 3:15 pm, Richard Damon <news.x.richardda...@xoxy.net>
> wrote:
>>
>> if the task has a suitable alternative that it
>> can fall back on if the malloc returns no buffer,
>>
> People discuss this quite a bit. Technically it's often possible to
> use a less memory-hungry algorithm if malloc() fails. However it's
> almost never done in real code, because it means programs become much
> more difficult to write and to test.

It also means to write more code, some of which is almost never going to
get used... I mean, it would be like writing a program so that it runs
both on systems with an FPU and without: You basically have to write it
twice. It is almost always simpler to just say "Buy an FPU!" or "Buy
more RAM or enlarge the swap file!"

> --

The correct separator would be dash-dash-space-newline, you are missing
the space.

HTH,
Markus

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

#12064

Markus Wichmann <nullplan@gmx.net> writes:
> On 23.10.2011 15:24, Malcolm McLean wrote:
[...]
>> --
>
> The correct separator would be dash-dash-space-newline, you are missing
> the space.

You can thank Google Groups for that.

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

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

#12079

Markus Wichmann <nullplan@gmx.net> writes:
> On 23.10.2011 15:24, Malcolm McLean wrote:
> > On Oct 23, 3:15 pm, Richard Damon <news.x.richardda...@xoxy.net> wrote:
> >> if the task has a suitable alternative that it
> >> can fall back on if the malloc returns no buffer,
> >
> > People discuss this quite a bit. Technically it's often possible to
> > use a less memory-hungry algorithm if malloc() fails. However it's
> > almost never done in real code, because it means programs become much
> > more difficult to write and to test.

Never used? I can point to several places in the linux kernel where it's 
done (and those are just in Nokia's contributions to the kernel, there 
may be many others).

If you need a contiguous block of physical memory for DMA, for example,
then first you ask for what's ideal, and then reduce your request if
that fails. Lather, rinse, repeat, until it's futile.

> It also means to write more code, some of which is almost never going to
> get used... I mean, it would be like writing a program so that it runs
> both on systems with an FPU and without: You basically have to write it
> twice. It is almost always simpler to just say "Buy an FPU!" or "Buy
> more RAM or enlarge the swap file!"

If the software vendor is also the hardware vendor, then he cannot blame
the user for the version of the hardware that he's shipped.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#12109

On Oct 24, 9:39 pm, Markus Wichmann <nullp...@gmx.net> wrote:
> On 23.10.2011 15:24, Malcolm McLean wrote:
> > On Oct 23, 3:15 pm, Richard Damon <news.x.richardda...@xoxy.net>
> > wrote:


> >> if the task has a suitable alternative that it
> >> can fall back on if the malloc returns no buffer,

<snip>

> It also means to write more code, some of which is almost never going to
> get used... I mean, it would be like writing a program so that it runs
> both on systems with an FPU and without: You basically have to write it
> twice. It is almost always simpler to just say "Buy an FPU!" [...]

At the times this was likely to occur there were usually multiple
versions of the math library. The application was not aware if the FPU
was present or being emulated (apart from a slight loss of
performance...)

<snip>

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web