assert ( malloc...

A question for you, Anon.

If you watch at malloc() manpage you can notice that the function may return NULL in some cases (i.e. errors or 0-sized allocation). How do you face this issue?

I noticed that many programmers check the return value and manage error routines for it, while other just assert() the return value not to be NULL.

Also in C++ by the way you use the new operator without taking care about the return value (I guess it's asserted to be not NULL under the hood, is it?)

What is your opinion?

On a desktop/home computers you practically never get NULL from malloc, unless your program has a severe memory leak, since the operating system will swap unused memory to disk. Also, memory fragmentation might cause malloc() to fail if you ask for a block too big even though there's theoretically free memory left.

When the memory has gotten fragmented, you'll notice that performance drops since malloc() has to do a lot of work per allocation.

>>41
Your kopipe is out of date.

>>34
Really? I thought he was trolling. Dynamic memory allocation is very important in my opinion. It's so important that people have spent quite a lot of time working on components to handle the process so you don't have to.

Sure, but these aren't considered stable by any safety-critical standard. Without managed pointers, any sort of malloc implementation is vulnerable to fragmentation. This is why even the latest versions of Firefox grow to using many hundreds of megs of RAM over the course of several days of use. With managed pointers, you need low-level thread control or some sort of stop-the-world call to compact memory, preventing any real-time application. You also need some extreme static analysis to guarantee an upper limit on dynamic memory usage (hint: no such analysis currently exists.) And you cannot reliably estimate performance of any kind. These are not stable or safe; they are merely acceptable for consumer applications.

There is a reason that safety critical coding standards, e.g. http://spinroot.com/p10/rule3.html , forbid dynamic memory allocation after startup. You don't want your plane to crash or nuclear reactor to fail because its memory was too fragmented.

>>43
The flaw in your reasoning is that a web browser isn't a nuclear reactor. It neither needs to nor can know how much memory it will need for correct operation. I'm all for abolishing the browser, but not for that reason.

>>44
The flaw in your reasoning is that a web browser isn't a nuclear reactor.
Hmm. This is not immediately obvious to me.

>>43
Funny thing, Firefox has lots of trouble with memory, whereas Opera, Safari, Chrome, hell, even MSIE perform much better in that respect. You can blame malloc all you want, but the problem is the browser.

[spoiler] fuck [spoiler]

>>45
Oh, you're an engineer. My condolences.

This discussion is silly since most software people develop these days isn't meant to run on extremely limited embedded systems or ``safety-critical'' systems. Most software should be written in as general manner as possible and only specialized as needed and when needed, not done so by default. Doing so by default only greatly cripples the application.

It reminds me of one system which I have much respect for, but it pre-allocates all the heap on startup, then just uses its own allocators and gc to operate on that heap. This is stupid because I have a fast machine with a lot of RAM, and it needlessly wastes RAM which it doesn't need by default, but when I have it load applications which alloc a lot, it would need a lot more, thus either fail because of heap exhaustion(read: allocation failure) or it would extend its heap automatically or via a command line parameter (depending on used options). Virtual memory exists for a reason on server and desktop machines. Manual memory allocation exists for a reason and GCs exist for a reason. They provide robust applications in the real world for real applications. What you consider ``safety-critical'' is just niche domain, but a needed one nonetheless, but it doesn't apply to most software written for normal boxes, nor it should.

Besides, failure to allocate memory is just one of many possible failures. I'd argue being able to recover the application automatically or manually (interactively) is of much higher value than just avoiding memory allocation at a cost. Here's an example where NASA launched a spacecraft into space, and upon extraordinary circumstances managed to patch the system live and fix the bug using a REPL (the application, Remote Agent, was a sort of a control AI, written in Lisp):

https://www.globalgraphics.com/news/ggpress.nsf/GGRVPressReleasesPublished/06608A7E4A25BE15802568E1005745C8/$FILE/PR19990817a.pdf
http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
http://en.wikipedia.org/wiki/Deep_Space_1

I'd feel a lot more comfortable as an engineer to be dropped in a REPL when a critical error happens so I could debug, find the error, and fix/hotpatch the system as it runs and resume its workings without interruptions, than I would be to be greeted by a segfault and eventual catastrophic crash because there was a bug someone didn't anticipate (suprise: humans aren't perfect, and foolproof programs don't exist. if it can fail, it will fail given enough time and entropy)

http://www.schneier.com/blog/archives/2010/05/automobile_secu.html
Some interesting reading in the comments here about secure systems.

>>46
Cool story bro. http://www.google.com/search?hl=en&q=problem+firefox+memory+opera+safari+explorer&aq=f&aqi=&aql=&oq=&gs_rfai=

>>51
hl=en&aq=f&aqi=&aql=&oq=&gs_rfai=
Son... I am disappoint.

>>43

p10 even denying alloca? Man, that's rough. Are you allowed to do any IO? Although, I admit I wouldn't want to fly on an Airbus that had a flight control system wihtout real time constraints.

>>53
Everyone should deny alloca. It's horrible for many reasons.

>>44-46
Strange how you guys thought my post was in any way related to a web browser. As I've been saying, malloc is perfectly fine (and indeed useful) for consumer applications. These are not safety-critical (no lives are at stake), and not expected to remain stable over a period of years or decades.

>>49
Of course a remote firmware update is useful. That also has absolutely nothing to do with malloc. I'd bet dollars to donuts that spacecraft already did not allow dynamic allocation of any form.

>>54
There's nothing alloca can do that ordinary variable declaration can't. Why does it even exist?

>>56
C89 and C++ don't support VLAs. Also, VLAs are almost as dangerous as alloca()...

>>53,54
It's the implementation of alloca() that's bad, combined with C's lack of stack protection.

In a language with segmented stacks and/or better static analysis to guarantee stack limits, alloca() is a great idea (and perfectly safe.) Unfortunately I don't think any such language actually exists. Go and D come close...

stack allocation is dumb. IF you need that kind of performance you statically pre-allocate a chunk of memory.e.g. char a[100000];

>>57
VLAs don't have to be on the stack. You don't even need a stack at all to implement C.

alloca only exists for the convenience of not having to use free. It is intended to be used for the sort of quick hacks that competent programmers would write in perl (the kind that take seconds to write, and are only run once or twice before being discarded).

>>60
You don't even need a stack at all to implement C.
Oh, that's not true. As long as there is recursion involved, you need to have some kind of LIFO structure. It does not matter whether you call it stack or something else, it will still be the stack.

And don't come up with this "C specification does not mention stack" bulshitte.

>>60
You don't even need a stack at all to implement C.
Oh, that's not true. As long as there is recursion involved, you need to have some kind of LIFO structure. It does not matter whether you call it stack or something else, it will still be the stack.

And don't come up with this "C specification does not mention stack" bulshitte.

>>62
Last I checked the specification doesn't specify how you should implement recursion- just how it should work.


T *foo;
if (!(foo=malloc(TIMES * sizeof *foo))) {
   perror("malloc()");
   exit(EXIT_FAILURE);
}

>>62
that's been discussed to death on comp.lang.c:
Before you repeat that the claim, which has been frequently made in this thread, that LIFO semantics are mandatory, please consider the following implementation:

It allocates and deallocates space for activation records. It makes sure that it always allocates a given record before the start of the lifetime of the variables stored in that record, and it makes sure that it never deallocates them until after the end of the lifetime of those variables, but it does not always carry out the allocations and deallocations in the same order as a LIFO mechanism would.

What requirement of the C standard would such an implementation violate?
This question is interesting because it relies only on the text of the Standard, and tells something about all possible C implementations. The Standard does not define the term "stack", as has been said, but we can certainly make inferences from the text of the Standard. The Standard's requirements on the lifetime of variables are very loose, and if the implementation wishes, it can make every variable exist from the start to the end of the program. Even the case of multiple instances of local variables in a recursive function can be catered for when we realise that C doesn't guarantee infinite recursion depth.

I can also imagine a C implementation which provides closures as an extension and as a result has a "spaghetti stack" which is certainly not a true stack. I believe this shows that C does not require a stack.
Also, what about an implementation that uses two stacks, one for return addresses and a separate stack for automatic variables? This could fully conform and would have major advantages, such as preventing buffer overflows from overwriting the return address. On such an implementation what would you mean by "the stack"?

the quotes in >>65 are all from this thread:
http://groups.google.com/group/comp.lang.c/browse_thread/thread/39a0658c686dce82/aaab9ac8204c1dc9

>>66
it'd be better to link to the beginning of the thread instead of the middle of it:
http://groups.google.com/group/comp.lang.c/browse_thread/thread/39a0658c686dce82/680d40637eab95e3

>>67
Cheers, my Home and PgUp keys don't work anyway.

>>65
I can also imagine a C implementation which provides closures as an extension and as a result has a "spaghetti stack" which is certainly not a true stack. I believe this shows that C does not require a stack.

AKA Apple's Blocks (all hail Glorious Leader Jobs)

>>60
VLAs don't have to be on the stack. You don't even need a stack at all to implement C.
Uh? >>57 did not say anything about a stack. >>58 mentions the stack, and says nothing about VLAs. Are you confused?

Also, your blatant Perl plug is ludicrous. alloca() is useful for performance. When you just need a scratch buffer, malloc() is by comparison extremely slow, leads to memory fragmentation, and will give you space in a different cache line. alloca() is compiled into a single processor instruction to offer you the space you need, and the space is (likely) already in the processor cache.

In fact absolutely everything in your post is wrong. Hand in your geek card; no internets for you today.

>>70
geek
  ( ˃ Д˂)

Uh? >>57 did not say anything about a stack.
apparently you missed the mention of alloca in >>57. You might want to work on your reading comprehension skills.

alloca() is useful for performance.
If malloc is too slow, use sbrk or mmap. If you'd actually written anything of consequence, you'd know that if you use malloc sensibly, it's almost never too slow.

malloc() is by comparison extremely slow, leads to memory fragmentation, and will give you space in a different cache line
That's only if your malloc is complete shit (the slow and different cache line things) and you're using it wrong (the memory fragmentation thing).

>>72
write a program which uses malloc and have it beat one with statically allocated block of memory. Then we can talk.

I think >>72 is trollin' y'all.

If malloc is so bad, wouldn't everyone want to write performance critical parts without malloc/kmalloc/alloca/etc?

>>75
I bet you don't understand how even one of those works.

>>73
That's not what alloca does.
Also, that's trivial to do, just malloc a big enough block of memory once and it shouldn't be any slower than statically allocating the memory unless your malloc is designed to be slow on purpose.

80 Name: Anonymous 2011-02-04 19:06

---

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List