Wikipedia goes wrong: is this possible?

I do not know you but i consider Wikipedia one of the more ugly things on internet and in general in the humanity history. I detest anything is Wiki and like Wiki, i consider a similar approach about the various argument mistaken, useless and dangerous.

Some time ago i have read (i do not remember the item) a thing like the following:

int funtion(int var) {

int arr[var]; ......

}

All this should be in the place of malloc function:

int function(int var) {

int *arr;

arr = malloc(var * sizeof(int));

if(arr != NULL) { ....... } else { puts("OUT OF MEMORY"); exit(); }

arr = NULL; free(arr);

}

I am not a very C expert, i have studied some things, read some item, but i have never seen a thing like this and that my compilers, obviously, refuse.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali
Loading thread data ...

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.

Reply to
David Brown

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.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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.

S
--
Stephen Sprunk         "God does not play dice."  --Albert Einstein 
CCIE #3723         "God is an inveterate gambler, and He throws the 
 Click to see the full signature
Reply to
Stephen Sprunk

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.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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

Reply to
David Brown

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

?

??

OK, without Occasionally.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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

Reply to
Bill Leary

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.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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.

--
Ian Collins
Reply to
Ian Collins

formatting link

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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

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

--
Ian Collins
Reply to
Ian Collins

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.

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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

--
Andrew Smallshaw 
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

Euros or Dollars?

--
Pasquale Frega 
http://www.webuse.net/pm.php?u=2970 
 Click to see the full signature
Reply to
paskali

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.

--
FSF associate member #7257
Reply to
Ivan Shmakov

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

Reply to
Jukka Marin

"Expected"? Argh!

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

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

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

Reply to
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

Reply to
Jukka Marin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.