Wikipedia goes wrong: is this possible?

Remember that all generalisations are false.

These two functions (assuming you correct the leak in the second version) do different things. The first allocates the memory on the stack as a variable length array, and is perfectly valid unless you are using a dinosaur compiler or do not understand how to set the compile-time switches properly. I think even Microsoft's C compiler handles VLA's properly. The second version allocates the memory on the heap.

The first version here gives you smaller and faster code, but will be more likely to have problems if "var" is very large. But if you know that var is small, then the first version is smaller, neater and clearer

- and therefore better.

In my business, small systems embedded programming with an emphasis on reliability, the first version might be considered acceptable if there are clear restrictions on "var". The second version is completely unacceptable - dynamic memory must be avoided unless there is no other way to handle it, and even then "malloc" and "free" are rarely the right way to implement it.

Read about modern history and politic on that site, see how are treated some arguments. Disgusting.

There are not leak or error on my code, other way (may be better) to write the same.

When you will use any day the first form, say me and all our here.

Yes, there is:

By clearing the pointer to the object _before_ freeing it, and then calling free(NULL), you leak that object's memory. That you made such an obvious error in your example showing the "superiority" of this solution shows just how difficult this can be to do correctly.

With VLAs, the compiler automatically cleans up the memory when the object goes out of scope, so a memory leak is not possible. There is no need to rely on the programmer being perfect.

He just told you when (and why) he uses the VLA form.

Yes, it is sure, that is a my mistake.

I am sure, i have read a lot of code and never i seen that form.

You may have read some C code, but I strongly doubt you have read any code for small microcontrollers or high-reliability systems written by people who know what they are doing.

There is no doubt that VLA's are not used very often in general C code. But they are handy if you want a small local array - they are easier, neater and faster than the malloc stuff (especially if you have more than one dimension). I think they are most often used for small buffers, especially for string manipulation.

Note that C++ does not support them (gcc allows them in C++).

Personally, I have only used them two or three times in my career. More often, my local arrays have compile-time fixed sizes. But I have /never/ used malloc to make a local array - in fact, I have never used standard C library malloc in any of my embedded code. As I said, a VLA might occasionally be acceptable if I know hard limits on the size, but standard malloc is never acceptable in my code.

(Occasionally, it is acceptable to use specialised dynamic memory management from pools, and it is also sometimes okay to use a malloc implementation that does not support freeing memory and is only ever used in initialisation. But standard malloc and free with its unpredictable success, memory fragmentation, non-deterministic run times, and potential complex code to avoid leaks, has no place in resource-constrained or high-reliability systems.)

I avoid to use C for string manipulation, there are better solution like TCL.

??

OK, without Occasionally.

Well, there are "other" solutions. Whether they're "better" or not would depend on the circumstances.

In many embedded systems, most historically, your memory is limited and you can't get any more via virtual memory. No disk to swap to. So, if you malloc its often questionable whether it will succeed or not. But...

If, say, you reserve a chunk of memory to do mallocs from, and work out a policy to make sure you never exhaust that memory, doing malloc/free lets you reuse that memory for multiple purposes. But are other ways to do the same thing without the malloc overhead and it leaves you open to making a mistake that leads you back to the problem I noted above. When I'm doing embedded work I don't use mallocs either. It's asking for trouble.

These days, though, some (a lot of?) embedded work is running on some OS with disk and virtual memory. In these cases, even thought he computer is "embedded," you DO have some reasonable expectation that you can get more memory as needed. If your application performance will allow it, then you might well use malloc/free for your work.

With "occasionally." Embedded work is a different world. Using malloc is almost always a bad idea in much of that world.

- Bill

What you say is very interesting but for me the use of C, in general, is not a good solution in this case. Apart the use of not (or pseudo) standard solution, the use of C in embedded system is not suggested, i see (here in Italy) the use of more evolute and modern platforms like .NET or Java.

The C is not the solution of the world, there are a lot of things possible with it but it is always a old (prehistoric) language and for this it is difficulty to upgrade or to change. Think: how many is easy to play with strings? how many is confortable to manage files? how may is simple and rapid to make gui's? No, for those, there are more modern and more good solutions. Not all is C. It is sure, if you learn a language, you tend to use always that, but in your case a more modern solution is better. I avoid to use C, only the strictly necessary things.

The virtual machines permit a better memory and resources managment, you do not have to play with pointers, dinamic memory managment, use or not virtual memory, etc..... It is sure, i do not like so J2EE or .NET, but, may be, there is a valid reason of their existense.

Then you are either deliberately trolling, or have a different view of embedded devices to those of us who work with them...

Another reason not to like them is they don't run on the vast majority of embedded devices.

"The typical .NET Micro-Framework device has a 32 bit processor"

The majority of embedded devices use 8 and 16 bit CPUs.

solution,

the use

do not

memory,

No, there are a lot of 32bit devices, as well as i wrote there are not economical reasons to choice 8bit devices in the place of more modern 32bit's.

Cite me one 32-bitter with a unit cost under 10 cents...

Euros or Dollars?

I guess either 0.10 USD or 0.10 EUR would make quite an example.

FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some 2 USD range per piece, whether they're 8- or 32-bit. I believe I've never bought an MCU for less than 0.5 USD a piece. But then, I've never bought more than a dozen of a kind at any single deal, which probably explains the difference.

The NXP LPC8xx series is expected to be in the 50 cent range (and up). Not bad for a 32-bit RISC in DIP8... :-) (Yes, they do have DIP8.)

-jm

"Expected"? Argh!

A price you can't see for parts avaiable at mouser or digikey is not real...

That's been my criteria for designing in parts for more than a decade. If you can't find it at one of those two, it really isn't something I want to put in a design. Those companies have become a my proxy of choice for a good purchasing agent when I am looking for quantities under 100 of almost anything. Granted, that I may pay a bit more per part---but that's nothing in comparison to designing in a part I can't find in time to deliver my product.

Mark Borgerson

:-) Arrow says the price is 0.39 eur (@ 10000 pcs). Haven't actually tried to buy any. Got a demo board from NXP recently, so the chip does exist. Digi-Key knows the part numbers, but has 0 stock.

-jm