|
jmaida wrote: Buffer overflows were and maybe still are reasons many virus attacks
Yeah, I often joke when this happens that I wind up attacking my own code with an exploit. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: The best one can do is lot of bounds checking in one's code.
In embedded you really have to make each line count. When you have a handful of microseconds to compute the nes state of the transistors that are piloting a motor, your clock is 40 Mhz if you're lucky and you have 3kB of RAM and 64kB of flash bounds checking in the code is really on a if-needed basis.
You just check the memory window while debugging step by step and infer from that.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
understood. tight coding
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
buffer over/under write/read is probably the only bug i have never created as i have always been painstakingly careful about such . in fact at a job many years ago i wrote a quick little memory protection scheme . it quickly found the source of memory errors though the project failed miserably . as for your situation would it make sense to run your code on a desktop/laptop in a kind of simulator of your devices w/ memory protection code so as to find any such errors ? - Best
|
|
|
|
|
as for your situation would it make sense to run your code on a desktop/laptop in a kind of simulator of your devices w/ memory protection code so as to find any such errors ?
In some cases - well many cases - yes, because I write my code to be cross platform wherever possible, but in this case, it wouldn't have made sense because it's I2S driver level stuff where there's no corollary on a PC. I'd have to write (and debug!) an emulator for it, so it just adds to the test matrix rather than solving anything.
My errors were dumb ones, TBH. The kind that are somewhat embarrassing but easy to find and fix once you step away and come back to it.
Pointer ops are nothing special to me. I take to them pretty readily and don't often make mistakes. When I do, they're usually kind of typo or memory lapse varieties.
To err is human. Fortune favors the monsters.
|
|
|
|
|
regarding the cause of errors , many years ago at a small firm it occurred to me to investigate the ultimate presumably psychological cause of each of the many errors in our then project . i never began the investigation but it would not have succeeded anyway had i attempted as it would have required considerable cooperation from my 2 co-workers who each held me in contempt not to mention the 3 owners who disliked me as they were aware i believed each of them to be insane .
|
|
|
|
|
Boy that sounds like a fun place to work. 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
BernardIE5317 wrote: co-workers who each held me in contempt not to mention the 3 owners who disliked me as they were aware i believed each of them to be insane .
Wow. Just Wow.
But since then you have learned to not tell people that they are insane?
|
|
|
|
|
BernardIE5317 wrote: it quickly found the source of memory errors though the project failed miserably
Not sure what that means but you cannot find the memory problems you stated in C/C++ using static analysis. It requires runtime analysis and it requires, at a minimum, fully exercising the application. Even then there is no guarantee.
|
|
|
|
|
my recollection was faulty . it was merely detecting un-freed memory . this was long before C++ . the project was all C . though fences and vector of stack addresses and automatic inspection of fences upon freeing or at end of execution of un-freed memory vector and manual inspection of stack addresses in either case would work reasonably well far better than examining every line of code in project it seems to me .
|
|
|
|
|
I feel your pain.
Just located and fixed two buffer overruns yesterday where my code was writing I422 video to buffers sized for I420.  It would run for hours, but just don't try to allocate/free anything! (... or try to make sense of the data that follows!)
|
|
|
|
|
So much nicer when it crashes immediately!
To err is human. Fortune favors the monsters.
|
|
|
|
|
Like BernardIE5317 and some others mentioned.
I remember using debug versions of malloc/free that would allocate a few extra bytes of memory at the end of a malloc() and write marker bytes in them. free() would check to make sure they survived. I think there were a few other tricks dealing with using special bytes for unallocated memory.
|
|
|
|
|
Hi All,
Being strongly encouraged (read forced) to use Python for a test rig. Okay need to get down with Kids etc. but syntactic white space 'align your tabs' (who came up with that, is it 1988, am I using a BBC micro) oh gord!!!
|
|
|
|
|
Worse: space and tab are not the same: so two lines which look to be identically indented in your chosen editor can be in different code blocks as a tab is one whitespace regardless of the visual effect. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Agreed but with intelligent Python editors why can't they convert between white space and tabs?
4 spaces = 1 tab
|
|
|
|
|
Most editors can, but they tend to default to "use tabs" to save file space.
And some only do it for modified lines, and ... it's a mess.
Just don't use Python is my advice! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: Just don't use Python is my advice! Laugh | 
I'm with you, but "it's so simple and easy to use..." crowd are in force!
|
|
|
|
|
OriginalGriff wrote: Just don't use Python is my advice!
Friends don't let friends use Python.
I attempted to learn it a few moons back and found the tab-space thing to much of a deterrent.
|
|
|
|
|
Friends don't let friends use TABs.
|
|
|
|
|
|
It is scripted so it's slower than .NET code. And the UI?
|
|
|
|
|
|
There's Codon for that:
[^]Python-based compiler achieves orders-of-magnitude speedups | MIT News | Massachusetts Institute of Technology[^]
>64
Some days the dragon wins. Suck it up.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
