Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Dynamic memory allocation in small microcontrollers.

Status
Not open for further replies.
These rules are not random or capricious, a little searching on these functions would have turned up lots of reasons.
https://blog.mozilla.org/nnethercote/2009/03/13/atol-considered-harmful/


What on earth has crawled into your normally helpful placid nature? I didnt suggest they were random or capricious, I wasnt sure of what to google and also I felt it a fair way to join the conversation!
Now that I have sunk my teeth into your ankle, Thank you for the answer, I appreciate the effort you made to find a good link.
But I have to admit that the wording immediately made me think of a stone tablet and 10 must not do's :D.
It is an interesting read and one I have bookmarked to come back to some time when I know more.
Thanks again, I am indeed grateful, but just a little surprised at how sharp you sounded
 
These rules are not random or capricious, a little searching on these functions would have turned up lots of reasons.
**broken link removed**

I don't know about this. atol() is certainly more efficient than strtol() and this may be important if you parse long data streams. In many cases you already know that you only have a number in the string and nothing else and there's no reason to check again. You just need to know what you're doing. Although in some C implementations atol() may be implemented through strtol() anyway.

Instead of dwelling on false safety issues, the author would better envision a possibility of spaces in front of commas in his exemplary parsing code. This is really a shame. Have you seen that: "Enter your credit card number, but do not enter any spaces". Why is that? The programmer is afraid that his space-stripping code may not be safe?
 
I don't know about this. atol() is certainly more efficient than strtol() and this may be important if you parse long data streams. In many cases you already know that you only have a number in the string and nothing else and there's no reason to check again. You just need to know what you're doing. Although in some C implementations atol() may be implemented through strtol() anyway.

Instead of dwelling on false safety issues, the author would better envision a possibility of spaces in front of commas in his exemplary parsing code. This is really a shame. Have you seen that: "Enter your credit card number, but do not enter any spaces". Why is that? The programmer is afraid that his space-stripping code may not be safe?

I certainly agree it's more efficient (and obsolete) but considering the life-safety context I understand. I use the function sometimes for simple input in a trivial testing program or in non-critical cases where the computer is generating the output in a very strict way that leaves no room for chance.

Here is a good comparison: https://stackoverflow.com/questions/3792663/atol-v-s-strtol
 
Last edited:
What on earth has crawled into your normally helpful placid nature?

As an Old salt I have a great tolerance for clever remarks that move the thread forward but little tolerance of shouting.
 
Last edited:
Dupe.
 
I use the function sometimes for simple input in a trivial testing program or in non-critical cases where the computer is generating the output in a very strict way that leaves no room for chance.

I use my own functions for text parsing. I have several, ranging from very simple (a la atol() except it'll return -1 on nun-numeric input) to very sophidticated, which provide very detailed information on what's in the input. I use them all (depending on the goal).

I don't think it has something to do with safety.
 
I don't think it has something to do with safety.

It's failure modes are per C99 are 'undefined behavior' so a code audit for secure computing would flag it as a violation due to being a possible exploit vector. The recent 'Heartbleed' coding snafu has everyone reviewing old code for this sort of thing. I have some code in the current Linux kernel tree that's been triple checked by others for problems but I still reviewed it just to make sure.
**broken link removed**
 
LG cant see this post anymore because his comments got him banned from this thread. having read what he put i personally dont think he was rude and i certainly dont think he was any ruder than many other threads on here.
you would think by now people would get how bad things are. Mr T has to post questions because there is rarely any interesting or though provoking being asked anymore then you go and ban one of the few people that actually does post a question worth asking. sorry for the off topic guys but i am fed up with the double standards around here
GM as in jason not LG
 
It's failure modes are per C99 are 'undefined behavior' so a code audit for secure computing would flag it as a violation due to being a possible exploit vector. The recent 'Heartbleed' coding snafu has everyone reviewing old code for this sort of thing. I have some code in the current Linux kernel tree that's been triple checked by others for problems but I still reviewed it just to make sure.

I don't think that you can create safe software by following "safety rules". There are always many things that can go wrong. The way to create a safe software is to always think about all possible consequences and test all possible cases.

These rules create an illusion that if you follow them, your code will be safe. This illusion is often repeated and thus became widely accepted to the point that it is tought in schools. This cause software developers not to think and test, but rather relay on false safity rules, and thereby drives them away from the very thing they need to do to keep their software safe. Software becomes more complicated, but it doesn't get safer or bug-free.
 
I don't think that you can create safe software by following "safety rules". There are always many things that can go wrong. The way to create a safe software is to always think about all possible consequences and test all possible cases.

100% agree but it's the same with front/side air-bags, seat-belts and speed limits. They don't stop crashes but try to limit the damage when something does crash into a predictable path so it can be handled in a deterministic fashion.

If you're an expert a tight-rope is a mile wide but it's still a long way to the bottom so you make sure your equipment is least likely to fail with redundant clamps, over specification of cable and making sure the wind is not blowing too hard.
 
LG cant see this post anymore because his comments got him banned from this thread. having read what he put i personally dont think he was rude and i certainly dont think he was any ruder than many other threads on here.

I don't think he was rude, just head splitting annoying in the formation of his question. There's a way to be inquisitive, clever and not annoying.
 
Any idea why this is considered a no no 20.10 (req): The library functions 'atof', 'atoi' and 'atol' from library <stdlib.h> shall not be used.

Maybe because of this: If I dislay this number to you:

10.000
or
10,000

What is that number to you? I bet the last one means different to you over there than it does here in Finland.
 
Maybe because of this: If I dislay this number to you:
10.000 or 10,000
What is that number to you? I bet the last one means different to you over there than it does here in Finland.
I believe it has more to do with atof/atoi/atol having undefined behaviour for out-of-range input strings, and not being able to detect errors. ref: https://bytes.com/topic/c/answers/730046-question-about-atoi "The functions atof, atoi, atol, and atoll need not affect the value of the integer expression errno on an error. If the value of the result cannot be represented, the behavior is undefined."
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top