Experts reboot list of 25 most dangerous coding errors Computer experts from some 30 organizations worldwide have once again compiled a list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The list for 2010 bears a striking resemblance to last year's list, …
And the time limit to fix a bug can be .. let me think .. Oh yes something like 17 years ?? .. and in that time you paid already how many time for the same error ??
In other words,
the "little" get smacked/sued and have to pay and/or fix their program immediately
and the "BIG" will start press conferences, lawyertalk, mumbeling about options, undocumented features, etc etc and nothing changes for a long time ..
and Paris ??
She knows BIG is NOT always better
the cost of development is going to go through the roof if this takes off.
Have to secure a code base, get a trusted third party to hold onto each commit, plus all the extra testing, and you will have to verify all the libraries and interpreters you use, along with a code review of compilers, which for the MS dweebs in the main is closed source, that should prove fun.
Background checks, you will have to pay a lot for developers to allow that., this is going to cost a King's ransom; need to make a quick change to a SQL statement is going to take ages to actually filter to live, no one is going to allow anything out of development, unless they have tested it from here to beyond.
Oh well, makes being a developer for others a bit boring and high risk, but they won't have to do much work though, and they will be a considerable cost to any business, so will be treated a bit better if the business actually survives the extra costs.
Smaller players who do their own coding for their own businesses will be in a much better position as well, as they will be able to make quick changes whilst everyone else bears the huge cost of any small change, big companies will just freeze.
And what is development, word processors have macros, as do spreadsheets, so accountants and secretaries will be liable if they put in a security risk and have signed the contract. As will anyone who uses a computer, it is all programming in a way, and if they put in a security hole due to ignorance they get sued :)
It is like a hack against the system, but anyone has been allowed to write such a contract in the past, it is nothing new it is just unworkable and uneconomic.
Just to pick one of your points:
"need to make a quick change to a SQL statement is going to take ages to actually filter to live"
No. If the code has previously been tested and there is no SQL injection possibility, it can go straight into live...after testing ofc
I think you're overestimating the danger. These are all problems that already exist, the list will just help foolish coders avoid the dangers in future (MS - we're watching you!)
Storing and registering code commits is easy, and most shops use code management tools like PVCS, Harvest, etc already. Small time devs don't, but would not agree to these terms without much increased fees. They're not interested in that type of application development.
Background checks are cheap. I do them for my tenants. most businesses already do this for employees. Even going further and getting C2 clearance certifications for each employee is only a few hundred bucks, and your devs are probably making $50-150K anually, so that's chump change.
Avoiding the most common, published mistakes? You should be doing that anyway. Yes, going through millions of lines of old code to find this is an issue, but new developments should be starting clean.
Devs who do "internal" work are likely doing that for external customers, and those customers can just as easily hold your internal devs to the same terms...
Development of this kind of code we're limiting here to applications that touch protected content, or open system level risks. macro's in word? We're relying on WORD to have a code base that itself prevents Macros from causing harm, so writing a bad macro should not be able to interfere with your system and this is not a concern, and does not require this effort. Further, we're talking about CONTRACTED development here. If you are being paid to write macros, you SHOULD be doing it right.
Writing good code, and doing good testing IS economical. it reduces tech support loads, eliminates dissatisfied customers, and avoids contract disputes and legal action when customers simple sue over "bad code" they commissioned to be written. If the contract does not have these specific terms, you can easily be sued, and if there are glaring errors, including these common industry accepted and published dangerous errors, you can easily be ruled incompetent, and that you produced a flawed product, and can be ordered to refun and pay legal fees, if not damages. Having these terms provides customer level of comfort, requires only minimal training for your devs, and no one said you have to include ALL the contract stipulations (like 3rd party code review).
Firstly, for any developer who claims to sign up to this, such bugs uncovered will be discovered in "previously existing code".
Secondly, I can see this as nothing more than an excuse for a lot of finger pointing. People working on a project which may be vulnerable to penetration will create suboptimal code as their concentration will always be on deflecting the blame rather than getting the job done.
We don't need stupid contracts.
We need coders to be more aware of the potential risks, and to attempt to code with responsibly.
It's a good thing to have well trained developers who understand coding with reference to security issues. (That's how I make some of my money.) But unless you are developing from scratch for a trivial microprocessor (itself developed from scratch) using machine code you are relying on code created by tens or hundreds of thousands of previous software engineers working in thousands of different organisations, either as part of the toolchain used to create your application, or your operating platform, or recursively in respect of earlier systems where these platform and toolchain artefacts came from.
Open source distributions are developing an effective form of suppy chain management with cryptographic signoff by developers and integrators. This is something likely far better than anything achieved in the complex and closed source world. But either way, the integrity of any final system beyond a given level of complexity still depends upon a web of trust with a great number of people past and present involved and it won't be possible to get them all to sign the proposed contracts. So if the platforms and toolchains are not going to be indemnified, what value is it to the customer of a more expensive application in practice if the latter is indemnified regardless of the legal status of the former ?
This one isn't going to fly in the open source world where licenses specifically disclaim developer liability, though there is nothing to prevent specific code being developed and released open source with side agreements. And if the source code supply chain isn't open source the customer has no way of knowing where all the platform and toolchain code came from or who checked it to what extent anyway.
After a few years in the dev game, I've pretty much made all the mistakes in the book, including one potentially news-making SQL injection fail. Fortunately I'm capable of learning , so I reckon I'm at least half decent these days. I code defensively, check best practice, analyze for holes etc etc. All the stuff you're supposed to do.
Yet when I'm asked to estimate dev costs for a bid, including all of the above, why is that number invariably slashed in half when the bid goes to the potential client?
I hear that, worse yet is when a client is made aware of vulnerabilities and declines to pay to fix them. I'm sure that I'm not the only programmer who's had the nightmare of inheriting a messy code base.
Bad code quality is a reflection of the trend for businesses to compete on price rather than quality. The problem is far more widespread than just software. Businesses can hire professionals who know what they're doing, or they can give the project to the cheapest developers to jerry-rig the thing together. There are plenty of us capable of doing the job right, but frankly until clients start to care about (and pay for) quality, our employment hinges on doing the work quick, dirty and cheap.
This is evidenced by the eagerness of western business to hand over critical business functions to offshore teams with whom they can neither communicate in real time nor communicate proficiently in the same language.
The problem tends to be that the typical customer has a rather faint idea of what they actually want done (or what is possible/reasonable) at the time a contract is signed. Suggest paying for the work that is needed to figure this out and they are likely to go to someone who is prepared to overlook this. I suppose it is a fundamental flaw in how things work in practice: one can't really blame the customer for not being an expert as this is the very reason they come to you. Smart customers might (eventually learn to) make different contracts for experts looking after their interests and those doing the rest of the work, in which case the suggestion of contract provisions for liability for insecure code would be more realistic in practice.
"How many years since the Morris worm?"
I think that should read "How many decades since the Morris worm?
Given that the list is a concensus of these errors the odds are.
1) The list will slowly change over time as programming target systems and methods used change.
2) Some items will remain persistent offenders due to *massive* code backlog, probably because a large part of this code calls certain *very* badly written library functions. Rewritting the library functions would porbably remove a lot of those vulns, but break some code (and of course it's impossible to say how much or where) that depends on those functions *being* poorly written. This presumes you still have the source to re-compile from. Also OMG it might *slow* the software a bit, and we can't have that, can we?
Instead of contracts to shift liability for bugs to the coders involved, how about we start a program of corporate education. We could call it "you get what you pay for."
I fail to understand how running your coders 18 hours a day, with no vacation for years, paying them barely enough to survive while either being already outsourced to some third-world code sweatshop or constantly under threat of same is supposed to produce good code.
Pay your coders well so they are enthusiastic. Give them vacation time between projects to decompress. Allow them to work sane hours so that they are well rested and their minds are fresh. Remove from them the constant stress of “fear of losing my job.”
Suddenly you have well trained coders who have their wits about them and care about their work. The code these folks produce will be better than that churned out by the folks at the code sweatshop.
The only way to make good code is to hold the management and directorship of the businesses involved personally liable for the quality of code they commission.
i know a LOT of coders. We employ about 600 of them, across 6 different development platforms in languages from COBOL to C to Java. A previous firm i worked for had about 10. I also worked for resellers and supported a number of coding shops.
Coders typically make well more than I do, and I'm not exactly underpaid... It's rare to find an "underpaid" coder.
Yes, some niche developers make poor wages, as do some guys in startup and small firms, and guys writing simply batch code. Most of those guys are also "starting" coders, who in 4-8 years will be making $60K+ given their experience. I started in IT making less than $20K a year too.
I also know very for coders who don't get vacation, and it's commonly held nowadays that lack of sleep make WORSE code. Well rested devs working 40 hours write more lines of complete code than thos who work 60+ hours... Most firms won't LET their coders work more than a set number of hours straight (though development emergencies sometimes override that in small firms).
"well trained?" we're not talking about complex math and rare algorithms here. We're talking about avoiding common, predictable mistakes. It's a simple few days of training, tops.
Management IS held responsible. If the devs push out bad code, and the company looses money, do you not think the investors will be looking at management for reasons why? management can't often read the code themselves, so all they can do is put in place people who can, and set up PROCESS for review. If that process fails, is it really some exec's fault, directly? No, it's a senior developer's problem. Commissioning code means "write something that does this" and has NOTHING to do with the internals of that code. it's not micromanagement.
Nail on the head there. Not just programmers, any IT folk...and probably just folk in general. Our buddy Michael C works at a pretty nice place I think. Unless my anecdotal evidence of talking to all the IT folk I know around the world about their jobs is totally off base, his gig is definitely the exception, not the rule.
I'm a network admin, and sure enough I am required to put [number shamefully well above 40] hours a week on average, 24/7 on call, no vacation pay for my own support cell phone, etc. etc. etc. Only get paid for 40 hours a week though, no overtime, no banked hours, nada. I’m consistently told that I choose to work overtime, and that because it’s my choice, the company can’t be held accountable. That may be true from one perspective, but the reality is I am not assigned hours to work, merely responsibilities, projects and deadlines. Heaven help me if anything is late or ends up broke. (No way you can keep this ship sailing on 40 hours a week and the shoestring budget we’ve got round here, letmetellyou.)
To be fair, there are some perks: the stock standard health/dental package. They do chip in $150 a month for parking, so I guess that’s generous. They let the IT types have their own coffee pot, (we pay for all supplies,) and a futon in the office for the nights we don’t make it home. Way I hear it though, coffee pot and futon won’t be allowed after the office move, and parking is up in the air too.
Still it’s the best job going in these parts for IT folk; might just be why I’m trying to get out of IT.
"The effort is designed to shift attention to the underlying mistakes that allow vulnerabilities to happen in the first place."
After reading through the list, there is one obvious over-riding problem. That problem is the lack of proper programming education and experience when it comes to the vast majority of the kids working on today's interconnected systems, combined with the general ignorance of whoever it is that is signing off on the internet-facing code that they are producing.
Which leads to the question "Why the hell are management hiring wet-behind the ears kidlets, with zero internet "street smarts", to program internet-facing software that (potentially) will cause all kinds of trouble for the userbase?" (see: TJX for a rather gross example.)
The answer is that manglement are cutting costs in areas that lead to security issues, PROBABLY because they are absolutely clueless about modern day security concerns and are hiring purely on paper, not actual ability.
Corporations need to realize that they need both a people management track, and a technical management track, with equal importance to the business. Until that happens ... Well, let's just say I'm happy in my retirement, working my ranch sunup to sundown (and beyond ...), 7 days a week. The corporate world has been fucked for years WRT connectivity and security.
"Failure to Preserve Web Page Structure"
A tad specific, don't you think? Looking down the list seems to show a distinct leaning to specific programming areas; namely the "web" - [13] "Improper Control of Filename for Include/Require Statement in PHP Program".
Clearly, the "experts" who compiled this list are only "experts" in single and very narrow field. So basically, this list of "top 25 programming errors" is a waste of space for 99% of programmers.
Buffer overruns doing at #3, then?
Rather than just skim the list, I actually read the vulnerabilities, and while some do include JavaScript and PHP-specific examples, most of them contain Java, .NET, C, and C++ examples. Even the web-specific issues reflect on good programming practice for "traditional" development.
Did you even consider that perhaps web-specific errors show as much as they do because that's where the majority of newbie development is happening? In fact, given the % of development happening on the web vs on "traditional" programming" and the purported level of training required for each, the number of non-web issues showing on the list indicates that your "99%" of programmers REALLY need to read the list, because they obviously STILL HAVEN'T GOTTEN IT despite having had 4 DECADES to figure it out!
You're over thinking things a bit. The reason that web vulnerabilities are so prevalent is that this is a list of the top 25 most prevalent security bugs and, this being the age of the internet and all, websites are the front door to most networks. It's simple really, you don't start breaking into someones network by cracking their internal payroll system, you do it by exploiting a flaw in some web facing application, which invariably means cracking a poorly written PHP, Java, or .NET site. Once you've got your foot in the door so to speak, then you can worry about mucking with more traditional systems. Of course the variety of worms, trojans etc. making the rounds also contribute to the prevalence of more traditional vulnerabilities (E.G. buffer overflow).
Another way of thinking about it is in terms of surface area, which for a program is the amount of the code directly, or indirectly but shallowly, accessible from the internet. Web applications by their very nature have a very large surface area, where traditional applications tend to have a much smaller surface area. To use a popular target as an example, Adobe Reader has a relatively small surface area requiring the user to first download or view a malicious pdf file, but that small surface area is mitigated by the prevalence of the software, as well as the tendency to embed the viewer inside web browsers thereby increasing its surface area (by reducing it's depth).
And what is the best way to make sure your dev team are up to speed on security ? Training.
Who are the best people to provide this ? Sans.org of course.
Advert posing as a serious study. It's like malware.
As mentioned above "you get what you pay for" ... of course this report suggests that you can get cheap inexperienced coders ... as long as they are trained.
Any firm that leaves quality, security, etc to the software vendors deserves a punch in t'gob for being naive.
#1 Failure to Preserve Web Page Structure
¿Programming? The mind boggles.
The real programming errors are nothing that a little experience won't put right, however, if junior developers are not allowed to make those mistakes they will never learn from them. As an example, just earlier this week my son spent hours on a university project trying to figure out why his program froze at a particular point. He eventually swallowed his pride and asked me to take a look. I saw the error in a matter of minutes, it was on the list. Furthermore, it wasn't directly related to the place where the progam was freezing, looking away from where you think the error is, is also something juniors need to learn.
It's all very well to say that errors shouldn't be made but in practice it is virtually impossible to account for everything an end-user will try do with a program. Bugs should be found in testng and the testing phase should include a "throw everything at it" approach to simulate what users might do, not what they are supposed to do. Quite often testing is reduced to inputting a few test values then checking that the output is as expected.
Remember, if your code is idiot proof it's only because the the right idiot hasn't come along yet.
Rather appropriately it appears that www.dilbert.com has been hacked this morning and is serving up a dodgy virus scanner instead of some pithy 3 pane comment on the IT industry.
Don't go there, especially if you've set your browser to 'download everything and infect me pleaase'.
For websites I have to fulfil two requirements:
1) Does work on the 'happy path' in IE?
2) Does it look pretty?
That is all.
I would love to be given the time and training to ensure that stuff is secure (probably best tested by an outside contractor to be honest) but it won't happen. The money people don't care and will not allow the resources as there is no visible benefit. Right up until a law suit lands.
Then it'll be my fault (despite having asked time and time again to consider security...)
It's depressing.
I don't know much about security, but I at least know enough to know that I don't know much. Which is better than most managers. I have met. Most just don't give two shits. And it's developers who have no authority to do anything about it who get it in the neck time and time again.
Are you a manager? When was the last time you SPENT SOME MONEY ON TRAINING? £4,000 may sound a lot, but it's a damned sight cheaper than having your ass sued off! If you want experienced devs, good products, quality, then feckin' TRAIN US! And don't bitch and moan when we get it wrong because (despite our best efforts) we get NO SUPPORT from dickwads like you.
End of rant.
If you want a job, sit back and carry on bleating as you are. If you want a career, get off your arse and train yourself, it can easily be done on your employers time. Hands off training is a complete waste of time and money, it's only useful purpose is to make employees feel they are valued.
That'd be nice start. Let me know when reality hits your planet.
I train myself - it's not easy to do at all. Having to buy the books, kit etc is a serious financial outlay that is often hard to meet. Having to give up other hobbies (there is a life beyond the CRT, y'know) is also a serious sacrifice.
When picking up a new skill I support to make sure I know what pitfalls to avoid before I have to fall down them myself (like leaving sites vulnerable SQL Injection, for example). So that means someone who has does it time and again and will pass their skills on. That is the value of the "hands off" training you seem to think is worthless (personally I'd rather it was mentor based and on-site).
But no - all one gets are attributes like yours. Obviously working 9.-5 (and more, unpaid) simply isn't enough for some folks.
>personally I'd rather it was mentor based and on-site
Fair enough, I forgot about that as I was thinking training courses, you are correct, this is the best way to learn but I wouldn't strictly call it training.
However, with regards to employer's time, I doubt anyone puts in 100% of an eight hour day, not even close. There are always lulls. I'm not suggesting these shouldn't be filled with reading websites nor contributing to forums, these are both time honoured work related activities, merely that some of that time could be better employed to improve oneself. There are myriad ways that you could include a small personal training project into a working day.
One other thing, if you value yourself, don't do unpaid work.
You say there are two types of people in this world: two types of people in the world, those who do and those who moan about them. Only two types of people, eh? Seems I might break your little black-and-white view of the universe.
I work for a living, 12-18 hours a day. I have a roof over my head for now, (and I am grateful,) and even a few shiny knickknacks and toys. I've worked hard for everything I have, but I still live paycheque to paycheque and put in enough hours at work to actually require a cot in my office. I would consider myself as someone who “does,” and isn’t afraid to put the time and effort in required to get things done. Yet, I still complain about the state of the world, so where does that put me in your view?
I don’t treat my staff like dirt, and I don’t ask anything of them I wouldn’t be willing to do myself. I give them the opportunity to make mistakes and I defend them vigorously around budget time. I fight for their raises, and better working conditions, I even manage to find time to volunteer at a couple of worthy causes outside the office, and make my varied donations.
When I look at the “management” folk, either higher up in my organisation or in other organisations around the world, I am sickened. (“Consultants” have a similar effect.) With some notable exceptions, they are greedy, self-centered little $expletives who will cheerfully ruin the lives of thousands of people for a small quarterly bonus. These folk certainly don’t lead by example; asking way more of those they lead than they are remotely willing to give in turn. They are constantly seeking the cheapest candidates who will work under the worst possible working conditions just to save a few bent coppers.
I am perfectly aware that the world isn’t so black and white as all that. People fall along a spectrum. On one end folk so charitable and self sacrificing they can’t look after their own selves. On the other end people who are so self-obsessed they can cause the deaths of millions for meagre personal benefit with a smile and a flip comment about “survival of the fittest.” What I rail against is a society that holds those close to the latter end of that spectrum up as role models, as though short-sightedness and selfishness were exemplary behaviour.
The world doesn’t owe me a living, but by $deity it could use a conscience.
From reading your posts it seems like you are allowing people to treat you like, as you say, $expletive. 12/18 hour days, being paid only for 40 hours, 24/7 on call using your own phone and whatever etc, etc... is. Quite honestly I can't believe that you have staff, however if you do and that's the best conditions you get for yourself then I dread to think how you can get anything better for them and how they can look up to you as a role model. You seem to have done little more than a lot of moaning under the guise of how wonderful you are.
I oversee a small department, be the company doesn't belong to me. I won’t ask my staff to work any more hours than I do, and I do my absolute damndest to make sure *they* at least get to make up their overtime elsewhere. (Legally there is no requirement for sick days, for example. I ensure they are not recorded, and am flexible about staff leaving early, etc.) I do my best to make sure they don’t have to bear the brunt of crappy upstream decisions. They better rested they are, and the better their spirits, the more efficient they will be.
I’d also like to point out for the record that I never said that I was wonderful in any way. I consider myself an "average guy,” no more or less selfish or giving than the folk around me. My complaint is that it’s those who tend to be the self-focused greedy $expletives who end up in charge. (Says all sorts of lovely things about our society, don’t you think?) The average working man, at least around these parts, tends to be a good sort.
As to "allowing people to treat me like $expletive," there aren't a lot of options around here. As much as I might gripe, it really is one of the best deals going for IT guys in these parts. (The guys that get gigs with the municipalities are all unionised and thus working there is pretty sweet...but job openings are rare and exceptionally competitive.)
There just isn’t a lot of work to be had. The power isn’t in the hands of the workers, it’s in the hands of the businessmen. There are far more IT people here than there are jobs, and frankly that seems to hold true for almost every industry I can name. I live in a metro with a little over a million people. There’s another metro to the south with about the same. There’s nothing else for 800km in any other direction. Ever major company (and even some municipalities) have been outsourcing to India or the Philippines. The only real work available is with the smaller shops, and as soon as they get big enough, they outsource.
You can cast aspersions on me all you want, but I still maintain that treating (and paying) people well should be the cornerstone of our society, not rabid self-interest, greed and idolising those who step on the backs of others to achieve their wealth. I'm sorry if that rubs your ideals the wrong way.
is that your way of doing something about being treated badly is cry and tell everyone how they are wrong. All of your posts assume that you are "normal". Well, wake up, your not. Your letting yourself get treated like crap.
You think everyone is outsourcing, but the fact is that it is still a very small number of companys. It sounds more like you just don't have the spine to go and look for a new job, or the stills to move in to another area.
You make a fair bit of unfounded assumptions, and like Chris W seem to believe the world is binary. Black or white, on or off. You are either doing something about it, or bitching about it. Oddly enough, it's entirely possible to do both, and life is very rarely so simple as to be binary about anything.
Where I live and work, most companies *are* outsourcing. For that matter, it’s a pretty big thing in various states in the US as well. Even where they aren’t outsourcing, many places are using the threat of it to drive down wages and working conditions. There are certainly places in this world where that isn’t true, and once my personal obligations are no longer binding me to this place, I do very much so hope to move to somewhere better. (Not everyone is so self-focused they are willing to screw everyone around them for personal benefit. I have commitments to keep.)
Not only am I out beating the streets for a new job, I am taking part in my political party to try to get actual change in the laws put through. I attend and do speak up at various industry organisation meetings, and pretty much anything else I can find where I have a chance to make an impact on the actual policies and regulatory structures of my country.
As much as it may seem to you I let others walk all over me, I really don’t. I fight for what I believe in, and if I didn’t, I’d still be working in (literally) a closet for an IT office as I was 5 years ago making less than half what I do now.
If you, AC, or Chris W, or anyone else have a great job with no worries in life I wonder how you got there. Was it because you are so innately better than everyone else? Plucky and spunky and possessing DNA without flaw? I really doubt it. Some of it has to be innate: to get anywhere in life you need the chutzpah to speak up for yourself and to stand out. There are other elements though: the hundreds, even thousands of people who went before you, standing up for workers rights and trying to keep businesses and governments honest. Perhaps you merely are without conscience, and soullessly stepped on others on your rise to the top. I don’t know, and I don’t really don’t care.
In the meantime though, while I am willing to fight for what I need…I honestly don’t believe people should have to. If you are willing to work hard, you should be able to earn a comfortable living. Time taken out for training should increase the level of that comfort. Forget all the fuzzy pink bunnies and hippy-happy reasons; I’ll give you the single best reason out there to keep your staff in good repair:
Every second your staff spend looking for a new job, fretting about their finances, campaigning for better working conditions or taking part in their political process is a second they aren’t doing one of the two things that make you money: working or relaxing. Relaxing keeps those workers sharp when they are called on to work, and a clear mind with no worries helps keep them focused. Happy, calm and focused workers are more productive than ones who are constantly looking for the next best thing. Retaining these workers is to the benefit of any business as well, as they are already trained, and familiar with the needs and flows of your organisation.
Of course this requires businesses, managers, politicians and even individuals who think “long term” and “big picture” to recognise. None of the above concepts mean a damn to members of the Cult of the Quarterly Bonus.
Whatever you believe, have a good weekend AC. I know I will, I just got a good Friday lunch-hour rant in.
Dear Beelzebub,
I don't know why you ask but just in case you think some other poor sod might be me then I'll answer. No, I don't work for CSC, not now nor ever.
>If you, AC, or Chris W, or anyone else have a great job with no worries in life I wonder how you got there.
I can probably speak for both of us when I say that the answer is we don't take $expletive from anyone.
Many thousands of people have crossed seas and continents, in many cases paying what to them are huge sums of money to less than savoury characters. They put themselves and quite often their family in debt and risk their lives using less than safe methods of transport. Many of them have died in their attempt to make a better life for themselves, others, knowing this still follow. Yet you won't make an 800km journey which to these people would seem like a ride on a cloud. One other thing, you can always return in safety from that 800km, for the others it is a one way trip into the unknown. Any one of these people have got more get up and go in their little finger than you have in your entire body. I honestly hope for your sake that Trevor Pott is not your real name because any future employer that can link you to your comments will throw your application straight in the bin.
Well Chris you are (in your mind at least) a far better man than I. I'd argue the point but we both simply care about completely different things. I acknowledge that people have "crossed seas and continents" and blah blah blah to make a better life for themselves. My grandfather was one such; after the war left his home country devastated we came here.
I look at things a little less black and white than you appear to though. Those people, when off “looking for a better life,” they generally do so when they have absolutely nothing left, or no chance of ever supporting their families where they are now. Shocking as it may be to you, there are perfectly valid reasons I can’t and won’t leave everything and everyone behind right at the moment. I have familial obligations, as well as friends who (at the moment) rely on my support. For that matter, my second-in-command at work has recently spawned an offspring...leaving him in no shape to take over the late-night duties or demanding hours I currently pull. There are several other commitments I have made that I simply can’t just walk away from. If you really are the kind of person that can abandon people who rely on you, I feel sorry for anyone who might come to know you. As much as I very much would like to improve my means, I won’t do so at the expense of others.
As to this being my real name, yes it honestly is. Here for the entire internet to see: there are people and ideals in this world that matter to me more than money, and more than my own sweet salient self. I honestly believe business should pay their staff well, and provide the best possible working conditions; in my opinion this produces the best results and value for money. I believe in leading by example, not through fear, or intimidation. If there is an employer out there who is reading this thread and decides that employing someone like me goes against their business style, then frankly they aren’t someone I’m all that interested in working for. Some employers build their relationships (with staff, suppliers and customers) based on honesty, loyalty and integrity. I admit these businesses are getting few in number ever year...but these are the types of businesses I seek out.
In the meantime Chris W, I’ve got a stupendously busy week ahead of me, and absolutely no time to devote to more back and forth in thread. I concede to you this argument; I accept that in your eyes I will forever be weak and pathetic, your personal methodology being superior to you in all possible ways to mine own.
I wish you all the best. Your ideology and philosophy seem to be quite in line with the Cult of the Quarterly Bonus, and I hope this allows you to reach the personal and professional heights you strive for. Certainly there are enough corporations where this seems to be The Way Of Things for you to do well. Have a pint on me, and enjoy the sweet taste of e-victory.
The proposal is that the development company will be liable, not individual developers.
None-the-less, it's a complete load of ivory tower bollocks, as others have noted.
It also appears to be rather rabidly against free software, in sentiment. How does the Linux kernel get all its developers background-checked? In fact, what organization would be able to sign such a contract at all in respect of Linux? In the brave new world of hyper-secure software, we'll all be using Windows again?!
SANS, just publish the 25 top fails, and STFU.
Perhaps this will force companys to employ real programers rather than some kid who made a few web pages and wrote a bit of actionscript.
I have 4 friends in IT, and only one of them has any formal training, and he's in sales FFS. The other 3 make it up as they go along. They have no idea about proper structure or documentation. As far as thay care as long as it dose the job it will do, and screw anyone who might want to look at the code later.
Its about time programers were seen on the same level as engineers, then perhaps the world would be a better place, and maybe they need pushing, but holding them to the same standards.
That little factoid just depresses me even more than I already am, that 3 people in IT just make it up and fumble along as best they can
And that I cant get a job in IT with 20 yrs in industrial robots, qualifications from the OU, and a damn good knowledge of 8 bit asembler code.
My depression is lifted though by my anger at the "buffer overflow" bug, or "array bounds checking" bug, come on people... this is 2010.
But then maybe its the managers saying "we have'nt got enough time inside your buffer writing routine to see if its over run, so leave out the checking"
Perhaps every programmer should spend a year writing life critical software like flight control systems , or industrial robot control programs.
That would seperate the good from the useless.
However..... would I want to fly on a plane or operate that robot afterwards.........
Management still has nothing but deadlines/money (security are people that watch cctv monitors) in mind, for example, a company owned by a Australian with a Scottish name, bought D/C racks to run automated tests in an attempt to up the abysmal quality rate of their HD STB. The pointy haired manager, decided that the code written by developers would be maintained by help desk staff with no programing training. To effect this cunning plan, "none of that programmer nonsense" like design, structure, meaningful identifiers/ OO / unit-tests or indeed tests of any kind, would be used on a code base that provided OCR/Image recognitions over a network while attempting to compensate for latency when simulating user interaction with set top box.
I walked out at the end of the first day, never to return, the other chap who'd foolishly taken a little longer to notice the smell of fail emanating from the boss's office, stayed a month, by which time the project had failed, and the manager been promoted on the back of his *genius* cost-cutting plan.
So it's hard to find decent employment, but I'm largely self-taught, did a couple of City & Guilds software development courses back when they offered Unix/C++ and Portable/C qualifications. (circa 1999) Got my first contract completely by chance, loitering outside an internet cafe, ended up chatting to a random, a cyber-squatter/domain broker, and hacking out a little application, a grand for a weeks work, he made rather more with the software but that's life. Since then, I've written encryption software for the embedded market, parallel processing software for the HPC market, and for my sins financial software (never again).
I've written polished, unit/integration tested code in C, C++, Perl, Ruby, Java, Python, Pascal(Delphi) and Sparc/x86 Asm (these tend to be inline in C apps, rather then complete asm except for the smallest of boards). I've also written really shonky code in VB and made all the mistakes on the list in various languages, including a major missing one: not *just* writing the simplest code that would work, on the basis it'll come in handy at some unspecified time in the future. I've also spent some big chunks of time out of work, but I use that time in developing my skills and underlying codebase. ( I've some interest in code generation/ toy compilers) So long as you know what you're doing, and you keep your head up, it'll be ok.
As for industrial robotic skills, are you any where near bristol? There's always people looking for embedded / industrial development staff round there.
as the title, sed.
Beer for the west country pubs.
Several of the items in the list used to be called exploits. Now they are programming errors. Is there a danger of shifting focus from the real villains here - the exploiters?
If it is legitimate to blame the coders, when do the ISPs, hosters of all these error-filled webpages, have to take any responsibility for what they allow on their servers?
Web design = coding ? Bleh
Most of those 'vulnerabilities' could/should be fixed at a lower level so sloppy coders can't break anything. Try pestering the language/platform makers to be more secure in the 1st place - not the poor saps trying to make the best of insecure tools available to them.
The rest is a matter of you get what you pay for - hire experienced staff and train them properly. You won't get the contract if you do though - the sweat shop next door will undercut you.
In other news: Software vendors agree a contract to stop night following day [small print: or shift the blame when it does]
I just looked at the examples on some of these - like the PHP include/require one - and thought, "oki - that might be a serious vulnerability but who the hell in their right mind would actually do that?"
Then I remembered some of the god-awful, shonky, half-arsed, crap PHP code I've seen over the years and sighed. If web-devs want to stop being mocked by "real programmers" it might help if they actually put some effort into learning their trade properly - there are some very good web-devs but there also seem to be quite a few feckless tossers who really couldn't care less.
Having said that though, "real programmers" often make the same mistakes as many "web-devs" (when they're forced to write web-apps); lack of ability to write good (X)HTML/CSS and forgetting they're coding in a warzone where they have no control over user-environment or interface software (browser) and everyone from here to Dubai and back again can have a crack at breaking your system.
Paranoia is not a mental health problem when you code for the web - it should be a way of life :)
Your ideal web-dev should be an expert in server/client architecture, able to write, optimise and load-balance applications, be a security expert and part time lawyer (your system needs for conform the DPA and DDA legislation in the UK)... so it's not surprising maybe that the good ones are really good (and rare) whilst the poor ones are awful (and in plentiful supply); considering a web-dev will earn maybe 50-66% of that of a Java programmer for example...
Part of the problem is that companies have been lead to view software as a commodity product, to be bought off the peg and customised, rather than something designed and tailored to the individual business' needs. Unfortunately the licence generally exempts the supplier from any liability if the software doesn't perform, while preventing anyone from fixing it in-house.
It's the same mentality as the chav putting a bean can exhaust on his Vauxhall Corsa and expecting it to perform like a Ferarri! Quality costs more upfront, but pays for itself in the long-term.
This "holding responsible" thing is the greatest idea ever. But why stop at developers?
Let Microsoft, Apple, Adobe. Symantec, Quicken and a raft of others be held responsible for material losses incurred as a direct result of their software not coming up to snuff, not matter what weasle words are written in the EULA.
Let those insidious wreckers of reputations, the credit bureaus, be held responsible for the crappy state of their records and the reprehensibly wide latitude in their queries used to construct the credit reports that are forwarded to banks, employers, police etc. I've never seen such shoddy work.
Let the IRS be held responsible for proving what they allege as to your financial cheating of the state *before* they are allowed to enact draconian measures to "ensure compliance".
Let idiots who ignore the noises coming from an apartment and the obviously battered appearance of a child who lives there for years , then criticize the welfare authorities and/or police when that child is killed by a "guardian" take responsibility for their callous disregard for the consequences of their "minding their own".
Let jurors take responsibility for their verdicts without the now-mandatory "not *my* fault" interview on national TV after the case is over.
Let the Police rather than the taxpayers take responsibility for monetary damages awarded in respect of injuries sustained as the result of misconduct. Let people sue the pension funds instead of the state and the blue wall of silence would soon crumble.
By jimminy, this anything but obvious idea has legs!
For any real programming issues on that list, talk to an embedded software engineer. Especially talk to anyone who's ever worked at higher SIL levels, or DO178B, or similar high-reliability systems.
It'd be nice to be able to report that it's easy. It isn't - it's a constant battle, all the time. But a standard QA plan for high-reliability software sets out how the battle will be fought, so that the chances of a bug making it through are as close to zero as humanly possible. The downside is that this costs money. A lot of money. Multiply your worst-case coding estimate by 10, and you've got the total time it'll take for design, coding, reviewing, testing and auditting.
But there are still no-brainer solutions to a lot of problems. Static analysis, for example - if you're coding in C and you're not running Lint (or equivalent) on your code, you're preparing to fail. Or incomplete requirements - if you're sending stuff over a serial link and your spec doesn't say what the endian is (been there), you're preparing to fail. Or testing - if your test spec doesn't quote a source requirement for every test you're doing, and if you haven't done a cross-reference to make sure your test spec has at least one test for each requirement, you're preparing to fail.
If you're going to treat coders like doctors and sue them for malpractice, you have to give them the absolute authority to do it right. That means the authority to determine how long it will take, and what techniques and tools will get used. The coders don't make those decisions now, except in a few rare instances, management does-- in the name of "getting the product to market in a timely fashion."
Not only that, coding is a team effort, and often ancient preexisting code and libraries are foisted upon coders who have neither the time nor expertise to fully understand what risks may be contained in their newly-found inheritance.
If you're going to treat them like doctors, they have to have the same sort of authority, the authority to actually make the decisions relevant to their responsibilities. And you'll have to pay them about three times as much. Any takers? I thought not.
Lol.. this article lists a bug that allows cross-site-scripting as the most _dangerous_ coding error.
I work as a software developer on avionics systems. Some girlie little website bug is never going to be considered even slightly dangerous compared to what we can screw up.
Microsoft seems to be on a crusade these days touting their own process security. This study seems more FUD on that line. Follow the money.
The ideas exposed are bordering on the ridiculous. I'd like to see Linux kernel developers lining up for background checks. And guess what is the prevalent platform for the gears that power the tubes of the Internet nowadays?
C'mon guys, I know there are a lot of real techies here. Aren't you just the least bit sick of "developers" who wouldn't know a pre-test from a post-test loop? Managers who don't know the difference between a web server and a mail server? As a computer scientist, I've seen the industry go to hell in a handbasket, and it's not just due to the Indians. Tell me you haven't seen a complete dunce get employed just because they know the hiring manager? I've seen History graduates, secretaries and frickin' carpenters hired as IT developers and consultants. Where's the quality under such conditions?
HP used to have a policy that only people with computing degrees were employed within the company. (Okay, they also had one against hiring women, but let's just go with the positives for the moment.) I say we get back to that and maybe claw back some of the self-respect that disappeared when our promotion got given to someone who could swim 200m faster than anyone else. Bitter? Not much.
#1 is cross site scripting.
Which only matters in a *web* environment.
20 years ago (I'm guessing) they'd be looking at memeory management (particularly unassigned pointers and memored which had been freed before last calling, mostly in C)
Things change. had Borland included function pointers (Yes full Pascal *does* allow you to construct a table of functions like C) before (IIRC) version 5 perhaps the world would be a *very* different place
Mine's the one with "Code Complete" in the pocket, which demonstrates that construct.
If memory serves, the syntax is something like the following, been years since I touched delphi so this might all be way of base.
What's code complete say on the subject ?
type
TFunc = function (n: integer) : integer;
TFunctPtr = ^TFunc;
TFuncTab = array[0 ..1] of TFuncPtr;
var
fptr:TFuncTab;
function my_square(n:integer):integer
begin
my_square := n*n;
end
begin
fptr[0] := my_square;
fptr[0](10);
end.
But Borland did -
Delphi event model processing is based around pointers to "functions/procedures on a object instance" and hasn't changed since version 2 (probably 1) and is I believe an extenstion of the pascal function pointers (I think was in turbo Pascal - but as I haven't used it for > 15 years really can't be 100% sure)
Devs do what customers pay them to do, not one bit more. Hold the system owners responsible, preferably with high costs associated with security breaches, and devs will automatically be tasked with increasing security. Setting up development standards in a vacuum is not going to change anything at all. But of course, if you're sitting high up in an ivory tower the dirt and drudgery down here on the ground looks quite random. Whip the bastards, that'll teach 'em to code right!
Would do a GREAT deal of good.
It is like these developer are working in a vacuum ... not hired by anybody that does not impose them the langage the schedule the training.. just evil incompetent devils ...
Remember the DMCA and such .? they BEFOREHAND remove software company from liability something we would not accept from any other industry (Toyota mess anyone ? )
Maybe THEN we will see a move to memory managed langage that would remove 80% of those bugs and vulnerability, and see a better emphasis on doing it RIGHT before doing it NOW.
NOBODY asks you to do it right in a development team, the security and quality is something you have to shove in yourself on top of the workload even if that quality would pay down the road in support and maintenance it has ZERO priority so it is like blaming the rail worked for the route of the railroad : he could put the rail more solidly in the ground sure but only IF he was not asked to do it on sand.
And to have those thing changed, software shops need to be responsible of the damage they cause like any other industry.
I need NONE of the "new" capabilities of office 20XX I would prefer to have it more logical, simpler to use and safer, and that goes with Operating systems and all the rest.
Drop C and C++ for christ sake, this is NOT a professional langage, just a glorified macro assembler.
First off, Memory management is *not* the issue with C/C++, *concurrency* is the issue, and that`s
solved by using concurrent languages (erlang etc) not a garbage collector.
You can use *deterministic* finalization to have the stack manage *allocated* memory using RAII patterns, 'C' also lets you do this with a bit more work ,try that in say, java, oh wait no deterministic finalization.
I'm a fan of V-HLL (ruby/perl etc) for lots and lots of things, but Language as panacea for bad resource management whether the resource is memory/db connections/sockets/threads/files open etc, is unhelpful in my view.
Finally, there are huge amounts of existing code in C/C++, you want to rewrite/wrap it all in some managed language de jour, go right ahead.
C/C++ are languages that you build your layers on, if you use the naked stdlib/stl you'll end up making more mistakes then if you write a handful of decent wrappers, like the following for realloc.
Almost all the stuff on the list in every language comes down to design issues, you can't get rid of error but you can design out most of the causes, aside from users.
/* Resize a chunk of memory obtained by a previous call to malloc()
* The behaviour is different to stdlib realloc in that 'old' is always freed
* Null pointers and zero sizes are not supported, use malloc/free directly if that behaviour is
* ... desired.
* This means that p = utility_realloc(p,size) is safe while as we all know
* p = realloc(p,size) is a leak waiting to happen
* On success: Returns a pointer to size bytes of uninitialized memory freeing 'old'
* On Failure: Returns NULL on failure modifiying errno AND freeing old.
* EINVAL: invalid args passed, 'old' is null or size is '0'
* Function may fail and set errno for same reason as realloc()*/
void *
utility_realloc(void *old,size_t size)
{
void *p;
int err;
errno = EINVAL;
if(!old || !size)
return NULL;
/* old is freed on success */
if((p = realloc(old,size)))
return p;
/* old is not freed on stdlib realloc failure */
err = errno;
/* it is now */
free(old);
errno = err;
return p;
}
Thank you for your reasoned and well thought out critique, you have a genuine flair for language and the sheer variety of your response was most refreshing. ;)
Well since you ask java doesnt' do deterministic finalization because
Java's designers made design choices in the generational G/C to not equate garbage collection with destruction,
This means
1) post/GC objects can become reachable again, in a rise from the dead leading to all sorts of fun and games in unwary code.
2) JVM prefers to dump all memory on exit(i.e. without finalizing) rather then run GC if possible, fast path with no finalize stub rather then slow finalize path which might never run but adds overhead anyway.
3) language scoping rules can't be used to implicitly bound object lifetime imposing implicit ordered finalisation (see point two), it has to done explictly using weak references making some useful design strategies cumbersome to implement,like say throttling a resource using an object reference counts(think peer nodes associations) to dynamically drive load management in a distributed system, additional ref, extra notch on the power, one less reference, means you step it down, scope managed ref counting is a nice way of implementing that sort of throttling principle
Try that with a java generic, add_ref() on construction is easy, how do you make sure release() is *always* called *for* you rather than *by* you, can you sure you caught every edge case? is it exception proof?, how easily can you test it?
I use whatever *tools* work best for the *job* in hand, I'm not picking on java so much as saying
4) *Memory* is no different from any other sort of *resource*.
5) Strategies exist in languages with determinstic finalization e.g. allowing resource management to be implicitly bound to object lifetime with the language doing the work rather than the developer.
6) A data point, there are plenty of garbage collectors for C/C++ yet GC is not that widely used for what ever reason, perhaps because of point five).
7) These stategies are examples of designing out problems rather than coding round them, using say explicit calls to synchonization primitives like mutexes.
8) Some of these strategies are less effective/more difficult to implement without language level support for deterministic finalization, hence the java reference (had to do this before and it's a pain)
9) Most of the items on the secure coding list are design problems, for example failing to sanitize user input is really failure to have/use user facing functions that sanitizes input for you.
10) Realloc() is a source of leaks in C code because people treat it as "free(old); return malloc(size);" when it's really "return (pnew=malloc(size)) ? free(pold),pnew : NULL;"
11) The realloc wrapper I posted plugs that *really common* class of realloc leak simply by including a header with a macro, i.e. no source change needed
12) Exactly that realloc leak in the JVM no less http://gcc.gnu.org/ml/java-patches/2008-q1/msg00092.html ("fourth google result for 'ralloc leak'"), easy fix.. #define realloc utitity_realloc
13)I don't think resource/memory management too big a deal, so much as I think some interfaces need wrapping for sanity including my own sometimes, not too often I hope.
I'm not advocating one language over another just saying we need better implementation designs.
Memory *really* is just another *resource* is it not, and almost all the coding flaws on the list come down to bad design, whether architectural/interface/implementation.
Granted some library interfaces in C/C++ are easy to make mistakes but as I said wrap them with
the safer/saner interface of your choice, why throw such a flexible tool away simply for the lack of using one of the thousands of decent library interfaces for what ever resource management issue you have, or here's a thought write a C/C++ extensionn for perl/ruby/python whatever and get the best of both worlds, memory managed access to all the C/C++ libraries through a thin shim layer.
14) Shared Memory Concurrancy, even with automatic management of resources, and all the tools we have is a right pain, it's even worse
trying to do anything even vaguely realtime and parallel that way in C/C++ for a few reasons, some of which are changing with boost/c++0x , but some are basic language issues.
The dominant model with c/c++ is shared memory concurrency(pthreads and the like) and everyone does it slightly differently, scaling to large numbers of cores/gpus cries out for language/library support for expressing something as clean message passing co processes without having to manage the details of the concurrency explicitly or give up the portability/expressiveness/compatibility of C/C++.
As I said previously, I think concurrency is the issue, those "muppets" over at intel, seem to agree that language support is needed http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/
you've heard of Intel right?
I don't have memory leaks, I have spread work across distributed processes issues, erlang solves that for me by inconnecting C/C++/whatever consumer/producers and letting them ignore concurrency completely, this thing from intel looks interesting too.
wow that was far too much.
> Thank you for your reasoned and well thought out critique, you have a genuine flair for language and the sheer variety of your response was most refreshing. ;)
Positively Wildean, I grant
> Well since you ask java doesnt' do deterministic finalization because [reasons]
It's more complicated than you made out. Generational, Mark-sweep, compacting -- none of these can immediately pick up all dead objects. The only thing that can approach this is reference counting which has other problems (speed, overhead), and still can't make immediacy guarantees (consider cycles).
More: <http://msdn.microsoft.com/hi-in/magazine/bb985010%28en-us%29.aspx>, look for "There are several reasons for this" for a summary, but this doesn't do justice. Conflating garbage collection and object finalisation was recognised as a bad idea back in the 80s by Modula 3's designers, but Java's creators were too witless to learn the lesson (like so many others they fail to learn), so Microsoft had to follow on and we all move backwards, again.
> think peer nodes associations
I would if I knew what they were.
> 5) Strategies exist in languages with determinstic finalization e.g. allowing resource management to be implicitly bound to object lifetime with the language doing the work rather than the developer.
I think you are thinking of C/C++ where object lifetimes are explicitly and sharply delimited by free() or implicitly by subroutine returns. It is reasonable, I suppose, to ask that Java provide some kind of equivalent to smart pointers so things happen automatically on subroutine returns, but there's not much you can do about other objects you intend to have longer lives. If you want deterministic deallocation for "local" variables, you have to wrap a try/finally around the routine body.
> 6) A data point, there are plenty of garbage collectors for C/C++ yet GC is not that widely used for what ever reason, perhaps because of point five).
These are conservative garbage collectors (I'm sure wiki has an article. Read up on them and have nightmares) and they don't provide the behaviour you are asking for.
> 7) These stategies are examples of designing out problems rather than coding round them, using say explicit calls to synchonization primitives like mutexes.
I don't know what you're saying that I have a tendency to build frameworks to hide grubby detail in the same way that you suggested wrapping realloc(), but typically on a bigger scale. I guess that's easy to say though.
13)I don't think resource/memory management too big a deal,
then you're a better person than I.
> or here's a thought write a C/C++ extensionn for perl/ruby/python whatever and get the best of both worlds, memory managed access to all the C/C++ libraries through a thin shim layer.
I don't see how this would get you the kind of deterministic memory management you want.
> (Stuff about concurrency)
I'm not saying that concurrency was easy or irrelevant, only that you were speaking too generally, and if you like Erlang's model, perhaps you should recognise that it is a model and not a language, and see if there is a framework to support what you want. Perhaps this is of interest <http://www.google.co.uk/search?hl=en&source=hp&q=actor+framework+%22c%2B%2B%22&btnG=Google+Search&meta=>
> (re. erlang) I don't have memory leaks,
Hmm. Is that because Erlang has a garbage collector?
> erlang solves that for me by inconnecting C/C++/whatever consumer/producers and letting them ignore concurrency completely
if it's that simple, why are you using Erlang? Just for producers/consumers? I'm missing something.
If you want deterministic finalisation, here's how to do it: work out the exact rules that fulfil the requirements, then slap a preprocessor over Java to provide it. How's that?
> Well since you ask java doesnt' do deterministic finalization because [reasons]
>It's more complicated than you made out. Generational, Mark-sweep, compacting -- none of these can immediately pick up all dead objects. The only thing that can approach this is reference counting which has other problems (speed, overhead), and still can't make immediacy guarantees (consider cycles).
>More: <http://msdn.microsoft.com/hi-in/magazine/bb985010%28en-us%29.aspx>, look for "There are several reasons for this" for a summary, but this doesn't do justice. Conflating garbage collection and object finalisation was recognised as a bad idea back in the 80s by Modula 3's designers, but Java's creators were too witless to learn the lesson (like so many others they fail to learn), so Microsoft had to follow on and we all move backwards, again.
Agreed, more to it than meets the eye.
Re Actor, I've come across that before, but thank you for the link.
Re Design/Frameworks/language stuff,
I suppose my point is just that most errors security or otherwise are design flaws that can be eradicated if you want to throw enough time/money at the problem.
The MSDN link has a nice example on it, take this part when referring to c# finalizers vs c++ destructors "Don't let the identical syntax fool you." (this is a design flaw, two separate concepts that are easily conflated, with the same syntax)
Re Erlang/Concurrancy
It's more that there are messages buses like rabbitmq that do the heavy lifting, I'm know you can do the same thing in other languages but this works out of the box for my application needs YMMV.
Using a message broker e.g. rabbitmq, just makes the producers/consumers simpler to write, they aren't aware that erlang/rabbitmq is used.
nice. that aside, it's quite a balanced article, again ta for the link.
Re java pre-processor,
I made a crude attempt at this years ago (pre-java generics), using java as the output from a simple generation language that added explicit calls to allow *more deterministic* code. Generics replaced 95% of the benefit of my little tool, so I mothballed it. But using Java pre-processing is already here, I think (too lazy to verify) at least one of the google tools pre-processes some other language into java, and annotations while not preprocessing in the trad sense surely blur the line.
using C++ would work too.
> think peer nodes associations
this patent troll explains it quite well http://www.faqs.org/patents/app/20080307094
> 5) Strategies exist in languages with determinstic finalization e.g. allowing resource management to be implicitly bound to object lifetime with the language doing the work rather than the developer.
>I think you are thinking of C/C++ where object lifetimes are explicitly and sharply delimited by free() or implicitly by subroutine returns. It is reasonable, I suppose, to ask that Java provide some kind of equivalent to smart pointers so things happen automatically on subroutine returns, but there's not much you can do about other objects you intend to have longer lives. If you want deterministic deallocation for "local" variables, you have to wrap a try/finally around the routine body.
I was, and I accept that smart pointers won't solve everything.
> 6) A data point, there are plenty of garbage collectors for C/C++ yet GC is not that widely used for what ever reason, perhaps because of point five).
These are conservative garbage collectors (I'm sure wiki has an article. Read up on them and have nightmares) and they don't provide the behaviour you are asking for.
I know what they are, cheers.
> 7) These stategies are examples of designing out problems rather than coding round them, using say explicit calls to synchonization primitives like mutexes.
I don't know what you're saying that I have a tendency to build frameworks to hide grubby detail in the same way that you suggested wrapping realloc(), but typically on a bigger scale. I guess that's easy to say though.
That realloc bug is present in a decent proportion of C code from compilers to virtual machines, that's a pretty big R-O-I for ~15 line of code, that designs out the error rising from the disparity between how people percive realloc() and how it's specified by the C standard.
Exactly as C# finializer syntax reintroduces the "realloc bug" by virtue of the disparity between how people percive "~foo" in C# and how it's specified by the C# specification/standard.
Design Again:
For example when you enter a numeric value in an application ui/ (This is more about preventing cockups rather than malice)
1) you can enter a number into a text input field then validate
2) pick from pre-verified data e.g. valid numbers from drop down.
13)I don't think resource/memory management too big a deal,
then you're a better person than I.
I'll take your word for it ;) but I only meant that shared resource management problems are well documented and understood, distributed resource/concurrency access issues are less well understood.
> (re. erlang) I don't have memory leaks,
Hmm. Is that because Erlang has a garbage collector?
No, it's because it's implements the non-shared state concurrency model in a functional language which *has a garbage collector* :)
Pint, because I need one, why don't you join me in raising a glass.
@sed gawk, as I'm not fond of beer and there's no whiskey icon it'll have to be the good lady . If you're interested in reliability, check this <http://en.wikipedia.org/wiki/SPIN_model_checker> which totally fails to explain what it can do, so try this <http://www.albertolluch.com/research/promelamodels> and look for 'deadlock'. One day I'll actually read the book I bought on it.
@jake: cheeky bastard, it's paris hilton for you too.
Annakan, really.
The language does not make the problem.
About 35 years ago I was working Assembler; not a nice guy language.
Not a language at all.
Your language is just an abstraction layer and just one that you know.
So bashing C or C++ is about like me saying that Pascal is retarded (but it is, dammit.) We have to do what we can with what we are given.
"Why did my creator give me two left hands?"
Thank you MarrCy Shelly.
(little insertion error check above; Hey Dave, it is still full of bugs; HAL.)
Because I have read it...
But still in software you expect bugs an insecurity. To say that nobody makes a mistake is just insane. Software takes time and in this case if you are to hand over all responsability to the developer then you need to increase the amount of testing. To garentee no problems, that could take a very long time which a lot of management don't like to hear.
Like others have said expecially in a team environment and with object oriented programming languages with use of inheritance. Someone could make a change and that could make what someone else has written insecure. So who would be in the wrong there.
I mean sure if you make idiotic mistakes then you will probably just be fired instead.
In what universe does a customer go to a vendor, and asks to buy their software, then tries to impose contractual conditions on how that software came to be written?
"I'd like a copy of Microsoft Office, written in Ada, using ClearCase for source control, developed entirely by US citizens who were wearing ties at the time."
Oh dear, I merely meant to point out that that the focus of any kind of concensus coding error list would shift over time and suggested what it *might* have been if it were compiled a couple of decades ago.
Yes I was aware that Delphi relies quite deeply on function pointers (as AFAIK did the original C++ macro processor that Bjorn thingy used to implement his language at Bell Labs).
My point was that Turbo Pascal dates from 1983, while Delphi dates from 1995 and AFAIK TP did *not* incorporate pointers (to anything) until version 5. This feature seems to be a *very* popular implementation idiom for C programmers. I speculated that had it been in the most common version of Pascal at *launch* the benefits of Pascal and the developers aproach (IDE, longer variable names, better type checking while retaining fact edit/link/compile cycle and availability of the compatible but better optimising Stoneybrook compiler) would have been obvious and the world would be a *very* different place.
Cracking my copy of "Code Complete" to page 276 onward. I'll be truncating code compared tot he book. I'm presuming you know when I'm skipping stuff as you know Pascal. The example reads records composed of multiple (and varying) fields by breaking them down to their individual fields and processing them. A new record type can then be defined as a list of fields to be processed.
Start by defining an enumerated type for the data field
Var FieldTypes = (FloatingPoint, Integer, TimeOfDay)
Define a "Procedure type."
type
HandleFieldProc = procedure
( FieldDescription: String;
var FileStatus: FileStatusType ):
Define an array of this type.
var
ReadAndPrintFieldByType: array [FieldTypes] of HandleFieldProc;
Initalise the array.
ReadAndPrintFieldByType: array [FloatingPoint] :=ReadAndPrintFloatingPoint;
ReadAndPrintFieldByType: array [ Integer ] := ReadAndPrintInteger ;
ReadAndPrintFieldByType: array [ TimeOfDay] := ReadAndPrintTimeOfDay ;
Not shown (in the book) is the master array "FieldDescription" indexed by a messageID number. consisting of a NumFieldsInMessage, FieldType and FieldName entries.
Setting MessaeIdx gives the following code.
MessageIDx :=1;
while ( MessageIDx <= NumFieldsInMessage ) and (FileStatus = OK) do
begin
FieldType := FieldDescription[MessageIDx].FieldType ;
FieldName:= FieldDescription[MessageIDx].FieldName;
ReadAndPrintFieldByType[FieldType](FieldNamem , FileStatus)
end;
Hey presto a processing loop extendible to any number of record formats or field types.
I note the use of variable names with the same names as arrays to hold instances and (possibly Pascals *most* annoying routine feature) its insistance that the case of variables matters.
Hope that answers any questions as I am exhausted.
"in what universe does a customer go to a vendor, and asks to buy their software, then tries to impose contractual conditions on how that software came to be written?"
Congratulations you chose the #1 language where the #1 customer would do *exactly* that.
Standard US Govt contracts are *highly* prescriptive and the purpose of Ada was to reduce the number of languages supported by the DoD (around 1900 IIRC when they did the survey that decided 1 language to run them all). the aim being that their contracts *would* specifiy exactly that.
This is not as Draconian as it seems. Firstly you'd be pretty dumb not to have seen this on the RFP and still bid if you had *no* Ada skills and secondly you could probably whine to the Dod (as a US con-tractor) and get funds re-train your code monkeys (espeically if they already had security clearance).
If you're talking about shrink wrapped software I agree. It's a done deal.
Personally I think you can write garbage in *any* computer language. Hard coding the contents of an array seems permissible in any language I can think of, but I don't think anyone reckons it's a good idea to *do* so, *except* newby programmers who've never had to fix/upgrade the software afterward.
OTOH it is very quick to do and if they get promoted for doing such quick work they never have to sort out their mess.
I also believe that robust secure code can be written in any language *provided* tools exist which support that language and recognise the coding errors people are prone to in it. But selecting (or building) such tools does not get the program written, only get it written *faster* and more robustly once you start. This will continue as long as managers don't get paid on how many bugs they don't make or how much time the *avoid* wasting by fixing them. A recipe for some truly "Dodgy software (TM)".
OTOH if you're in the software business and make your money on the support contracts most of your customers sign then why *make* that investment. From this perspective a software house is a machine for *making* bugs. Like any parasite as long as the host is not damaged too much the relationship can continue indefinitely.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
